3 ms·
You mean sizeof({int, long, float, double, char}) == 8, right? [edit: no, I guess not. sizeof returns char-sized units, not bytes. TIL.] But why? I don't anti
by scottlamb 4y ago
You mean sizeof({int, long, float, double, char}) == 8, right? [edit: no, I guess not. sizeof returns char-sized units, not bytes. TIL.]
But why?
I don't anticipate we'll ever stop caring about using RAM efficiently, so I assert we need a way to operate on smaller types. The compiler could provide the traditional API I want this by masking/shifting without instructions specifically for smaller types, but (a) then there's a lot of extra masking and such to do anything, and (b) it would be bad for thread safety. IIUC Alpha was a bit like this in that read-write operations done from different threads on adjacent bytes within a word might clobber each other. Not great...
And as colejohnson66 said, there are DSPs like this, but they are explicitly not designed for general-purpose programs.
- thriftwy 4y agoIf you're searching for a way to snap your data to power-of-two byte grid, you're already not using RAM efficiently.
- scottlamb 4y agoThat seems pretty absolute! Bitstream encoding of everything would introduce a lot of complexity. There are places where it's called for, but I think in many many places the status quo of rounding up to 1/2/4 bytes is a better solution than either bitstream encoding or rounding up to 8 bytes.