←back to thread

366 points pabs3 | 2 comments | | HN request time: 0.526s | source
Show context
justahuman74 ◴[] No.41364800[source]
I hope they're able to get this ISA-level feedback to people at RVI
replies(2): >>41364827 #>>41364904 #
dmitrygr ◴[] No.41364827[source]
None of this is new. None of it.

In fact, bitfield extract is such an obvious oversight that it is my favourite example of how idiotic the RISCV ISA is (#2 is lack of sane addressing modes).

Some of the better RISCV designs, in fact, implement a custom instr to do this, eg: BEXTM in Hazard3: https://github.com/Wren6991/Hazard3/blob/stable/doc/hazard3....

replies(2): >>41364944 #>>41366113 #
renox ◴[] No.41364944[source]
Whoa, someone else who doesn't believe that the RISC-V ISA is 'perfect'! I'm curious: how the discussions on the bitfield extract have been going? Because it does really seem like an obvious oversight and something to add as a 'standard extension'.

What's your take on

1) unaligned 32bit instructions with the C extension?

2) lack of 'trap on overflow' for arithmetic instructions? MIPS had it..

replies(3): >>41364991 #>>41365621 #>>41367330 #
1. phkahler ◴[] No.41367330[source]
IMHO they made a mistake by not allowing immediate data to follow instructions. You could encode 8 bit constants within the opcode, but anything larger should be properly supported with immediate data. As for the C extension, I think that was also inferior because it was added afterward. I'd like to see a re-encoding of the entire ISA in about 10 years once things are really stable.
replies(1): >>41368901 #
2. dmitrygr ◴[] No.41368901[source]
The main problem with what you’re saying is that none of the lessons learned are new. They were all well-known before this ISA was designed, so if the designers had any intention of learning from the past, they had every opportunity to do so.