PPC binutils opcodes

PPC binutils opcodes

[Dmitry Selyutin]

Hello folks,

long time no news. We're still extending PowerPC with SVP64
extensions[0], and, as part of this large task, we're updating
binutils respectively[1].
With the recent commit[2], I've hit the limit on count of operands
stored in powerpc_operands array, and now I'm somewhat unsure of how
to address it.
The trivial and obvious solution to increase the size of the operand
index[3] can be done, but it appears there is another obstacle this
time[4].

Considering fx_pcrel_adjust field, it appears to be shared and it has
exactly 8 bits[5]. This is enforced by the assertion above, but also
by other places[6].
The logic around the fx_pcrel_adjust field prevents me from adding new
operands; even if I increase the operand index size, I will for sure
hit other limitations.

So I thought the best option would be to ask for your help and ideas
on this. Could you, please, suggest the correct way to add new
operands but keep the logic around this field intact or, well,
working?

I tried checking the code around regarding fixups, but I'm currently
struggling to understand what happens there. Any help or tips are
highly appreciated.
Ideally I'd like to re-use already existing mechanisms for adding new
instructions and keep the original code as intact as possible.

[0] https://libre-soc.org
[1] https://git.libre-soc.org/?p=binutils-gdb.git;a=log;h=refs/heads/svp64
[2] https://git.libre-soc.org/?p=binutils-gdb.git;a=commit;h=dfa9e48a625faee0f70252c7fbf2cd7a0343f8f1
[3] https://git.libre-soc.org/?p=binutils-gdb.git;a=commit;h=b4a728e26f4c364f1a4d365c3c4e5e2441f70a5e
[4] https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=c3439a6cd6098ba36d38b1ff55bf6430b45bd4e2;hb=refs/heads/svp64#l1642
[5] https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/write.h;h=501bdd828fc96e423a689141ab425743f484da3c;hb=refs/heads/svp64#l78
[6] https://git.libre-soc.org/?p=binutils-gdb.git;a=blob;f=gas/config/tc-ppc.c;h=c3439a6cd6098ba36d38b1ff55bf6430b45bd4e2;hb=refs/heads/svp64#l7061

Re: PPC binutils opcodes

[Luke Kenneth Casson Leighton]

(please do reply cc as i am subscribed digest, thank you for understanding)

On Wed, May 11, 2022 at 10:24 AM Dmitry Selyutin <ghostmansd@gmail.com> wrote:

> The trivial and obvious solution to increase the size of the operand
> index[3] can be done,

direct to the diff may be helpful:
https://git.libre-soc.org/?p=binutils-gdb.git;a=commitdiff;h=b4a728e26f4c364f1a4d365c3c4e5e2441f70a5e;hp=bdb7c7d203c3f155e5e2834b7781c0fd173d5e6c

another helpful resource: a machine-readable version of the fields, taken
from the v3.0B specification, verbatim:

https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=openpower/isatables/fields.text;h=eb962688ca674db58b65100a159c1b20cfbbb886;hb=e4142b9e970ae21639ed5a8884d193f57ffc463a#l294

aside from the Draft SVP64 fields i am only seeing appx 130 v3.0B fields.
if not for pseudo-fields there should have been plenty of room.

with the OpenPOWER Foundation inviting others to add Custom Extensions
and also the OPF ISA WG being set up and welcoming contributions to the
Power ISA it would be anomalous that binutils has this built-in limit on the
number of potential opcode fields.  we happen to be the first to encounter
that limit.
https://openpowerfoundation.org/groups/isa/

l.

Re: PPC binutils opcodes

[Alan Modra]

On Wed, May 11, 2022 at 12:24:21PM +0300, Dmitry Selyutin wrote:
> Hello folks,
> 
> long time no news. We're still extending PowerPC with SVP64
> extensions[0], and, as part of this large task, we're updating
> binutils respectively[1].
> With the recent commit[2], I've hit the limit on count of operands
> stored in powerpc_operands array, and now I'm somewhat unsure of how
> to address it.

Yes, we are getting close to the limit on mainline, 241 entries.

> The trivial and obvious solution to increase the size of the operand
> index[3] can be done, but it appears there is another obstacle this
> time[4].
> 
> Considering fx_pcrel_adjust field, it appears to be shared and it has
> exactly 8 bits[5]. This is enforced by the assertion above, but also
> by other places[6].

Increasing the size of fx_pcrel_adjust should be fine, adjusting the
assertion and removing the silly mask to 8 bits.  Another option
is to add a field to tc-ppc.h:_ppc_fix_extra and use that instead of
fx_pcrel_adjust in tc-ppc.c.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PPC binutils opcodes

