[libre-riscv-dev] multi issue

[Luke Kenneth Casson Leighton]

On Fri, May 31, 2019 at 8:41 PM Jacob Lifshay <programmerjake at gmail.com> wrote:


> (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,

 yes, agreed.

> 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.

 basically... yes.  it should, in effect, comprise nothing more than:
 * every field of the 32-bit opcode
 * all the predication bits/fields
 * basically everything from SV-v2 (48-bit format)
 * fully-extended register numbers
 * VL (explicitly, this time) if it will fit.
 * anything else that provides the *FULL* context of the operation
needed to be carried out

i would prefer - very much - that the 32-bit RV format be kept as-is,
and any other bits *added* - just like in the 48-bit format - rather
than spending extra time trying to "reinvent" yet another instruction
format.

if going down that path it would be better to forget the effort
entirely, do a "partial decode" (extract funct7 etc.) and eat the gate
space by way of a much simplified instruction issue phase.

 ( right now for testing purposes i have semi-invented an
"instruction" set.  it is 4 bits long.  the first 2 bits say "please
communicate with the INT Computation Unit Group and do this
operation", the second 2 bits say "please communicate with the BRANCH
CU Grp and do this operation".

 that level of simplicity has a cost in terms of the amount of
encoding space.... and i don't care!)

 RV32 on the other hand is sufficiently "regular" from a decode
perspective that it can be worthwhile using it - in combination with
the extra bits to extend regnums and add predication etc. etc. - to
use as the fundamental basis.

 if it really can't fit into 64 bits, and it has to be say 68 or even
70, that's absolutely fine.  we're using it "internally".  it's not
intended as a "public spec", although yes, i agree that it would be
really nice if it could also *become* a public ISA API, that's not the
primary goal here.


> 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.

hm.  you've lost me here.  can you raise a bugreport for this, it's
(again) getting sufficiently complex to need tracking, and we're
starting to make crucial decisions that need to be kept track of.

l.