Re: Plugin-based opcode table

[Peter Bergner <bergner@linux.ibm.com>]

On 5/23/22 8:06 AM, Dmitry Selyutin via Binutils wrote:
> On Mon, May 23, 2022 at 3:59 PM Alan Modra <amodra@gmail.com> wrote:
>> I don't see any need for the artificial boundaries you might get with
>> a plugin, whatever that might look like.  ppc-opc.c already supports
>> multiple incompatible powerpc cpu implementations, including ones that
>> depart significantly from current powerpc ISA documentation.
> 
> Alan, please, correct me if I'm wrong: does it mean that we can just
> stick to marking new instructions and facilities with a custom per-CPU
> flag? For now I introduced the -mlibresoc CPU which enabled the
> PPC_OPCODE_SVP64 flag, and marked some new instructions appropriately
> with this flag. Would that be OK if we follow this approach?

I'm just catching up on my email backlog after being on vacation last
week, but I agree with everything Alan said and also agree with how
you're going about things.

That said, I assume your -mlibresoc flag enables more than just the
PPC_OPCODE_SVP64 flag, since there is a lot of "base" POWER instructions
like addi, etc. that I'm sure your cpu implements.  If for some reason,
one of those "base" instructions enabled by -mlibresoc isn't implemented
by your cpu or conflicts in some way with your new instructions, you
can add the PPC_OPCODE_SVP64 to the deprecated field for the problematic
instruction to disable it when using -mlibresoc.

For example, POWER9 uses all the flags POWER8 enables plus PPC_OPCODE_POWER9.
However, the "lxvx" instruction changed between POWER8 (where it was an
extended mnemonic for lxvd2x) and POWER9 where is became a real instruction
with a different opcode than lxvd2x (I'm ignoring that doing that was
a very bad idea!).  How that was solved, was adding PPC_OPCODE_POWER9
to the old lxvx instruction's deprecated field to disable that on POWER9
and later cpus.  POWER9 and later cpus get the new lxvx instruction,
because we enable it with the PPC_OPCODE_POWER9.

Peter