[libre-riscv-dev] Instruction sorta-prefixes for easier high-register access

[Jacob Lifshay]

On Fri, Jan 25, 2019 at 2:24 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> hiya jacob, ok so i had a couple of days to think.
>
> my main concern about modifying encoding of RV instructions is that SV
> then becomes a dead-end as far as wider adoption is concerned, due to
> the violation of the rule that "no instructions shall need
> modification to be made parallel".  people considering adopting SV on
> custom (or future) extensions may not have the same operands or types
> of operands / modifiers, and the lack of clarity and simplicity makes
> them stay away.
>
Yeah, I was starting to get a little concerned about that, the prefix
proposal doesn't exactly have a consistent pattern as it is. I think I went
a little overboard with the different prefix formats.

>
> also: if we create what is effectively a new encoding, we might as
> well stop entirely on SV, and implement RVV plus some custom
> RVV-xBitManip extensions.  it would be a lot less work, particularly
> software-wise.
>
Yeah, leave that for a backup plan if SV turns out to not work or we run
out of time or something.

>
> so, can we do a parallel track (not *stop* the new encoding entirely),
> seeing if it's possible to shoe-horn all the required prefixing into
> the 12 bits *without* modifying the 32-bit encoding?  i like vlp4
> (that's 4), i like the 2-bit scalar/vector-mod-2 idea (2+2 for rd and
> rs*), that leaves 4 bits, at least 2 of which need to be allocated to
> over-riding the dest-elwidth (as separate and distinct from the
> *source* elwidth which comes from the operation).
>
If we switch the 2-bit scalar/vector to 1-bit scalar/vector-mod-4, we will
have more bits left over.

Assuming we do implement scalar/vector-mod-N we should use moving the MSB
to the LSB to save muxes, like the rest of RISC-V, rather than shifting:
let reg_num: u5 = ...;
let scalar: bool = ...; // not really part of reg field anymore
let reg_num = if scalar {
        reg_num as u7
    } else {
        // sends abcde to deabc00
        ((reg_num as u7 & 0x3) << 5) | (reg_num as u7 & 0x1C)
    };
use_reg(reg_num);
We may want to define a slightly different transformation for C
instructions, to allow the 3-bit register fields to be the most useful.

Also, I think that we need to not have seperate source and dest elwidths
except on mv/conv since we can then dedicate a clock cycle to the type
conversions rather than trying to pack it in every operation. We would
still have all the different elwidths but an op would have the same elwidth
out as in (except for mv/conv). I don't think type conversion is going to
be common enough to use an extra 2-bits and maybe an extra pipeline stage
or two to allow conversion for every instruction.

I think we should try for a 5-bit vlp since that way, we can have more
predication registers and all 4 most common (1..4) VL-multipliers together.
>From what I recall, the LLVM variable length vectors will support something
like VL multipliers, so it will make it easier to compile for as well.

>
> that would leave 2 bits spare which could be used for more
> operation-specific uses such as LD/ST behaviour.
>

> what do you think?
>
Yeah, sounds good. If we don't have enough for LD/ST, we can always add
custom instructions (not by abusing the prefix system).

Jacob Lifshay