Hacker News Reader

Comment by monocasa | Hacker News Reader

Check out how the RISC-V jump offsets are encoded/packed.

   |   imm[20|10:1|11|19:12]   | rd | 1101111 |  JAL

I've heard that there's some reason for the bits being strewn about (something about how it enables some microoptimizations on tiny decoders by sharing muxes?), but I don't know the exact specifics.

View on HN

It's because then the other fields, such as the source and destination registers can stay in the same place across various opcodes. In the rare cases there's an immediate field, such as the jump offset, it uses what would otherwise be a register or an operand.

Disassembling RISC-V is then quite straightforward because of this feature.

As someone who's written a lot of disassemblers, this feature is far more complicated to write a disassembler for than how the other RISCs handle it, by close to an order of magnitude when you account for the extra tests that you want too.

All of the bits being contiguous would just mean that you could just

  jump_offset = (((i32)opcode) & 0xFFFFF000) >> 12;

rather than this weird game of trying to piecemeal back all of the requisite components. Or, if the components are in order then you're given the choice; it doesn't have to be a mutually exclusive decision.

It's got to be saving some muxes on tiny cores by keeping the sign bit and bits 10:5 in the same place, but honestly even that seems like a micro optimization that doesn't have a lot of benefit at the end of the day. I wouldn't think that this single saved mux would have been in a critical path (and the sign bit would have been in the same place regardless).

Reply on news.ycombinator.com