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