[libre-riscv-dev] [isa-dev] Re: SV / RVV, marking a register as VL.

[Jacob Lifshay]

On Sun, Sep 1, 2019, 07:34 lkcl <luke.leighton at gmail.com> wrote:
>
> On Saturday, August 31, 2019 at 3:57:20 PM UTC+1, lkcl wrote:
>
>>
>> i've been trying to think how to get that down further, for some time.
>
>
> came up with something, overnight:
> https://groups.google.com/forum/#!topic/comp.arch/l2nzme2sCR0


What about taking the vector/scalar propagation idea and just apply it
to normal instructions (outside of VBLOCK):

there would be a 128-bit CSR (64-bit on RVE) with a 4-bit field for
each register field encoding [1], tentatively named SVMODES. It is
allocated to normal CSRs in the same manner as the time CSR -- by
splitting into XLEN-sized chunks.

[1]: not just register number, other extensions may have a register
field encoding to register number translation table, such as SVorig.

each field would be encoded as follows:
bits 0-1:
    00: SUBVL=1
    01: SUBVL=2
    10: SUBVL=3
    11: SUBVL=4

bits 2-3:
    00: scalar
    01: vector unpredicated
    1x: vector (predication -- TBD)

the 4-bit field corresponding to rd would be written with the vector
mode of the result of each instruction, which is calculated from the
instruction and the vector modes as follows:
1. If the instruction specifies scalar/vector mode in the encoding
(like via SVPrefix), then the mode specified by the instruction is
used.
2. Otherwise,
    a. the scalar/vector mode is calculated for each of the source
operands by reading from the SVMODES field corresponding to the
register field encoding for that source operand.
    b. If the SUBVL modes from the source operands don't match and the
instruction doesn't specifically handle differing SUBVL modes, then
trigger an illegal instruction trap (swizzle can handle diffferent
SUBVL modes, most other instructions can't)
    c. The SUBVL mode for the result is chosen from one of the source
operands (doesn't matter which, they match) unless the instruction
specifically overrides the result SUBVL.
    d. If all the source operands are scalar, then
        1. the result is scalar unless specifically overridden by the
instruction.
    e. Otherwise,
        1. the result is vector unless specifically overridden by the
instruction.
        2. The result predication is TBD (probably selected similarly
to SUBVL selection).

There would be a separate SVMODES csr used for context switching, on a
trap, the old value would be saved (by switching which SVMODES csr is
used or by copying to a different csr), then the SVMODES csr would be
cleared to all zero (all registers scalar with SUBVL=1).

on return from an exception, SVMODES would be restored (by copying
back from the saved csr or by switching which SVMODES csr is used).

There would be a separate instruction that clears SVMODES to all zero,
to allow calling scalar code quickly.

Since using SVMODES instead of all SVPrefix instructions just makes
the code smaller and faster, but doesn't allow using any more
instructions than before, it could be used like a more complicated way
to compress instructions and it would be possible to limit all SVMODES
handling to after the register allocator in the compiler, similar to
how RVC instructions can be substituted entirely in the assembler,
without the compiler needing to know (though knowing allows selecting
more optimal code at the expense of a more complex compiler).

Jacob Lifshay