[Dmitry Selyutin]

On Wed, May 11, 2022 at 4:13 PM Alan Modra <amodra@gmail.com> wrote:
> Increasing the size of fx_pcrel_adjust should be fine, adjusting the
> assertion and removing the silly mask to 8 bits.  Another option
> is to add a field to tc-ppc.h:_ppc_fix_extra and use that instead of
> fx_pcrel_adjust in tc-ppc.c.

As I've just found, to my confusion, we actually have a way to reach
the desired goal by simpler actions. Right above fx_pcrel_adjust,
there's yet another 10-bit field, called fx_unused. It's indeed not
used yet. I suggest allocating 8 bits out of it, and make opindex at
include/opcode/ppc.h:powerpc_opcode an unsigned short (or, ideally, I
suggest using uint16_t: ppc.h already uses stdint.h anyway).

We could use less bits than 8, but, since the operand size is going to
take at least 16 bits anyway and to avoid similar problems in the
future. Hopefully 16 bits will be sufficient.
I'll prepare the patch. Alan, could you, please, help me with tests I
need to check? It'd be great if there's some CI to use: my environment
is somewhat rusty and slow.

Re: PPC binutils opcodes

[Luke Kenneth Casson Leighton]

(thanks kindly for cc'ing alan)

On Wed, May 11, 2022 at 2:13 PM Alan Modra <amodra@gmail.com> wrote:

> Yes, we are getting close to the limit on mainline, 241 entries.

Matrix-Multiply-Assist and etc. from Power ISA 3.1 i presume, which have
new Forms and new operand field names?

btw what's the best advice for submitting Draft work? we're attempting
to keep to the Sandbox EXT022 but at some point we're going to run
out of space there.  is there a "--draft" or "--experimental" flag
that can be set?
or is it something that is fine under a new CPU name (e.g. -mlibresoc)?

given that the Power ISA is both Trademarked and controlled by the
OpenPOWER Foundation, i quite understand if the answer is,
"You Don't - not until it's ratified by the ISA WG".

a potential compromise between the pain-in-the-ass of having to maintain
an indefinite fork on the one hand and accidentally becoming the de-facto
dominant "occupier" of EXT022 would be a dynamic-loadable module
system.

[although, how the heck that would work for SVP64 Prefixing will
be a bit of a handful].

l.

Re: PPC binutils opcodes

[Dmitry Selyutin]

On Wed, May 11, 2022 at 10:46 PM Luke Kenneth Casson Leighton
<lkcl@lkcl.net> wrote:
> is there a "--draft" or "--experimental" flag
> that can be set?
> or is it something that is fine under a new CPU name (e.g. -mlibresoc)?

It seems that these are logically the same from the point of binutils:
it even looks like there are -future, as well as stuff like -mspe and
-mvle. We, for now, use -mlibresoc[0]. So, as a matter of fact, there
is, and we use it. But I'd also be interested to know whether this
should be handled differently than it is now.

[0] https://git.libre-soc.org/?p=binutils-gdb.git;a=commit;h=a1e12c31e28e8c630ad129fd672c25779b360d5f

Re: PPC binutils opcodes

[Alan Modra]

On Wed, May 11, 2022 at 08:46:16PM +0100, Luke Kenneth Casson Leighton wrote:
> (thanks kindly for cc'ing alan)
> 
> On Wed, May 11, 2022 at 2:13 PM Alan Modra <amodra@gmail.com> wrote:
> 
> > Yes, we are getting close to the limit on mainline, 241 entries.
> 
> Matrix-Multiply-Assist and etc. from Power ISA 3.1 i presume, which have
> new Forms and new operand field names?

The most recent change that added two dozen or so entries was removing
powerpc_macros.  Moving those extended instructions into the main
powerpc_opcodes table meant writing a bunch of insert and extract
functions to poke operands into the underlying instruction fields, and
of course they need new entries in powerpc_operands.

> btw what's the best advice for submitting Draft work? we're attempting
> to keep to the Sandbox EXT022 but at some point we're going to run
> out of space there.  is there a "--draft" or "--experimental" flag
> that can be set?
> or is it something that is fine under a new CPU name (e.g. -mlibresoc)?

I don't see any reason why you shouldn't use -mlibresoc or whatever
you choose.  The nonsense over -mfuture was entirely non-technical:
The non-engineering parts of IBM hadn't decided the naming of
power10.

> given that the Power ISA is both Trademarked and controlled by the
> OpenPOWER Foundation, i quite understand if the answer is,
> "You Don't - not until it's ratified by the ISA WG".

Also not a problem as far as the binutils project is concerned.
Experimental and/or subject to change is fine, so long as you don't
break other cpu support.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PPC binutils opcodes

[lkcl]

On May 11, 2022 9:06:38 PM GMT+01:00, Dmitry Selyutin
<ghostmansd@gmail.com> wrote:

> -mvle. We, for now, use -mlibresoc[0]. So, as a matter of fact, there
> is, and we use it. But I'd also be interested to know whether this
> should be handled differently than it is now.
>
> [0] https://git.libre-soc.org/?p=binutils-gdb.git;a=commit;h=a1e12c31e28e8c630ad129fd672c25779b360d5f

my question is whether unapproved Draft instructions should be
permitted upstream *at all*. given that we are the first group to ever
design new instructions outside of IBM and the OPF Membership and will
be the first to utilise the upcoming ISA WG "External Contributor" RFC
Process this has never come up before.

a dynamic loadable plugin would make it clear that non-approved Draft
instructions may not be upstream where they could cause irrevocable
nightmare opcode conflict damage but at least is not massively
inconvenient to maintain for vendors wishing to develop Custom
processors using the Sandboxed (EXT022) opcode area.

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

l.

[1] https://libre-soc.org/openpower/sv/bitmanip/
[2] https://libre-soc.org/openpower/isa/svfparith/
[3] https://libre-soc.org/openpower/isa/svfixedarith/

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

Re: PPC binutils opcodes

[Peter Bergner]

On 5/11/22 6:38 PM, Alan Modra via Binutils wrote:
> On Wed, May 11, 2022 at 08:46:16PM +0100, Luke Kenneth Casson Leighton wrote:
>> btw what's the best advice for submitting Draft work? we're attempting
>> to keep to the Sandbox EXT022 but at some point we're going to run
>> out of space there.  is there a "--draft" or "--experimental" flag
>> that can be set?
>> or is it something that is fine under a new CPU name (e.g. -mlibresoc)?
> 
> I don't see any reason why you shouldn't use -mlibresoc or whatever
> you choose.  

+1

There is also no problem if your cpu uses a particular set of major and/or
minor opcode bits that another cpu already uses or a new cpu might use in
the future.  We already have multiple cases of this in the opcode table.
You just have to ensure that your cpu's bitmask (ie, the combination of
powerpc_opcode flags that describe what your cpu implements) doesn't enable
your new instruction(s) as well as any instruction(s) that have conflicting
opcode bits.

As Alan said, as long as you don't break other cpus, I think you're fine.

Peter

Re: PPC binutils opcodes

[Luke Kenneth Casson Leighton]

On Wed, May 18, 2022 at 4:32 AM Peter Bergner <bergner@linux.ibm.com> wrote:
> On 5/11/22 6:38 PM, Alan Modra via Binutils wrote:
> > I don't see any reason why you shouldn't use -mlibresoc or whatever
> > you choose.
>
> +1
>
> There is also no problem if your cpu uses a particular set of major and/or
> minor opcode bits that another cpu already uses or a new cpu might use in
> the future.

this is the bit that makes me jumpy / nervous, from a Specification
Management perspective.  it's where RISC-V, due to its popularity, is
inexorably and irredemably heading in the direction of a public opcode
conflict.

aside from being a niggle for developers (who have to specify
the right flags, but as you point out below they have to do that anyway),
then as long as there is no customer-need / drive / call from a *different*
vendor to utilise two or more operations that have publicly-conflicting
opcodes, everything's perfectly fine.

remember, we're not designing instructions that are intended for
specialist niche areas or are hidden behind proprietary compilers
where (thank you for describing this to me yesterday, Toshaan,
about the private IBM product) where yes the product is popular
but no its users are *not* permitted to compile their own source code,
they get binaries pre-compiled by the vendor (IBM), and it's the
vendor (IBM) that keeps the [conflicting] compiler entirely secret
and out of the public eye.  this is *not* of concern: such scenarios
can have as many conflicts as they like and there will be zero [public]
problems.

the driving motivation for what we're doing is as a Hybrid
CPU-VPU-GPU mass-volume target. one product family, able to do
the exact same job of ARM+MALI, or Intel i5/i7/i9 + i950 Graphics,
or AMD+Ryzen, and with the same expected popularity and market
reach of those products.

however unlike those products, instead of 2 disparate ISAs and
associated brain-melting userspace-kernelspace-GPUspace RPC
marshalling mechanisms across PCIe buses (aka, "a Graphics Driver"),
we're envisioning a single unified ISA that is *completely*
public and completely end-user-programmable.  you want a huge
Vector cosine operation? no problem, there's an opcode and
associated intrinsic for that, right here, right now.

a la ARM SVE2 and AVX-512, we fully expect, once people
get over the "disbelief" hump of a small team being able to
achieve this (and think at that level), that other vendors will
go "dang, we need those opcodes too, our customers are
already clamoring for them because of the performance
increase / power-reduction / etc."

and if those vendors happen to be *already using* that same
opcode space for other customers that they're already supplying
product to, long-term, and those customers fully expect to
recompile their source code right here, right now, using both
conflicting operations *in the same binary*, that is where the
nightmares begin.

opcodes that have been explicitly marked - officially - in the
spec - as deprecated, i have no problem with, because those
will be for legacy applications that will be covered by a PCR
bit anyway.

sotto voice: bottom line here is, the last thing we need is for IBM to
be pissed at us for wrecking their 25-year-old superb and highly
stable ISA, *even if we warned them loudly of the possibility!* :)


