[libre-riscv-dev] SV Prefix questions

[Luke Kenneth Casson Leighton]

(replying slightly out of order, more later, once i've thought it through)

On Wed, Jun 26, 2019 at 7:39 AM Jacob Lifshay <programmerjake at gmail.com> wrote:

> >  again, to reiterate: i do *not* believe it is a good idea to add
> > actual instructions to SVP.
> Weren't we going to add SVP instructions anyway for the 32-bit
> compressed versions of the 48-bit and 64-bit instructions?!!

 yes... conceptually split between "the prefix which adds SV state"
and "the scalar C instruction".

> We are also adding all the P48 and P64 instructions.

 which, again, is "the prefix which adds SV state" and "the scalar
RV32 instruction".  the P64 state just happens to be longer than the
P64 state.

 we are *not* actually adding any new P48 or any new P64 instructions.
look again really closely at the spec, particularly the way that i
split the tables out to make this really, really clear.


 this is a fundamental tenet of the SV paradigm.  "no new opcodes" is
critically important to observe.  about the only justifiable exception
to that is possibly dot-product, and *maybe* reduce-style operations
[although even those can be covered by overlapping SV Registers].

 this fundamental aspect is why i said, last month, that P64 should
take an absolute maximum of 1-2 days to complete.

 why?  because all it should be is "a longer prefix that adds SV state
to [any] scalar instruction".

that is *completely different* from using some of the P48 (or even
P64) brownfield encoding space *as* scalar *NON-SV* operations... then
working out how to add an SV prefix on top of them.  which is
something we should consider doing only as a last resort.

ah.  drat.  i sent you the wrong "discussion" link with the
MV/Swizzle.  moved to separate page:
https://libre-riscv.org/simple_v_extension/specification/mv.x/

so that's a *32 bit* encoding... that can also be used as a standard
(scalar) 32-bit MV.

* if embedded in P48 it adds P48 SVprefix SV state
* if embedded in P48 it adds P64 SVprefix SV state which *includes*
setting MVL and VL *and* SUBVL *and* extends the registers to the full
7 bit.
* if embedded in a VBLOCK it gets the full flexibility including
overlapping registers.

it is *NOT*, repeat *NOT*, an instruction that is **ONLY** accessible
via SVPrefix.  that's the difference.

the reason for not mixing the two is that it requires complications in
the decode and the instruction queue implementation to support.

everything should be mappable down, in the instruction queues, to:

* some vectorisation state unique to the *element*
* a 32-bit *SCALAR* opcode (as-is or part-decoded)

if we absolutely absolutely must make that a 48 bit scalar opcode,
then we have to make it a 48 bit scalar opcode.  this should be an
absolute last resort however.

l.