[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:

> The problem is that the work done 18 months ago works on RISC-V, not Power.
> We would be severely constraining ourselves if we try to force it to work
> without any adaptation.

right.  so.  this is exactly what i have been thinking on for many
months in the background, and what the "register profile
categorisation" page is for (the one that, if you recall, you didn't
quite understand why it was needed).

the purpose of that page, which involves analysing the CSV files
breaking them into "NR-MW" groups (not the same as the pipeline reg
profiles but similar), leaves us with an extremely small amount of
work to go, *by category*:

* that one matches RV I-Form
* that one matches RV FR4-Form

at which point, we're done [with no duplication of the months of
effort previously spent on SVP]

now, obviously, C isn't going to *have* a profile because we never did
that analysis (never did an SV-C32).

whilst the number of OpenPOWER opcodes is ridiculously large, the
number of register-profiled "categories" is really very small: 17
arithmetic and 8 LDST.

https://libre-soc.org/openpower/opcode_regs_deduped/

of those 8 LDST, i would be very surprised if they could not be
covered by one single SVPrefix (the one we already developed, the only
thing to think through is LD/ST-update)

and of the 17 arithmetic there several are highly likely to be covered
by the same categories (2R1W same as 2R for example, and CRs likely to
be synonymously associated with the input vector and/or output vector,
and so on).

[it'll be hard-slog-work but whatever route is taken that slog-work
still has to be done]

my biggest concern is that, knowing how long it's going to take, and
knowing *in advance* that a single EXTNNN *does not have enough bits*
to do *one* of P48 or P64, let alone share them all.

and thus the entirety of the prior SVPrefix work would have to be
completely and utterly discarded by going down the route of forcing
things into one (or a shared!) EXTNNN, it should be pretty clear that
this is going to be a minimum of three to four months additional work.

whereas simply looking at each of the 8+17 categories and seeing if
they match with RVC XX-Forms, this is a near-trivial 1 hours work or
less to do a preliminary viability assessment.

and if that assessment even comes up with an 80% match then we just
saved 4 months total redesign time.

does that make sense? i haven't gone into depth on this because it
hasn't been the right time, however i have been thinking this through
and planning a strategy for about... a year, just to make sure that we
don't throw away the time wasted by the RISCV Foundation's
intransigence.

l.