From:   Krste Asanovic via lists.riscv.org
Sent: Thursday, October 6, 2022 12:42 PM

We can delay, but not prevent, the need to have greater than 32b instructions.

I worked on another RISC ISA for 25+ years, and we were planning for an inevitable 64-bit instruction extension to that one, also.  I completely concur that “we can delay, but not prevent” the need for >32b instructions. 

So yes, it will need to happen – but it is important that when it does happen, it’s rolled out as a well-thought-out, planned, restrained extension so that we can avoid the worst pitfalls.  (RISC-V instruction encoding already provides for longer instructions, so at least a clean path has been laid – we need to be good stewards of that gift and use it wisely)

CSR-state-encoding approaches [to ISA extensions] are annoying
to both hardware implementers and software toolchains.

And also create enormous verification headaches.  I’ve seen that happen during a window of time when an ISA didn’t have good ISA architectural oversight (hardware teams effectively put opcode bits in state registers for certain instructions) -- it took over a decade to undo some of the architectural damage from that, and the parts that couldn’t be undone left permanent baggage for implementors and especially verification teams to deal with.   That is not a place that we want to go, when it is so avoidable.

most alternative datatypes need a much smaller number of operators supported than IEEE FP and some have unique operators not present in IEEE, so [it] does not make sense to encode full cross-product of datatype and operators for all datatypes.

Agreed.

= DW