logoalt Hacker News

Joker_vDyesterday at 5:28 PM1 replyview on HN

My point is that fixed-length instructions are supposed to be easier to decode than variable-length ones, right?

If not, then why even bother with fitting immediates and inventing LUI/AUIPC, just have a 48-bit long LI instruction. The same goes for 64-bit, an 80-bit LI.W is still shorter than the piecemeal construction with several instructions.

If yes, then the small cores are arbitrarily given a burden of supporting variable-length instructions, supposedly efficiently: if your instruction fetch is 16-bit wide, you need two fetches to fetch a single 32-bit instruction, which sucks; if it's 32-bit wide, you need to conditionally stash the upper half for the next fetch cycle, and still prefetch yet more 32-bits because that upper half may contain only a half of a full 32-bit instruction; alternatively, you can fetch 32-bits at alternated aligned/misaligned addresses and ignore the inefficiency of throwing away re-fetched bits — again, all of this sucks.


Replies

rwmjyesterday at 5:46 PM

Yes, fixed-length instructions are easier to decode, but that also means a hard upper limit on the number of instructions that could ever be supported. Which is obviously a problem for a future-proof architecture.

The rationale for this and also for confining the base set to 32 bit is explained here: https://docs.riscv.org/reference/isa/v20250508/unpriv/extend...

show 2 replies