[Libre-soc-dev] svp64 and opcode_regs_deduped
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed Dec 16 07:58:38 GMT 2020
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
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
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.
More information about the Libre-soc-dev