<M9names[m]>
Alistair: there's an rv32ec in ch32v003 - it's a decently popular low-cost micro
<JamesMunns[m]>
I feel like at some point we'll end up wanting a better story for risc-v extensions and versions of std/core
<M9names[m]>
we'll probably always want the base and most "common" combination of extensions prebuilt, but i have had no issues using build-std for oddball configurations
<thejpster[m]>
<JamesMunns[m]> "I feel like at some point we'..." <- Also for combinations of FPU, PAC, MVE and MVE.FP on M85.
<JamesMunns[m]>
yeah. it definitely seems to me that embedded devices are going to need a better story about build-std and compile-time target features.
<JamesMunns[m]>
I also know the cargo team was supportive of working towards stabilizing parts of build-std
<thejpster[m]>
I think this came up in Delft. I don’t know what progress has been made.
<JamesMunns[m]>
I think probably none, blocking on us proposing something
<diondokter[m]>
There's no real progress that I know of except that I added the optimize-for-size feature flag together with some optimizations from me and Folkert
<diondokter[m]>
But yeah, I think they're willing (for at least a subset of features), but someone needs to push it I think
<JamesMunns[m]>
honestly thejpster if you have a write up of "things you might want to do for thumbv8" like all the potential variants, and someone else risc-v aligned could give examples of the same for different extensions, it'd probably be a very big help
<thejpster[m]>
I think the new platform docs I wrote cover most of it
<diondokter[m]>
Also: What is the minimum of feature set that we can stabilize that would still be useful to us.
<diondokter[m]>
Might be possible to stabilize building `core` and not yet building `std`
<diondokter[m]>
s/./?/
<thejpster[m]>
I didn’t mention PAC because PAC doesn’t work in Rust on M-Profile. But that’s all I left out.
<thejpster[m]>
It doesn’t even need to be in cargo. I’d be happy to call rustc and do it by hand. I just don’t want to have to use the secret bootstrap flag.
<JamesMunns[m]>
diondokter[m]: > <@diondokter:matrix.org> Also: What is the minimum of feature set that we can stabilize that would still be useful to us?
<JamesMunns[m]>
> Might be possible to stabilize building `core` and not yet building `std`
<JamesMunns[m]>
but yeah, also being able to build core with either "prefer opt size" or "panic immediate abort" enabled are also common nightly cargo opts
<JamesMunns[m]>
thejpster[m]: I think cargo + `build-std` is the correct stable path forward
<diondokter[m]>
optimize-for-size is probably not gonna be stabilized soon since it's still up in the air whether they want to keep it in the long run.
<diondokter[m]>
But panic immediate abort might be possible to stabilize
<thejpster[m]>
JamesMunns[m]: Using nightly or the bootstrap flag?
<thejpster[m]>
I see cargo as a mechanism for invoking compilation but the fundamental problem is that core and std are fully of nightly features and the requires compiler and libs, not cargo. Cargo can put a bow on it when it’s done.
<thejpster[m]>
s/fully/full/
<thejpster[m]>
s/fully/full/, s/the/that/
<JamesMunns[m]>
I think what we're talking about is not requiring nightly to use build-std, for a subset of uses
<diondokter[m]>
Indeed
<JamesMunns[m]>
so, cargo would be blessed to rebuild core/std in some cases using neither nightly nor the bootstrap flag
<thejpster[m]>
Where build-std is just rustc /path/to/core/lib.rs ?
<JamesMunns[m]>
thejpster[m]: I think the initial plan was "only with the snapshotted core source"
<JamesMunns[m]>
e.g. not "bring your own core"
<thejpster[m]>
Oh. Yeah. I don’t want to bless one build system. There are many build systems.
<diondokter[m]>
This is a cargo feature, not a rustc feature
<diondokter[m]>
IIRC there is a way to make the stable compiler use nightly features. I saw Mara Bos play with that to create cursed things one or two years ago
<JamesMunns[m]>
I think she was just doing RUSTC_BOOTSTRAP crimes
<thejpster[m]>
I don’t see that flag getting blessed, but maybe I’m wrong.
crabbedhaloablut has quit [Ping timeout: 248 seconds]
crabbedhaloablut has joined #rust-embedded
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
<JamesMunns[m]> "so, cargo would be blessed to..." <- When you say " core/std " you really mean it right? Not just core+alloc+panic_abort, but it would also work for rebuilding `std` with stable rustc and stable cargo? (For the few chips that do support std proper, that is)?
<ivmarkov[m]>
Ah that would be such a pity. If they do `core` I would imagine `std` won't be rocket science either... that would allow us to get rid of the nightly chain for the ESP-IDF. only reason we need it for `cargo -Zbuild-std`. Also other than optimization level, I don't think we need much more w.r.t. affecting the build.
<ivmarkov[m]>
Is there any new development in that repo? I think the effort there stalled > 3 years ago. Is there a person willing and having time to revive this?
<JamesMunns[m]>
The conversation at RustNL was "we didn't realize people wanted this so much, start proposing things you want/need for stabilization and we can start talking about it"
<ivmarkov[m]>
"We did not realize" :D I guess we should've been more vocal...
<JamesMunns[m]>
yeah, for sure there's been progress! build-std has gotten work, it's just been in the cargo repo
inara has quit [Quit: Leaving]
<JamesMunns[m]>
but: I think action is on us to start enumerating desires and proposing things for stabilization :)
<ivmarkov[m]>
How can I help?
<ivmarkov[m]>
<JamesMunns[m]> "I think she was just doing ..." <- Yes this, but also `export __CARGO_TEST_CHANNEL_OVERRIDE_DO_NOT_USE_THIS=1`
<JamesMunns[m]>
Yeah, if ivmarkov and thejpster and others could make a tracking issue or something to begin enumerating the requests, I think that would make it easier to communicate upstream.
<JamesMunns[m]>
Even if we don't know what to do, writing down what we want to be able to do helps a lot.
<dirbaio[m]>
panic-immediate-abort feels a bit hacky / leak impl details tho
<dirbaio[m]>
in theory the compiler should be able to produce equally good code with#[panic_handler] with abort()
<dirbaio[m]>
with LTO etc
<dirbaio[m]>
but for some reason it doesn't
gmarull[m] has joined #rust-embedded
<gmarull[m]>
Hi, is it possible to rename an enumeratedValue using svdtools? I've been able to replace them, but I'd like to just rename them.. thanks
<thejpster[m]>
i cannot make rustc hoist that load. It is, obviously, outside my loop. I even tried to put it outside my function. It just inlined it back inside the loop.
<adamgreig[m]>
is it a const constant?
<thejpster[m]>
no, because it's an array inside a static
<thejpster[m]>
but it's produced from a const fn
<adamgreig[m]>
a big array? is the index constant?
<thejpster[m]>
and it still puts the load in the loop
<thejpster[m]>
I really can't afford to be doing redundant loads in this loop
<dirbaio[m]>
maybe try a compiler_fence?
<dirbaio[m]>
load, fence, then loop
<adamgreig[m]>
I don't understand how it can not have it in the loop, isn't the value being loaded dependent on the loop variable?
<adamgreig[m]>
oh, just loading the address of the array every time, and then doing the array lookup inside that?
<adamgreig[m]>
yea, that does seem annoying... especially with r4 unchanged in the loop
<thejpster[m]>
<dirbaio[m]> "maybe try a compiler_fence?" <- Good idea
<JamesMunns[m]>
I don't totally track, but is there a reason not to make the two ptr ranges slices (one & one &mut), then do a `something.iter_mut().zip(other.iter()).for_each(|(dst, src)| ...);`
<JamesMunns[m]>
by making it a slice, you are asserting that the values do not otherwise change while the slices are alive, and by using iterator methods, you are proving that the iteration is in-bounds
<JamesMunns[m]>
(you don't really want to mix long lives slices and pointers, but turning ptr+ranges into slices, IF the contents are valid values, locally is very reasonable, imo)
<JamesMunns[m]>
if the dst is not necessarily valid, then you can do the same with MaybeUninit which can still be written to.
<JamesMunns[m]>
but yeah, you can still make an `&mut [MaybeUninit<GlyphAddr>]` and write through to that
<JamesMunns[m]>
s/lives/lived/
AtleoS has joined #rust-embedded
rom4ik1 has quit [Server closed connection]
rom4ik1 has joined #rust-embedded
<ivmarkov[m]>
<diondokter[m]> "Three things:..." <- Ok. Maybe not today, but I'll do a short writeup and paste here for your review. But for me, it really boils down to invoking `-Zbuild-std` with a stable compiler and cargo. No more, no less.
<thejpster[m]>
I don’t think I can make any &mut references to the frame buffer or the palette because the other core will be writing to it simultaneously.
<whitequark[cis]>
silly question maybe but: why not write it in assembly?
<whitequark[cis]>
it doesn't seem like a huge or hard to maintain piece of code
<diondokter[m]>
Yeah, I had the same thought. And that way you know it won't break in a future or past compiler version
<thejpster[m]>
The original point of the program was to demonstrate that Rust can do hard real time with reasonable performance without hand writing assembly.
<thejpster[m]>
It’s not making life easy though.
<JamesMunns[m]>
tbh if you have unsynchronized access to the same stretch of data you're kinda out the window, soundness wise
<JamesMunns[m]>
I admit not really grokking enough to do a reasonable and fair review tho
<thejpster[m]>
I think with ponters it’s fine. Worst case scenario is a 1/60 second glitch on a pixel or a colour. Only with a shared or mut references will the optimiser make assumptions around exclusivity.
<JamesMunns[m]>
it's... complicated. By loading or storing to a pointer you are asserting that you are allowed to do that, and you have correct provenance, etc. IF the storage pointer is derived from an UnsafeCell, this is somewhat better, but it's not quite "no references means no UB".
<JamesMunns[m]>
But this also probably isn't helpful and just ranting and raving about UB without time to do a code review is probably no better than noise.
<JamesMunns[m]>
so I'll butt out.
<thejpster[m]>
neither a compiler_fence nor a fence helped - it left the fence outside the loop and kept the literal load inside the loop
<geky[m]>
<thejpster[m]> "godbolt has it hoisting the load..." <- Weird, maybe the compiler is more worried about register spillage? Is draw_next_line_chunky4 inlined? Maybe moving the hot loop to its own noinline function would help.
<geky[m]>
Or at least test if that's the case
<thejpster[m]>
yes it's all inlined into core1_main, which is in RAM
<thejpster[m]>
it uses the same number of registers whether you load the constant once ahead of the loop, or load it 320 times inside the loop
nadja has quit [Quit: bye!]
nadja has joined #rust-embedded
<geky[m]>
Huh, yep, that is weird
<geky[m]>
Maybe it _thinks_ it will spill and then a later optimization pass saves a register?
<geky[m]>
Sounds frustrating
jduck[m] has quit [Quit: Idle timeout reached: 172800s]
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]
RockBoynton[m] has joined #rust-embedded
<RockBoynton[m]>
diondokter: Are you planning a release for `device-driver` anytime soon? I wanted to give it a shot but noticed the github version has quite a few differences from the one on crates.io
<diondokter[m]>
RockBoynton[m]: Yeah true. I could do a release I guess. But I'm not very happy with the state of the code so I've been putting a lot of work in refactoring everything and unlocking more features and making existing features nicer. So I've been reluctant to release...
<diondokter[m]>
Any feature specifically that you're looking for?
<diondokter[m]>
The refactor is on a whole other branch, so that's not in the way of doing a release
<RockBoynton[m]>
Nothing specific, I am just writing a driver, so I was looking for tools to make that easier, found this, and I recognized the name! I just started following the example in the repo and immediately got errors when trying to import things that aren't exported (at least from the root) in the released version
<diondokter[m]>
<RockBoynton[m]> "Nothing specific, I am just..." <- Ah yeah that makes sense! I'll make a release tomorrow
Gewinum[m] has joined #rust-embedded
<Gewinum[m]>
dear Rust community, i've got an announcement to make
<Gewinum[m]>
dirbaio[m]: Go is supported by a whole huge company, its pretty universal honestly
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
I would love if Rust had a suitable backend framework. To use Python analogies, there are many Flask-analogs, but no Django analogs
<dirbaio[m]>
there isn't even good flask analogs. there's libs with way too many generics.
<firefrommoonligh>
I think Rust in theory would be a nice library for backend websites, but IMO it's a lack of lib/ecosystem issue. Which is nontrivial because something like Django or Rails is large and complex. Maybe some day. I don't have a principle against rust on backend, but it's one area where I will not use it, yet.
<Gewinum[m]>
yall never tried to make backend on c# without asp.net
<firefrommoonligh>
I remember early on when I was asking about an ORM like SQLAlchemy or Django's ORM, the rust guys told me I was nuts for wanting that, and that Diesel is perfect.
<firefrommoonligh>
I think specifically the disconnect was in wanting a model-based auto-migration setup
<firefrommoonligh>
Then again, the Python and Django guys (including official docs) think you're doing something very naughty if you want to use the raw Django SQL queries instead of the ORM
<dirbaio[m]>
diff models and autogenerate migrations? yeah I don't get why that's not more common. Django's migrations are sooo good
<Gewinum[m]>
honestly i personally dont trust orms much
<firefrommoonligh>
So, to change a DB model in Django, you update your model, then run python manage.py makemigrations and python manage.py migrate, and it's done. SO, kind of like changing normal code, but with 2 CLI thinigs
<Gewinum[m]>
id rather write prepared raw sql queries than use orm
<firefrommoonligh>
In Diesel, at the time, you had to change the model in 3 separate places with 3 separate syntaxes, eg just to change a field or w/e
<firefrommoonligh>
Gewinum[m]: I think the raw is easier to debug and QC the ORM isn't fucking you with a slow query, but ORM can be convenient/easier to read/write. Especially for the complex queries
<Gewinum[m]>
firefrommoonligh: i remember in c# there were architectures where you used raw sql queries for read and orm for writes
<firefrommoonligh>
dirbaio[m]: Very nice! I am suspicious that eventually we will get something like this in Rust
<firefrommoonligh>
No blockers I am aware of; just hasn't been done as of when i last checked
<dirbaio[m]>
not so sure. for some reason the latest trend is "write migrations in sql, generate models from that"
<dirbaio[m]>
* not so sure. for some reason the latest trend is "write migrations in sql, apply them to a db, generate models from the resulting schema"
<dirbaio[m]>
which I think is worse 🤷
<dirbaio[m]>
db's data types are much less rich than Go/Rust types
<firefrommoonligh>
Oh no!
<dirbaio[m]>
you often want two columns to be two different Go types but both get stored as strings in the db
<dirbaio[m]>
if you generate from the db ... you can't
<firefrommoonligh>
I change my mind on things all the time, and make mistakes. This includes on DB schema... so I like making changes easy
<firefrommoonligh>
So, what I am confused about, is what all the micro servers are being used for. I am guessing it's microservices vice websites
<firefrommoonligh>
(Rocket, Axum, Axios etc)
<firefrommoonligh>
They make it very easy to respond to web responses and serve content, but don't have integration with all the things even a relatively small website would have. Auth, ORM integration, email, security etc
<firefrommoonligh>
templates
<dirbaio[m]>
sqlbunny is used in 4 companies. the 4 companies I wrote the backend of :D
<firefrommoonligh>
V nice!
<dirbaio[m]>
I actually don't want it to get popular lol
<firefrommoonligh>
I have never used Go
<firefrommoonligh>
Too many people asking dumb Qs about it?
<dirbaio[m]>
probably? dunno
<dirbaio[m]>
maintaining embassy is bad enough
<dirbaio[m]>
and an orm is much "less cool"
<firefrommoonligh>
Well, if it's already helped you on your own projects, worth it
<dirbaio[m]>
it does the things I want exactly how I want 🤷