Plugin-based opcode table

[Luke Kenneth Casson Leighton]

On Sun, May 29, 2022 at 3:30 AM Peter Bergner <bergner@linux.ibm.com> wrote:

> I'm just catching up on my email backlog after being on vacation last
> week,

nice. i mean the vacation :)

> but I agree with everything Alan said and also agree with how
> you're going about things.

appreciated the reassurance.  i'm not going to get over being
nervous about adding to EXT01 (25% of v3.1 prefix space),
and to EXT019, 005 and 004, before all these have been
approved by the OPF ISA Working Group.

certainly, the 005 and 022 (sandbox) opcodes will *not* be
permanently in the places we'll initially submit them in.  004 we can
make a good case for madded and divmod2du [0] staying where
proposed.

still, the good news is that people can go "oh, er, so that's what
the Libre-SOC team plans to propose to add to Power ISA,
i didn't quite have time to work it out before".

> 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.

yes, we aim for the SFFS (Scalar Fixed Floating Point Subset) subset,
described right at the very beginning of the Power ISA Spec (page viii)
and have confirmed with Mendy that it's fine to add whatever you like:
we therefore choose to add BE, AMO, TLBIE and a RADIX MMU in
order to run scalar Linux. following microwatt, basically [1]

keenly aware that a corresponding revival of runtime capability detection
is needed in glibc6 there (removed a few years ago because noone was
using it, because there was only POWER8/POWER9) but one step at
a time.

> 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.

fortunately as an entirely from-scratch design with a focus on mass-volume
general-purpose compute we have no legacy instructions to support.

> 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!).

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.

a solution here is to set the PCR bit that flips back to POWER8
compatibility. if that's protected it would be necessary to have a
kernel syscall call to flip back and forth. performance would
suck, but at least runtime binary compatibility would be achieved
and people don't scream [except to hoot somewhat in derision
at such a terrible hack, but hey].

now imagine - even worse - that there's no PCR register bit that
can be deployed to flip back and forth between POWER8 and POWER9
compatiblity.

now imagine that this happens on two or more high-profile public uses of
the Sandbox (EXT022).  the spec said it was "perfectly ok". page xii

    "Facilities described in proposals that are not adopted
    into the architecture may be implemented as Custom Extensions
    using the architecture sandbox"

this is the nightmare scenario that i'd like to see avoided [understatement]

we've another meeting coming up, wed 01jun2022, i have an idea to
put in a proposal for some "pre-reservations" of opcode space as ISA
RFCs. my biggest concern is that there's no two-way communications
path to the IBM Engineers submitting instructions for future IBM
POWER 11/12 designs. we have no idea - at all - whether there's
already a conflict.

l.

[0] https://libre-soc.org/openpower/sv/biginteger/
[1] https://shenki.github.io/boot-linux-on-microwatt/