long double (was "strtold?")

[Jeff Johnston]

Ken Werner wrote:
> On Monday 30 March 2009 11:44:37 Ken Werner wrote:
>   
>>> If the platform normally prepends an underscore to a C function, you are
>>> not going to call
>>> the correct C math functions and the linker is going to fail.  Feel free
>>> to correct me if I have misinterpreted
>>> this.
>>>       
>> I see your point. How does the prepend mechanism work on those platforms? I
>> guess calling the correct function could be achived by conditionally
>> prepend the underscore using macro substitution.
>>     
>
> The GCC defines __USER_LABEL_PREFIX that could be handy.
>
>   
>>> Thus, I would like to see this implemented as it is done for
>>> DOUBLE_IS32BITS.  The functions
>>> are declared and implemented as calls to the double versions with casts.
>>>       
>> Implementing these stubs would work but it would increase the code size
>> too. The GCCs aliasing mechanism might be an alternative. In that case the
>> mapping needs to be done in the translation unit of the referred symbol.
>>
>> The mechanism described in GCCs info page 5.36 "Controlling Names Used in
>> Assembler Code" allows the users code to link against the double
>> counterparts. This could help architectures where the long double is going
>> to change in the future. However, I'm not sure if this approach is
>> compliant with the C99 standard.
>>     
>
> We found an actual problem using the  __asm__ approach. The GCC build fails 
> for libgfortran. The configure script checks whether the use of the log10l 
> function fails to link and sets a corresponding flag called HAVE_LOG10L. The 
> c99_functions.c of libgfortran includes <math.h> which maps log10l to log10 if 
> my patch is applied. libgfortrans log10l function itself calls the log10 and 
> you're stuck in an infinite loop. Such things may happen to other code too. So, 
> using the __asm__ mapping method seems not to be the best idea if you can't 
> touch the compiler and/or the source code.
>
> Mapping the long double functions using GCCs __attribute__ (alias) mechanism 
> also has its flaws. Beside from the fact that the aliasing need to be done in 
> the same translation unit and is only available on GCC (and compatible) it 
> assumes the calling convention for long double arguments is the same as for 
> double args. Most likely this is true but it's not guaranteed.
>
> All in all it looks like implementing small wrapper functions that just call 
> their counterparts seems to be the way to go - as you suggested. : )
>
>   
Ok, great.  It should not be a code-size issue as you earlier 
mentioned.  Any application that calls
a C library function has to expect something gets linked in.  A small 
stub that calls another function
is hardly surprising.
> For the SPU target I'd like to use GCC aliasing to save code size and don't 
> pay the penalty of an extra function call. I'll post a patch as soon as I find 
> some time.
>
>   
If you do an SPU-only solution, a preferred way would be to add a 
machine/math.h extension to math.h and then have a 
libc/spu/machine/math.h file.  In libc/include/machine have a math.h 
that defaults to empty for everyone else.

-- Jeff J.
> Regards
> Ken
>