This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: GAS .fpu directive
- From: Renato Golin <renato dot golin at linaro dot org>
- To: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- Cc: Peter Bergner <bergner at vnet dot ibm dot com>, Richard Earnshaw <rearnsha at arm dot com>, Nicholas Clifton <nickc at redhat dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Date: Fri, 22 Aug 2014 15:21:37 +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> <53F4CB31 dot 9080701 at arm dot com> <1408553484 dot 5894 dot 8 dot camel at otta> <CAMSE1kdDQOuuKhPcF8qasM-PMXBkAKDfjioCmYc39cORV3o4gA at mail dot gmail dot com> <1408562067 dot 5894 dot 23 dot camel at otta> <CAMSE1kfq3CoxR8KWOo6dzgoR4CxyLqyA+_o=ZVU_MfJwHf8-mA at mail dot gmail dot com> <6D39441BF12EF246A7ABCE6654B0235320EF4632 at LEMAIL01 dot le dot imgtec dot org> <CAMSE1kdvh+uVriMQV1LeJJYGVY-g7BcO0ZVsESiGUeXs132eBw at mail dot gmail dot com> <6D39441BF12EF246A7ABCE6654B0235320EF47F9 at LEMAIL01 dot le dot imgtec dot org> <CAMSE1kfrQ5+tKZBywh6dx9VdXhrMosDdwsJUZV6LZm9oY6Mbqg at mail dot gmail dot com>
So,
The fact that:
.fpu vfpv2
vabs.f32 s1, s0
.fpu neon
vmov d0, d0
sets:
FP_arch: VFPv3
Advanced_SIMD_arch: NEONv1
and
.fpu neon
vmov d0, d0
.fpu vfpv2
vabs.f32 s1, s0
sets:
FP_arch: VFPv2
Advanced_SIMD_arch: NEONv1
tells me that:
1. Neon flags sets vfp3, but vfp2 flags don't unset NEON (which is kind of ok).
2. The last flag seen is what goes in the "module context" (aka build
attributes), and that's wrong
3. It's not possible, in ARM, to unset an .fpu/.cpu etc, making their
usage in .text dangerous (leaking assumptions)
4. Merging assembly files, inline assembly or partially linking files
may make the in-text-fpu setting very complicated to deal with
So, my proposal is to tackle one problem at a time:
Problem A:
Regarding module context (build attributes in ARM speak), command line
options should override header options (before .text or any
instruction or non-header directive). Non-header options should have
no change in module context.
So...
$ echo ".cpu cortex-a8" | as -mcpu=arm11
should produce ARM11 as CPU type.
$ echo ".fpu neon\n .text\n .fpu vfpv2" | as
should produce NEON+VFP3 as FPU/NEON types
Problem B:
Local fpu/cpu/arch options are undefined and will have rest-of-the
file context. It's up to the user to make sure they're right.
There are some ways of fixing this:
1. Create a push/pop semantics, like Power. That's probably unlikely
for ARM, but would be the best to have.
2. Define that those directives have function/section scope, so reset
to the module level value on next function definition/section.
3. Leave as is, but add .fpu/.cpu at the end of inline assembly blocks
with the global value to reset expected behaviour. Hand assembly would
still be at peril.
We can solve A before B. Does that make sense?
cheers,
--renato