I use bit masks, suck it! (Really though, programming on an embedded CPU might be reasonable to do this, depending on the situation, but on a PC, trying to not waste bits wastes time)
Store only bits using word-length ints (32 bits in most modern architectures), and program everything to do math using arrays of 32 int-bits to numbers!
I once had to reverse engineer a database to make an invoice integration. They had an int named flags. It contained all status booleans in the entire system. Took me a while to figure that one out.
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
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.
If you want to optimize to this point, do some embedded development. It's somewhat fun to work at such a low level (testing tends to be annoying though)
23 Comments
Tolookah@discuss.tchncs.de · 41 pts · 1y
I use bit masks, suck it! (Really though, programming on an embedded CPU might be reasonable to do this, depending on the situation, but on a PC, trying to not waste bits wastes time)
Binette@lemmy.ml · 13 pts · 1y
exactly! it is more costly for your pc cpu to check for a bit inside a byte, than just get the byte itself, because adresses only point to bytes
virku@lemmy.world · 9 pts · 1y
Store 8 bits in the same byte then 👌
sxan@midwest.social · 4 pts · 1y
Wrong direction!
Store only bits using word-length ints (32 bits in most modern architectures), and program everything to do math using arrays of 32 int-bits to numbers!
virku@lemmy.world · 5 pts · 1y
Oh man! That took me down memory lane!
I once had to reverse engineer a database to make an invoice integration. They had an int named flags. It contained all status booleans in the entire system. Took me a while to figure that one out.
sxan@midwest.social · 5 pts · 1y
We've all been there, friend. The bit arrays can't hurt you now.
jsomae@lemmy.ml · 3 pts · 1y
Unlikely. Most of the time on modern hardware, you're going to be cache-limited, not cycle-limited. Checking one bit in a register is insanely fast.
ch00f@lemmy.world · 29 pts · 1y
I've been working on disassembling some 8-bit code from the 90s. Fuckers returned bits from functions using the overflow bit. Nuts.
racketlauncher831@lemmy.ml · 6 pts · 1y
What era was that device? Some old games on NES had to use all kinds of quirks like this to overcome hardware limitation.
ch00f@lemmy.world · 2 pts · 1y
It's in an AlphaSmart. I'm working through disassembling the ROM to add some new features.
jsomae@lemmy.ml · 4 pts · 1y
Where do you go to talk about such things? Could be fun to have a retro reversing community.
flubba86@lemmy.world · 1 pts · 1y
Nice.
jsomae@lemmy.ml · 26 pts · 1y
Use bit-fields:
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.
Transform2942@lemmy.ml · 18 pts · 1y
This is both the right and wrong answer
Strawberry@lemmy.blahaj.zone · 3 pts · 1y
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?
kora@sh.itjust.works · 6 pts · 1y
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.
jsomae@lemmy.ml · 3 pts · 1y
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.
Strawberry@lemmy.blahaj.zone · 1 pts · 1y
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
homura1650@lemm.ee · 1 pts · 1y
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.
Donkter@lemmy.world · 16 pts · 1y
Solution? Store 8 booleans in 1 byte.
Agent641@lemmy.world · 7 pts · 1y
If you put them in the right order, you can store 10 bools in a byte.
kompreshun.
Jolteon@lemmy.zip · 7 pts · 1y
lorty@lemmy.ml · 16 pts · 1y
If you want to optimize to this point, do some embedded development. It's somewhat fun to work at such a low level (testing tends to be annoying though)
CaptainBlagbird@lemmy.world · 19 pts · 1y
Embedded SW dev here; don't listen to this, fly you fools!