public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kinsey Moore <kinsey.moore@oarcorp.com>
To: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>, gcc@gcc.gnu.org
Cc: Joel Sherrill <joel.sherrill@oarcorp.com>
Subject: Re: ARM Cortex-R5F Support
Date: Wed, 2 Mar 2022 08:06:48 -0600	[thread overview]
Message-ID: <fc001e13-2e38-95c2-2a83-236bb8271abf@oarcorp.com> (raw)
In-Reply-To: <fe42da69-30f8-42b5-e6df-5dab3dbb36c0@foss.arm.com>

On 3/2/2022 05:49, Richard Earnshaw wrote:
>
>
> On 01/03/2022 16:23, Kinsey Moore wrote:
>> Hi,
>>
>> I'm looking at working on Cortex-R5F support for RTEMS, but it seems 
>> as if latest GCC supports the Cortex-R5. This R5 has implicit FPU 
>> support which would make it really R5F. The ARM reference page on 
>> this core (https://developer.arm.com/Processors/Cortex-R5) specifies 
>> that the FPU is optional. I see that the FPU support can probably be 
>> disabled using the nofp option to achieve Cortex-R5 support, but I 
>> was wondering why this is handled differently from the Cortex-R4[F] 
>> support since that is broken out into two different CPU entries in 
>> gcc/config/arm/arm-cpus.in. It appears that R7 and R8 are handled the 
>> same way as R5.
>>
>> Is the R4/R4F just the legacy way of handling this and R5/7/8 are the 
>> new way?
>>
>
> Arm no-longer gives distinct product names for products that come in 
> multiple guises.  Another example of this is that many armv8-a 
> products have an optional crypto unit but have the same product name.
>
> So to answer your question more directly, the -mcpu=cortex-r5 will by 
> default be considered to have an FPU, provided that the compiler was 
> built with --with-fpu=auto (the default).  If you specify 
> --with-float-abi=soft, then even if the product has an FPU, or for 
> some cases a SIMD unit, then these will never be used.  So I'd recommend:
>
> For FP support: -mcpu=cortex-r5 -mfloat-abi=hard
> For no FP support: -mcpu=cortex-r5 -mfloat-abi=soft
>
> There's also a mid-way variant of -mcpu=cortex-r5 -mfloat-abi=softfp, 
> which would use the FP hardware but use the soft-float calling 
> conventions; this code is abi-compatible with the no-fp variant above.

Ah, ok. Thanks for that info. I guess ARM or their downstream vendors 
are just inconsistent about naming of those cores since I'm seeing R5F 
references in official documentation from the downstream vendors.


Kinsey


      reply	other threads:[~2022-03-02 14:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-01 16:23 Kinsey Moore
2022-03-02 11:49 ` Richard Earnshaw
2022-03-02 14:06   ` Kinsey Moore [this message]

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=fc001e13-2e38-95c2-2a83-236bb8271abf@oarcorp.com \
    --to=kinsey.moore@oarcorp.com \
    --cc=Richard.Earnshaw@foss.arm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=joel.sherrill@oarcorp.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).