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

[Luke Kenneth Casson Leighton]

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.

So where are we. 12 bits.

* 5 bits vlpr5
* 1 for rd (or 2? issue with 32bit ops)
* 1 for rs (or 2?)
* 2 for elwidth, on arith ops?
* LD/ST contains 8/16/32/64 in op already. Use 2 bits for stride etc mode?
* 1 spare




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