4 ms·

Now if only Rust had bitfields like this. It was proposed years ago but nothing has come from it.

dbcurtis 8y ago
Yes, well, now that Rust is aiming for first class support for embedded by the end of 2018, I expect there to be more pressure to find a good solution for bitfields. For that target audience, many will consider the current situation a show stopper.
- burfog 8y ago
  Bitfield support is far more useful for emulators and for dealing with binary file formats and binary network protocols. Embedded stuff typically means kernels and drivers. For that, the bitfields are in hardware registers. This is troublesome because the hardware might not act like normal RAM. Issues you will encounter: 1. The hardware demands a particular access size. For example, a nice big array of 4-bit values may need to be accessed only by 16-bit operations because it is on a 16-bit data bus that lacks byte enable lines. Another example is that different access sizes may go to different registers. 2. The hardware takes an abnormal action when accessed. Reading and writing might go to separate registers. Reading could fetch a byte from a FIFO, so the language/compiler is not free to do speculative or repeated reads. Writing could output to a FIFO. Reading or writing could clear bits, possibly in a different register, or initiate a coprocessor action. 3. The bus might allow reordering that can affect the device. For example, the bus might cancel operations that seem to be superseded by later operations (write after write, or read after read) but enforce ordering in other cases. The compiler must respect this in some way, possibly by suppressing optimization or by generating a compile error when the constraints appear to be violated. You also get ugly layout issues like split fields, but that hits emulators and file formats too.
- cormacrelf 8y ago
  There are a few crates around that help you get over the hurdle with some (but not too much) awkwardness, like https://github.com/dzamlo/rust-bitfield https://github.com/dzamlo/rust-bitfield

Yes, well, now that Rust is aiming for first class support for embedded by the end of 2018, I expect there to be more pressure to find a good solution for bitfields. For that target audience, many will consider the current situation a show stopper.

burfog 8y ago
Bitfield support is far more useful for emulators and for dealing with binary file formats and binary network protocols. Embedded stuff typically means kernels and drivers. For that, the bitfields are in hardware registers. This is troublesome because the hardware might not act like normal RAM. Issues you will encounter: 1. The hardware demands a particular access size. For example, a nice big array of 4-bit values may need to be accessed only by 16-bit operations because it is on a 16-bit data bus that lacks byte enable lines. Another example is that different access sizes may go to different registers. 2. The hardware takes an abnormal action when accessed. Reading and writing might go to separate registers. Reading could fetch a byte from a FIFO, so the language/compiler is not free to do speculative or repeated reads. Writing could output to a FIFO. Reading or writing could clear bits, possibly in a different register, or initiate a coprocessor action. 3. The bus might allow reordering that can affect the device. For example, the bus might cancel operations that seem to be superseded by later operations (write after write, or read after read) but enforce ordering in other cases. The compiler must respect this in some way, possibly by suppressing optimization or by generating a compile error when the constraints appear to be violated. You also get ugly layout issues like split fields, but that hits emulators and file formats too.
cormacrelf 8y ago
There are a few crates around that help you get over the hurdle with some (but not too much) awkwardness, like https://github.com/dzamlo/rust-bitfield https://github.com/dzamlo/rust-bitfield