This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 07/21] ARC: math soft float support
On Thu, 20 Dec 2018, Vineet Gupta wrote:
> I'm still ramping up on hard-float, so pardon some of my naivety. It seems the
> function calling convention is no different for soft-float vs. hard-float. We have
> a single register file (hard FP instructions inherently use an additional
> accumulator but that isn't really passed around so doesn't affect calling
> convention). Other than that SP values go normally in a reg, DP go in reg pair
> just as any 64bit value.
If you have only a single register file and the same calling convention -
and all struct layouts etc. are also the same - then indeed that would be
a single ABI (meaning that you only need one dynamic linker name for ARC
rather than two, if you only support one endianness). (On architectures
with separate register files, jmp_buf, ucontext etc. might sometimes
differ between hard and soft float, although often the space is still
there in the soft-float case, just not used.)
The ARM and RISC-V cases are ones where there are separate hard-float and
soft-float calling conventions - but *also* support for using hardware
floating point with the soft-float calling convention.
If you do have a single ABI, that indicates having bits/fenv.h contents
unconditional (because a soft-float compilation might legitimately end up
linking with a hard-float libm) - and thus indeed needing the internal
headers to disable certain math tests for soft-float. fpu_control.h
contents would still be conditional, however.
--
Joseph S. Myers
joseph@codesourcery.com