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

[Aleksandar Kostovic]

>
> you forgot rs2. some ops (shift, mulhsu, sub, div, mod, etc.) are not
> commutative, so it'd be nice to have both scalar<<vector and
> vector<<scalar.


So you are suggesting that we should builds custom op codes that take like
a range of scalars and turn it into a vector and opcodes that take vectors
and broke it down into scalars?

Sorry if this has been asked before, but i am trying to grasp all the
things right now.

On Sun, Jan 27, 2019 at 4:46 PM Jacob Lifshay <programmerjake at gmail.com>
wrote:

> On Sun, Jan 27, 2019, 06:20 Luke Kenneth Casson Leighton <lkcl at lkcl.net
> wrote:
>
> > On Sunday, January 27, 2019, Jacob Lifshay <programmerjake at gmail.com>
> > wrote:
> >
> > >
> > > For my previous prefix proposal, I just assumed that the encodings used
> > in
> > > OP-32 would be a subset of the encodings in OP, which seemed pretty
> > > rational as there's still plenty of unused space.
> > >
> > >
> > Yehyeh. And you can see why the decisions were made. AND is left out
> > because obviously, AND of 64 bit is no different from AND of 32 bit, just
> > drop the top 32 bits.
> >
> > However other ops that may not be emulated by chopping the top 32 bits,
> > these have their own OP32.
> >
> > The assumption has been designed around non-vector engines, basically. It
> > would be madness to add special 16 bit scalar ops to a 64 bit system,
> total
> > waste of opcode space.
> >
> > Vector and SIMD is a completely different story. Now performance matters.
> > Doing 8 bit ops using 64 bit ALUs is utterly wasteful.
> >
> > Unfortunately, adding custom 8/16 bit ops is not a viable option - not if
> > SV is to be a general parallel processing  abstraction layer, that is.
> > Using one custom 32 bit opcode for a hybrid Prefixed-Compressed extension
> > is about as far as we can push it (or reuse the RVV space).
> >
> > The brownfield encoding space may end up being used for future
> extensions:
> > xBitManip being the most likely candidate.
> >
> From what I saw last time I looked at the public info, they ended up using
> some more of funct7 similar to how the M extension does rather than using
> something that is different between OP and OP-32
>
> >
> > So where are we. 12 bits.
> >
> > * 5 bits vlpr5
> > * 1 for rd (or 2? issue with 32bit ops)
> > * 1 for rs (or 2?)
> >
> you forgot rs2. some ops (shift, mulhsu, sub, div, mod, etc.) are not
> commutative, so it'd be nice to have both scalar<<vector and
> vector<<scalar.
>
> > * 2 for elwidth, on arith ops?
> >
> fp arith ops have width builtin, so only needed on int ops
>
> > * LD/ST contains 8/16/32/64 in op already. Use 2 bits for stride etc
> mode?
> > * 1 spare
> >
>
> Jacob
>
> >
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>