>  We already have multiple cases of this in the opcode table.
> You just have to ensure that your cpu's bitmask (ie, the combination of
> powerpc_opcode flags that describe what your cpu implements) doesn't enable
> your new instruction(s) as well as any instruction(s) that have conflicting
> opcode bits.

not a problem, technically :)  i am a little nervous about the quantity of
opcodes we're designing (and have been trying for 18+ months to draw
attention to that), but this is par-for-the-course: IBM's agreement
with Motorola 12 years ago stopped entry into anything other than the
Server Market, and there is a lot of catch-up to be done.

normally this job would be covered by *teams* of people, i mean, look
at how it's done in RISC-V, they have multiple ISA WGs with multiple
vendors contributing in each area.

* [0] madded (variant of madd with the 128-bit result split across 2
64-bit regs)
* [0] divmod2du (merging of div and mod results again into 2 64-bit regs)
* [1] transcendentals fsin fcos atan2 log1p exp1m etc. and DCT/FFT ops
* [2] 6 CRweird instructions (much more powerful CR-field-level operations)
* [3] bitmanip operations with large immediates and/or operands (3-in 1-out)

to give you some idea of the scope:

* we're completely out of Sandbox EXT022 (combined bitmanip, SVP64)
* EXT05 is taken up entirely with 3 very-large-immediate bitmanip ops
* crweirds need to use EXT019 (a swathe of 32 just like addpcis and crops)
* madded/divmod2du need to go into EXT04 (same area as madd*) [5]
* transcendentals into EXT059 (joining other FP scalar ops)

