public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: linuxppc-dev@lists.ozlabs.org, Paul E Murphy <murphyp@linux.ibm.com>
Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.org
Subject: Re: [RFC Linux patch] powerpc: add documentation for HWCAPs
Date: Sat, 21 May 2022 10:11:48 +1000	[thread overview]
Message-ID: <1653091346.1a5h1ae3pd.astroid@bobo.none> (raw)
In-Reply-To: <c1f6c6c9-4cc7-0dcb-360d-9ae0df6378b4@linux.ibm.com>

Excerpts from Paul E Murphy's message of May 21, 2022 12:21 am:
> 
> 
> On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
>> This takes the arm64 file and adjusts it for powerpc. Feature
>> descriptions are vaguely handwaved by me.
>> ---
>> 
>> Anybody care to expand on or correct the meaning of these entries or
>> bikeshed the wording of the intro? Many of them are no longer used
>> anywhere by upstream kernels and even where they are it's not always
>> quite clear what the exact intent was, a lot of them are old history
>> and I don't know what or where they are used.
>> 
>> I may try to get these descriptions pushed into the ABI doc after a
>> time, but for now they can live in the kernel tree.
>> 
>> Thanks,
>> Nick
> 
> Thanks, this is really helpful.  I've been caught off-guard by some of 
> the subtleties in the meanings of these bits at times.  I think it would 
> be helpful to share what is implied by the usage of the word "facility" 
> below.  It would resolve some of my questions below.

Yeah that's probably a good point. In the introduction we can explain
that the facility is a class of instructions, registers, and behaviour,
but that the specifics depend on the ISA version.

> 
> 
> 
>> +PPC_FEATURE_HAS_ALTIVEC
>> +    Vector (aka Altivec, VSX) facility is available.
> 
> I think "(aka Altivec, VSX)" might be more accurately stated as "(aka 
> Altivec)"?

Yes VSX is a thinkso, should be VMX as pointed out.

>> +PPC_FEATURE_HAS_DFP
>> +    DFP facility is available.
> 
> Maybe something like "Decimal floating point instructions are available 
> to userspace.  Individual instruction availability is dependent on the
> reported architecture version."?

Yep, we can cover all these with a note in the intro.

>> +PPC_FEATURE_HAS_VSX
>> +    VSX facility is available.
> A small reminder the features are also dependent on architecture version 
> too might be helpful here too.
> 
> 
>> +PPC_FEATURE2_TAR
>> +    VSX facility is available.
> 
> Was manipulating the tar spr was once a privileged instruction, is this 
> a hint userspace can use the related instructions?

It can be disabled with facility control, and I guess there was
some consideration for how it might be used, e.g., "system software"
could use it for its own purpose then clear the bit for the application.

In practice I don't really know what makes use of this or whether
anything sanely can, it's marked reserved in the ABI. Would be 
interesting to know whether there is much benefit to use it in the
compiler. The kernel could actually use it for something nifty if we
were able to prevent userspace from accessing it entirely...

>> +
>> +PPC_FEATURE2_HAS_IEEE128
>> +    IEEE 128 is available? What instructions/data?
> 
> Maybe something like "IEEE 128 binary floating point instructions are 
> supported.  Individual instruction availability is dependent on the
> reported architecture version."?

Right, I just didn't know what architectural class of instructions
those are. Is it just VSX in general or are there some specific
things we can name?

>> +PPC_FEATURE2_SCV
>> +    scv instruction is available.
> 
> I think it might be clearer to say "This kernel supports syscalls using 
> the scv instruction".

Yeah good point.

>> +PPC_FEATURE2_MMA
>> +    MMA facility is available.
> 
> Maybe another note that specific instruction availability may depend on 
> the reported architecture version?

Thanks,
Nick

  parent reply	other threads:[~2022-05-21  0:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-20  5:15 Nicholas Piggin
2022-05-20  9:21 ` Michael Ellerman
2022-05-20 12:06   ` Nicholas Piggin
2022-05-20 14:21 ` Paul E Murphy
2022-05-20 17:42   ` Segher Boessenkool
2022-05-21  0:11   ` Nicholas Piggin [this message]
2022-05-23 14:19     ` Paul E Murphy
2022-05-20 16:58 ` Peter Bergner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1653091346.1a5h1ae3pd.astroid@bobo.none \
    --to=npiggin@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=murphyp@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).