[Libre-soc-dev] svp64 and opcode_regs_deduped

[Luke Kenneth Casson Leighton]

On Wed, Dec 16, 2020 at 3:29 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> I think we'll need to go through the OpenPower base instructions and
> manually categorize them, since the categories in opcode_regs_deduped
> have some issues.

this is a... how-to-say... a laborious perspective that burdens us
with a massive amount of work.  the purpose of sv_analysis.py is to
save time.. *and* has a nice side-effect.

what i've been doing is using the categories as an opportunity to
double-check the CSV files (against decode1.vhdl)

since sv_analysis.py was written there have been *multiple* bugs in
the CSV files found - and fixed.  if you find any discrepancies please
do not mess about: *immediately* file a bugreport, this is quite
serious high priority, so make sure that's set in the bugreport,
because the mistake means that the 180nm ASIC is going out *with the
wrong behaviour*.

as part of that bugreport, the information should say what is noted
about it, and that the instruction is in an incorrect category.

> rlwimi is a good example: it is listed as 2R-1W-CRo but only has 2
> register fields but also can't really be a twin-predicated instruction
> since the first register is both read and written. I think the SVP64
> encoding for it should also have just 2 register fields.

good.  ok.  so this is a good example.  in this case, it is not that
"all the instructions should be categorised manually", it's that the
sv_analyse.py program needs to be modified to correctly take into
account this error (if it turns out to be one: i just did a quick
check and i believe it to be correctly categorised, but the reasoning
is best left to the bugreport and validated).

i already have one "non-standard" re-categorisation based on a string
match: "cr*" for cr ops.  there is no problem doing the same thing
with rlwimi.

so: let's discuss this one under the bugreport once it's raised.

> So, the encoding break-down needs to be based on both which
> inputs/outputs instructions have as well as how many register fields
> each instruction has.

great.  then let's get that encoded up in sv_analysis.py rather than
abandon it and land ourselves with 10 times the amount of work.

> This is really starting to remind me of x86 with
> all its weird and "wonderful" instructions -- too bad RISC-V's not a
> good option any more, it is much cleaner.

i know.  i'm pissed, it means it costs NLnet a lot more.  but that's
reality.  ultimately though the stable base of OpenPOWER and its
reputation will serve us better.

l.