when proposed as RFCs we'll need to propose using up *both* EXT05
*and* EXT09, the two areas i have a vague recollection of being the
areas marked in the spec as "if you want to officially propose something
that needs an entire opcode, use these".

once they've gone through the [new] OPF ISA WG RFC process, many
of the bitmanip X-Form operations currently jam-packed into EXT022
could be proposed to place in EXT031 or EXT019 but there are still two
groups of large-immediate, large-number-of-operands operations [4] that
cannot be merged into one, they'd have to be in both EXT05 and EXT09.

> As Alan said, as long as you don't break other cpus, I think you're fine.

i think / plan into the future (a long way), and there's a scenario that i am
able to visualise which is making me nervous [RISC-V has already hit it
and, as predicted ~3 years ago, there's no way back]. i appreciate it's quite
complex / specific, and i would like everyone to understand it in full.
what do you feel would be the best way to achieve that?

if the dlopen/dlsym plugin idea is a step too far, i think what we'll do is
add a "-mdraft" option as well. "-mlibresoc -mdraft".  firstly, i absolutely
do not want people to think that we're operating "rogue", here, and
secondly i want it to be very clear that we're acting responsibly, and in
no way want the Power ISA to have any possibility of long-term
irrecoverable damage.  we're expecting to use it for 20+ years, so
have to keep it clean.

l.

[0] https://libre-soc.org/openpower/isa/svfixedarith/
[1] https://libre-soc.org/openpower/isa/svfparith/
[2] https://libre-soc.org/openpower/sv/cr_int_predication/
[3] https://libre-soc.org/openpower/sv/bitmanip/
[4] https://libre-soc.org/openpower/isa/bitmanip/ - termlog* and grev*
[5] https://libre-soc.org/openpower/sv/biginteger/