AdamHorden has quit [Read error: Connection reset by peer]
matoushybl[m] has quit [Ping timeout: 246 seconds]
M9names[m] has quit [Ping timeout: 246 seconds]
vollbrecht[m] has quit [Ping timeout: 246 seconds]
birdistheword99[ has quit [Ping timeout: 246 seconds]
marmrt[m] has quit [Ping timeout: 246 seconds]
matoushybl[m] has joined #rust-embedded
marmrt[m]1 has joined #rust-embedded
therustybits[m] has quit [Ping timeout: 246 seconds]
vollbrecht[m] has joined #rust-embedded
birdistheword99[ has joined #rust-embedded
therustybits[m] has joined #rust-embedded
AtleoS has joined #rust-embedded
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 252 seconds]
mrkajetanp has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 260 seconds]
onsdag[m] has quit [Quit: Idle timeout reached: 172800s]
sugoi has joined #rust-embedded
sugoi has quit [Ping timeout: 260 seconds]
cacharle[m] has quit [Quit: Idle timeout reached: 172800s]
<andar1an[m]1>
Is there any crossover between rustc cranelift work and embedded?
<diondokter[m]>
Not really
<K900>
What sort of crossover are you expecting?
<diondokter[m]>
AFAIK cranelift only targets x86-64 (and maybe ARM64?)
<K900>
Cranelift can target aarch64, does that count?
<K900>
It can do aarch64 and I think rv64somethingsomething?
<diondokter[m]>
I mean, maybe it could add support for 32-bit thumb instructions in the future...
<diondokter[m]>
s/ARM64/aarch64/
<K900>
> Cranelift has four backends: x86-64, aarch64 (aka ARM64), s390x (aka IBM Z) and riscv64.
<K900>
...is s390x embedded?
<K900>
(don't answer that)
<andar1an[m]1>
Just wondering about embedded plans pertaining to modular toolchains. It was a cool topic to me yesterday. Assuming there is GCC, LLVM mainly supported now? But It seems there is a team looking at leveraging cranelift in the rust compiler. I liked learning about it in wasm world.
<K900>
What does "modular toolchains" even mean
<andar1an[m]1>
Choosing
<K900>
Choosing what?
<andar1an[m]1>
I dk what else to call it. Basically just curious about how embedded development will create requirements for specific toolchains.
<K900>
What requirements?
<JamesMunns[m]>
K900: You don't gotta be antagonistic.
<JamesMunns[m]>
It seems somewhat reasonable that andar1an is describing "modular backends"
<K900>
You are being very vague yet again
<andar1an[m]1>
I am learning. If my questions are vague it is because I don't understand yet. You don't need to answer if it upsets you
<andar1an[m]1>
I am assuming that linking relies on a specific toolchain
<K900>
No, it does not
<JamesMunns[m]>
andar1an the door is open to other compiler backends, LLVM is by far the main one, there are two flavors of GCC backends in the work, and cranelift.
<K900>
And yes that was the missing part
<K900>
Linking isn't actually specific to a compiler backend
<JamesMunns[m]>
Currently, GCC could be used to support embedded targets, and cranelift could, but it's not planned at all afaik
<K900>
At least in the overwhelming majority of cases
<K900>
So you can, e.g., build some code with GCC, and then link it with LLD or mold or whatever
<K900>
You don't have to use the GNU binutils
<K900>
You maybe won't be able to use the magic single line GCC invocation that has the compiler link the output for you behind your back
<K900>
And even then most linkers provide a compatible enough interface that you can just tell gcc (or rustc, or whatever it is you're using) to just use this or that linker binary
<K900>
And it'll _probably_ work
<K900>
In most cases you can even link together code produced by multiple different compilers, as long as they agree on ABI
<andar1an[m]1>
Thanks, I think what I am trying to understand is how tightly coupled rust-embedded development may be to specific toolchains (and it doesn't sound like it is?), or if there are some form of "interfaces" that make this more agnostic so that one may vary in the future. I like the thought of competition and diversity for innovation and progress. It is good you mentioned ABI's because I have been wondering if the wasm ABI is
<andar1an[m]1>
relevant in embedded. I'm still early stages of learning but this neat phil-op rustos-dev blog has been helpful.
<K900>
Every target has its own ABI, generally
<K900>
Also, what exactly do you mean by "toolchain" here?
<K900>
Like, you talked about codegen backends before
<K900>
But those are all backends inside rustc, you still invoke rustc
<andar1an[m]1>
Yes, but there may be time implications based on that choice for build
<K900>
There's multiple other Rust compilers out there
<K900>
None of them are really feature complete but some are getting there
<K900>
So is your concern coupling, or is it just performance? Because generally the way to improve performance is probably not to write another compiler
<andar1an[m]1>
Ya, I just love this. Trying to imagine future, not so much worry about what to use now with this thinking
<K900>
(and in fact I don't think any of the currently existing compilers are meaningfully faster than rustc)
<andar1an[m]1>
I don't plan to use something other than rustc
<andar1an[m]1>
I am referring to rustc using llvm or cranelift, etc. \
<K900>
This is just the codegen backend, and honestly especially on embedded targets codegen should not take up that much time
<andar1an[m]1>
Just didn't understand implications for embedded because of flags that I saw that I don't understand yet
<K900>
Because you're not generating that much code usually
<andar1an[m]1>
Cool, ty
<K900>
The slowest parts of rustc are in the type checker
<andar1an[m]1>
That's one reason why I am so interested in embedded for "services". Way less code haha
<K900>
Even on non-embedded targets
<andar1an[m]1>
I also like to imagine neural networks physically. With ipv6 and embedded, it seems like things make sense
<K900>
I'm not sure I understand what you mean here
<K900>
Do you mean, like, running every node in a neural network on a separate physical node?
<K900>
Because modern ML models have millions, or even billions (in the case of LLMs) of nodes
<K900>
So that's not really a thing that you can realistically do
<andar1an[m]1>
Maybe not every, and maybe not specifically an LLM netual network. But a highly distrubuted system where single nodes represent specific functions is fun to imagine
<andar1an[m]1>
I personally don't think neural network is a synonymous term with LLMs
<K900>
Basically any neural network that's not just an MNIST tutorial will have hundreds or even thousands of nodes
<andar1an[m]1>
more imagining web3 and p2p networks
<andar1an[m]1>
And IPV6 supports many many addresses
<K900>
But also what you're describing is closer to the "functions as a service" thing that was all the rage, like, a few years ago
<andar1an[m]1>
ARIN has a general meeting in October, it will be interesting to see what is discussed about this
<K900>
See AWS Lambda, etc
<andar1an[m]1>
I know what it is
<andar1an[m]1>
And before is was FaaS it was just sensors shipping data
<andar1an[m]1>
these are not new concepts
<K900>
They're not, but they had a lot of hype behind them, and many adopted them, and you can learn from what worked there and what didn't
<andar1an[m]1>
The value here is in utilizing as much available compute as possible to reduce waste and excessive manufacturing. Can't just produce more, we need to waste less
<dirbaio[m]>
ah for example 4 bytes before field_f?
<dirbaio[m]>
you can add a "dummy" u32 there so that these 4 bytes aren't padding anymore
<dirbaio[m]>
same with any other holes
<dirbaio[m]>
and once you got the struct with zero padding you can use zerocopy
<dirbaio[m]>
(or other crates like bytemuck, or using unsafe slice_from_raw_parts etc. but all these fundamentally require the structs have no padding to be sound)
<BenPitcairn[m]>
But presumably the resulting [u8;NUM_BYTES] or whatever, would not be the same, which unfortuantly is currently a requirement to maintain compatibility.
<dirbaio[m]>
so this change doesn't break compatibility or change the size of the struct
<dirbaio[m]>
it just converts 4 bytes of padding to 4 bytes of a field
<dirbaio[m]>
you can always do this to remove all "padding holes" without changing size or offsets of existing fields
<dirbaio[m]>
and once you have no padding holes, your struct is now safe to transmute to [u8; N]
<BenPitcairn[m]>
But there is no way to have field_f at offset 20 so the entire Struct will convert to a [u8;504]? (I realise that repr(C) would be causing the padding) Ultimately the SD card will be removed and the binary data read by a computer and currently that software cannot be changed.
<dirbaio[m]>
currently your struct has field_f at offset 24, not 20
<dirbaio[m]>
you can force packing the fields with #[repr(C, packed)]
<dirbaio[m]>
with that field_f will be at offset 20, unaligned
<dirbaio[m]>
but that is a backwards-incompatible change if you have existing code using the #[repr(C)] struct
<BenPitcairn[m]>
Sorry - I should have been more clear. The compatibilty isn't with the struct - it's with the structure of the 512bytes that ultimatly end up on the SD card.
<dirbaio[m]>
then try repr(C, packed)
<dirbaio[m]>
with `repr(C)` `BlockContentsA` is 512 bytes
<dirbaio[m]>
with `repr(C, packed)` `BlockContentsA` is 504 bytes
<dirbaio[m]>
pro tip: if you use rust-analyzer you can see the struct size if you hover it, and the field offsets if you hover them
<dirbaio[m]>
it helps to see exactly how the Rust compiler is laying out your struct in memory
<dirbaio[m]>
to check if it matches what you expec
<dirbaio[m]>
s/expec/expect/
<BenPitcairn[m]>
with `repr(C, packed)` I get a `reference to packed field is unaligned` error.
<BenPitcairn[m]>
If this part of the code isn't particularly performace critical would I be better just creating a new `[u8;N]` and copying in the required fields?
<BenPitcairn[m]>
This kind of issues only occurs with certain Structs which are mostly related to misc metadata. The "main" part is just storing an array of u32s so I can easily handle that.
<dirbaio[m]>
yeah with packed you can't get references to fields, you can only copy whole fields in or out
<dirbaio[m]>
because the fields may be unaligned, and references must always be aligned
<BenPitcairn[m]>
Ok - I that makes sense.
<BenPitcairn[m]>
dirbaio: Thanks for you help btw - this has been very useful.
<BenPitcairn[m]>
Is there anything else that I should bear in mind when using `repr(C,packed)`? In my very limited knowledge I understand it is strongly advised against!
<dirbaio[m]>
if you don't use unsafe the compiler will prevent you from shooting yourself in the foot
<dirbaio[m]>
the only side effect is you can't take references to fields
<dirbaio[m]>
which can be annyoing
<dirbaio[m]>
other than that it should be fine to use
<BenPitcairn[m]>
Thanks - just realised I still had a #[derive(Debug, Copy, Clone)] which was obviously stopping it compiling with repr(C,packed). If it's not performace critical do you think it's better to use the repr(C,packed) approach or creating a new array and copying in the required parts at the required locations? This would only need to be done at startup and shutdown of the device when not much else is happening.
<BenPitcairn[m]>
s/I//, s///
<dirbaio[m]>
perf should be the same with both
<dirbaio[m]>
but if you do it manually you'll have to write more boilerplate
<BenPitcairn[m]>
thanks for your help dirbaio
AtleoS has quit [Ping timeout: 260 seconds]
AtleoS has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 248 seconds]
haobogu[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]1>
> There are a number of officially supported targets by the Rust compiler, however, many bare-metal targets are missing from that list.
<thejpster[m]1>
Are they?
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
<alex[m]12>
I need to enable clocks to the ADC, however I can't access the RCC.ahbenr register, since the RCC is moved after using constrain() on it.
<alex[m]12>
So I am in a bit of a pickle: I'm programming an STM32F303 and I need to do some stuff the stm32f3xx HAL does not support (ADC Dual mode). So I'm accessing it register wise through the PAC.
<alex[m]12>
Do I need to give up on the HAL completely and do everything using PAC, or is there another way to access that register?
<BenPitcairn[m]>
I am modifiying RCC before calling RCC.constrain() and that seems to be working ok (In this case for enabling the MCO outputs).
<alex[m]12>
<BenPitcairn[m]> "I am modifiying RCC before..." <- It compiles now. No hardware to test it with yet though. Thanks!
cbjamo[m] has quit [Quit: Idle timeout reached: 172800s]