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

[Luke Kenneth Casson Leighton]

On 11/26/20, Cole Poirier <colepoirier at gmail.com> wrote:

> Good. That seems to me essential. The lack of compatibility caused by
> needing it to be in our own mode will really undermine the usefulness of
> much of what we’re discussing here.

no it won't, and a Silver Member of the OpenPOWER Foundation
specifically requested that we find some sort of way to isolate
LibreSOC Mode in a way that requires some sort of privileged
operation.

a VLE-like page bit fits that request perfectly, giving us the
leverage to say "look, we are being reasonable, we are listening, and
we are actively engaging and being responsible".

it also by a happy coincidence allows us to explore Major Opcode
"reordering", safe dropping of Major Opcodes, and so on.

remember

WE NEED FOURTEEN MAJOR OPCODES for a successful deployment of SimpleV.

OPF has specifically said in the v3.0B and v3.1B spec that one (QTY 1)
opcode is a sandbox (for "unofficial" use), one (QTY 1) is an
"Official" candidate for a new "thing" and one more (QTY 1) is a very
reluctant 2nd priority "Official" candidate for a new "thing".

consequently there will be SERIOUS resistance to Compressed-Scalar
taking up BOTH those Official Opcodes, and the only reason it would be
considered would be because the benefits (25% or greater code
reduction size) are so massively high.

Simple-V, by contrast, i'm just not even going to bother putting it
forward to the OPF ISA WG unless it's behind an isolation barrier,
because by requiring FOURTEEN major opcodes (not one, not two:
FOURTEEN) it should be blindingly obvious that unless it's isolated
it's going to get flat-out rejected.

whilst initially i believed that a Program Compatibility Register
(PCR) bit was the best way to achieve that, i now realise that we need
to mix "standard" v3.0B,  v3.1B and SimpleV code into the same program
(Jacob gave a convincing argument that the code reduction size of
v3.1B is worthwhile)

LibreSOC SV code will be hand-coded Video Decode routines written by
Lauri, embedded into v3.0B/v3.1B standard encoded ffmpeg, gstreamer
and libavutil code.

the LibreSOC SV code will still *have* v3.1B 64 bit prefix
instructions... it's just that they'll be at a totally different Major
Opcode.

the only safe way to do that is a VLE-like page bit.

and, because that has precedent, the burden will not be on *us* to
justify *why* it should be allowed, the burden will instead be on the
OPF ISA WG Committee why *not*, and, with the VLE precedent, it will
be hard for them to say no.

basically we need to mentally model the behaviour of the "black box
known as the OPF ISA WG" as part of the development of the extensions,
and make use (nicely) of Paul as a gateway to test out hypotheses of
what might pass.

l.