Plugin-based opcode table

[Paul Mackerras]

Just to clarify something below...

On Sun, May 29, 2022 at 10:13:06AM +0100, Luke Kenneth Casson Leighton wrote:
> On Sun, May 29, 2022 at 3:30 AM Peter Bergner <bergner@linux.ibm.com> wrote:
[snip]
> > 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!).
> 
> yowser that would have been painful. and a costly mistake that won't go
> away for at least another decade [i'm aware that IBM still gets 3rd parties
> asking to license POWER8, *for new designs*]
> 
> >  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.
> 
> ok. so this is good to know, because you know what it costs to have to
> support a conflicting opcode, long-term.
> 
> now imagine that a binary program needs *both* the old *and* the
> new behaviour of lxvx, in the same binary - in public usage. part
> of upstream binutils, part of upstream glibc6, and so on.

The problem Peter was describing was at the assembly level not the
machine code level.  The lxvd2x instruction still exists in POWER9 and
does the same thing that it does in POWER8.  POWER9 added a new
instruction which took over the "lxvx" mnemonic.  In big-endian mode,
lxvx and lxvd2x do the same thing (in little-endian, they differ by a
double-word swap).

That is, the difference is in what bits you get out of the assembler
when you write "lxvx", rather than a binary compatibility difference.

Paul.