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

[Luke Kenneth Casson Leighton]

On Tuesday, January 22, 2019, Jacob Lifshay <programmerjake at gmail.com>
wrote:

> On Tue, Jan 22, 2019, 03:04 Luke Kenneth Casson Leighton <lkcl at lkcl.net
> wrote:
>
> > On Tue, Jan 22, 2019 at 8:08 AM Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > > Changes to the proposal:
> > > I changed where elmsz comes from in integer size conversions, using
> > > OP-IMM/OP-IMM-32 to differentiate between unsigned/signed.
> > > I split the elmsz mapping into elmszd/elmszw to allow reordering to
> match
> > > the unprefixed sizes.
> >
> >  the thing about elwidth is that there needs to be one for the source
> > operands and a *separate* one for the destination register
> >
> >  otherwise, explicit operations are needed which perform
> > width-conversions.  which is feasible: special over-ride on MV / F.MV.
> >
> Width conversions are handled by conv for int to int, fcvt for fp to fp and
> int to/from fp.


The modes required are src dest elwidth, plus sign/zero extension, plus
truncation, plus when no width overide is in place, plus Vector Scalar
options, plus predication. If you have a look at the SV spec, the LD/ST
section, and the MV section, it covers how all of those can be done.


>
>  also, how is vector-scalar and scalar-vector to be specified?
> >
> We will have broadcast instructions


>
What are "broadcast" instructions?


> but may need to change the encoding for
> the more common operations to accommodate vector-scalar modes for
> power-efficiency and lower register pressure.


Changing the encoding has huge software implications.


> We could use the prefixed jal encoding as a different opcode for
> vector/scalar as jal is useless when vectorized.


>
There are a ton of non-vectoriseable ops, the problem is that there are
nowhere near enough.

I like the idea, the problem is that the entire vectoriseable opcode space
needs to be fitted into the overloaded space.

Plus all future opcodes.

So by overriding the jal and other space, the implications are as follows:

* the rule about not modifying opcodes has been discarded, which implies a
massive amount of compiler work
* the RV vectoriseable opcode space in no way fits in full.
* the decode of jal (and other ops) now just got much more complex in
hardware.

Remember that any modifications to the compiler toolchain have to be paid
for sonehow.

L.




-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68