This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: GAS .fpu directive
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Nicholas Clifton <nickc at redhat dot com>, Renato Golin <renato dot golin at linaro dot org>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Wed, 20 Aug 2014 17:22:09 +0100
- Subject: Re: GAS .fpu directive
- Authentication-results: sourceware.org; auth=none
- References: <CAMSE1keWd0+uUS0fpaC3-yXsnN-z2_Bsa5anwvQAQwXgWuw_Yw at mail dot gmail dot com> <53F4C261 dot 8090900 at redhat dot com>
On 20/08/14 16:44, Nicholas Clifton wrote:
> Hi Renato,
>
>> It seems GAS accepts .fpu anywhere in the file, and the meaning is
>> that it can change the FPU type mid-way through an assembly file, or
>> even in a block.
>
>> Is that intentional?
>
> No.
>
>> Is there any real usage for this kind of thing?
>
> Yes.
>
>> I naively assumed that .cpu / .fpu were like .eabi_attribute flags
>> that would tell what the *file* is, because normally one assembly
>> won't run on different machines at the same time.
>
> Correct.
>
>> The only use case I can think of is if there is a conditional jump
>> based on the existence of instructions, so a block that has neon is
>> only executed if there's no exception, but that still doesn't need a
>> .fpu vfp somewhere else.
>
> Right. Basically such an sceanario is theoretically possible, but it is
> unlikely that it will ever turn up in real code. The real reason why
> the directive is accepted anywhere is that it was just too much bother
> to write additional code to make sure that it is only used once, and
> then only in an appropriate place. Much easier to just let it be
> accepted anywhere and to rely upon the assembler programmer or the
> compiler to only generate one instance of the directive.
>
> Cheers
> Nick
>
>
>
Actually, I can think of use cases for this 'feature'. Consider a
function that will only be called when it is known that an ISA extension
is present (specifically, Neon). We then might want most of the code to
be marked as no-neon, but then to enable Neon for that function only.
I'm not sure that the current implementation really supports that at
present (it probably ends up setting the attributes incorrectly), but it
is at least conceivable.
R.