PPC binutils opcodes

[Luke Kenneth Casson Leighton]

On Thu, May 12, 2022 at 7:32 AM lkcl <luke.leighton@gmail.com> wrote:

> given that we have used up the entirety of EXT022 [1] with bitmanip
> and other Draft instructions, and have had to allocate some in EXT019
> [2], others in EXT004 [3], and even more in EXT005 (Draft ternlogi,
> grevlogi from [1]) , this is kinda important to know.
>
> (Alan, i have raised this with the OPF Board of Directors).

Sorry Alan, follow-up: strictly speaking the use of 25% of the EXT01
64-bit Prefix by SVP64 is *also* "unauthorised" [DRAFT].  made
slightly worse there by the fact that the entirety of the EXT01 Prefix
has no Sandbox areas at all: i don't think OPF expected anyone
to want to use 64-bit prefixes quite so soon, let alone take up 25%
of the reserved encoding.

one of the reasons i'm being so strict / a stickler about this is
because 3 years ago i did a comprehensive equivalent analysis for
RISC-V. that spec has a similar "grey-area" problem where Custom
(Sandboxed) Opcode space could become "de-facto common usage",
where hundreds of thousands of developers demand upstreaming
of unauthorised, rogue instructions that were Sandboxed *exactly
as the spec says is perfectly ok*.  or, worse, indefinitely maintain
hard-forks of binutils, gcc and llvm with the rogue instructions
dominating the Sandbox area.

which is "fine" [it's not] right up to the point where a *second* peer
(mass-volume level) of the first processor tries exactly the same thing.
at which point the nightmare conflict - completely out of the hands of
the Foundation at that point - is in full swing and cannot retrospectively
be corrected because there's too much product already out there
in the hands of users.

all "strictly perfectly fine because the spec says using the Sandbox area is ok"

l.