2 ms·

I suggest that eventually it would make sense to move from octet-based ISAs to 64-bit word based ISAs. One such sizeof(int, long, float, double, char) is 1.

sparkie 4y ago
RISC-V is a variable-length instruction ISA, where instructions are a multiple of 16-bits.
colejohnson66 4y ago
What would be the benefit? Modern processors handle (what appear as) octet-based memory (despite having 64-bit words) all the time with no issues. In fact, your processor may only work on, say, 128-bit (16 byte cache line) memory accesses at a time. But if you insist, TI has some DSPs where CHAR_BITS is 16. They're supposedly a massive pain to use because you have to mask off the upper octet every so often.
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 ago
  If 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 ago
    That 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.

sparkie 4y ago

RISC-V is a variable-length instruction ISA, where instructions are a multiple of 16-bits.

colejohnson66 4y ago

What would be the benefit? Modern processors handle (what appear as) octet-based memory (despite having 64-bit words) all the time with no issues. In fact, your processor may only work on, say, 128-bit (16 byte cache line) memory accesses at a time. But if you insist, TI has some DSPs where CHAR_BITS is 16. They're supposedly a massive pain to use because you have to mask off the upper octet every so often.

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 ago
If 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 ago
  That 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.