[Libre-soc-dev] efficient decoding algorithm for variable-length instructions

[Luke Kenneth Casson Leighton]

On 11/26/20, Jacob Lifshay <programmerjake at gmail.com> wrote:

> Full remapping everything dies; having a v3.1B compatible
> 16/32/48/64-bit format lives still (assuming I can convince everyone).

1) the fact that 14 Major Opcodes are needed for SV makes its chances
of merging with Standard v3.2+ for general adoption to be a grand
total of "flat-out zero" without safe isolation.

2) one Silver OPF Member has already raised concerns and will outright
reject proposals that are not isolated behind privileged operations.

3) with the need to execute code in the same executable that is both
Standard v3.0/1/2+ AND SV-encoded still isolated the only technically
sane way to do that which does not compromise either our goals or
those of OPF Members is: a VLE-like page-marker.

4) letting the OPF ISA WG decide on only two Major Opcodes for
scalar-Compressed for v3.2+ will fit their procedures and practices
and make them happy.

the expectation that they will accept SV taking over 14 major opcodes,
displacing twi, tdi, mulli, lq, sc, attn *and* the entirety of VSX, is
completely unrealistic, we need to recognise and accept this and then
take advantage of it.

implications are:

a) v3.2+ with Compressed would be 16/32/64 (no 48).  although 2
OPF-officially-selected EXTNNNs would be used, SV would *not* be
supported.

b) v3.2+ 48-bit could be hypothetically considered, providing prefix
space that adds predication to VSX.  although it may be easier to add
via EXT001 64bit, at least it opens up options.

c) SV is free and clear to do a (reasonable, minor) shuffle behind the
VLE-like isolation barrier, adopting full 16/32/48/64 encoding and
basically within reason doing whatever we like / need.  still has to
be signed off by OPF but as a privileged op it'll be fine.

l.