192
Tell me the truth ...
(lemmy.ml)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 15 May 2025
192 points (96.6% liked)
Programmer Humor
35875 readers
1487 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
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?
I've used it a fair amount for memory mapped IO where the hardware defined bitfields. It is also useful when you have a data format with bitfields. I'd say it is also useful when your data does not respect byte boundaries, but the only time I've run into that involved the bit order being "backwards", which means that I still had to bittwidle things back together.
From a performance perspective, a cache line is only 64 bytes. Space in registers, low level memory caches, and memory throughout are all limited as well.
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