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

[Jacob Lifshay]

On Thu, Nov 26, 2020, 04:41 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> 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.
>

In the scheme I'm proposing Compressed instructions only need 1 primary
opcode (opcode 5). The other opcode (opcode 0) is used for new 32/48-bit
instructions (totally left alone if we're leaving out 48-bit in
non-GPU-mode and can cram the new 32-bit instructions into already
partially-occupied primary opcodes).

>
> 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.
>

I think it can be done in much less than that (would fit entirely into the
scheme I proposed with 32/48-bit in opcode 0, 64-bit in opcode 1 shared
with v3.1 instructions), I'll make a prototype soon.

Jacob