public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: Kinsey Moore <kinsey.moore@oarcorp.com>, gcc@gcc.gnu.org
Cc: Joel Sherrill <joel.sherrill@oarcorp.com>
Subject: Re: ARM Cortex-R5F Support
Date: Wed, 2 Mar 2022 11:49:41 +0000	[thread overview]
Message-ID: <fe42da69-30f8-42b5-e6df-5dab3dbb36c0@foss.arm.com> (raw)
In-Reply-To: <cb5c7cdd-d41a-b930-9179-d18d9bcf2e3f@oarcorp.com>



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.

HTH,
R.

> 
> Thanks,
> 
> Kinsey
> 

  reply	other threads:[~2022-03-02 11:49 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 [this message]
2022-03-02 14:06   ` Kinsey Moore

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=fe42da69-30f8-42b5-e6df-5dab3dbb36c0@foss.arm.com \
    --to=richard.earnshaw@foss.arm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=joel.sherrill@oarcorp.com \
    --cc=kinsey.moore@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).