This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]