Yes, firmware running on bare metal requires good resource management. My current development board processor contains 512KB SRAM. That’s equivalent to half of the size of an average PDF.
Yes, because cache optimization is still important. Also useful to keep the size of packets down, to reduce the size of file formats, and anywhere that you use hundreds of thousands of instances of the struct.
For the packet size and fils format issues, it seems like this language feature would be less reliable than bit shifting or masking, given that different implementations may store the bits in a different order or not compactly
Use bit-fields:
struct { bool a : 1; bool b : 1; bool c : 1; //... };Edit: careful not to use a 1-bit signed int, since the only values are 0 and -1, not 0 and 1. This tripped me up once.
This is both the right and wrong answer
In a world where a bigger memory chip is more expensive by only a few cents where this would be most useful, is this feature still relevant?
Yes, firmware running on bare metal requires good resource management. My current development board processor contains 512KB SRAM. That’s equivalent to half of the size of an average PDF.
Yes, because cache optimization is still important. Also useful to keep the size of packets down, to reduce the size of file formats, and anywhere that you use hundreds of thousands of instances of the struct.
For the packet size and fils format issues, it seems like this language feature would be less reliable than bit shifting or masking, given that different implementations may store the bits in a different order or not compactly