[libre-riscv-dev] multi issue

Jacob Lifshay programmerjake at gmail.com
Fri May 31 20:40:54 BST 2019


On Fri, May 31, 2019, 04:57 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> compare to this:
>
> * 1 to 6 months discussion on the new variable-length format (most of
> it waiting for other people to respond)
> * hand-over to RISC-V Foundation for ratification AT WHICH POINT WE
> ARE COMPLETELY EXCLUDED FROM ALL DISCUSSIONS.
> * ratification to take maybe another YEAR (during which time we have
> NO IDEA if the specification has been changed AND THE MEMBERS ARE
> PROHIBITED FROM DISCUSSING THAT WITH US)
>
> ... you see how that works?
>
yeah, in that case, let's just take all of the current spec's 48 and 64-bit
space and just trap for all of them when the isasel register is not 0
(allowing us to be forward compatible with whatever scheme is chosen by
emulating everything bigger than 32-bits). I still think the idea of
translating all instructions into 64-bit versions is a good idea, the
64-bit versions are kind-of like an intermediate language. I'll write a
spec for that today, I expect the spec to be quite simple, since it will
just expand everything into uniform fields optimized for simple decoding by
the execution logic. The pre-vectorization decoder will handle conversion
of all non-supported combinations to trap instructions. I think we should
use the lower 16-bits being 0 as the canonical  trap instruction, the upper
bits can be used to convey trap information. Unless we have another
mechanism to store the pre-decoding instruction bits, I think we should set
mtval to 0 on illegal instructions.

Jacob


More information about the libre-riscv-dev mailing list