PowerPC BSP mvme5500 and hardfloat.

[Till Straumann]

I agree with Sebastian. You must not mix code that was compiled with 
hard- and soft- float,
respectively. Newer linkers warn you about it.

If you don't believe it one example:

hardfloat ABI: when calling a vararg function (such as sprintf) the 
caller must set or
clear a certain bit in the CRC register depending on whether or not the 
argument list
contains FP arguments.

softfloat ABI: CRC bit is not touched/maintained/looked at.

therefore: if you e.g., call sprintf() (compiled with hard-float) from a 
soft-float unit
then (even assuming you don't pass any FP args) it is not guaranteed 
that the CRC
bit is cleared and sprintf() may do strange things or even crash.

I'm actually surprised - I thought we save/restore FP context across 
interrupts as well
(at some point I had added it for altivec) but looks like we don't. 
However, IIRC, the FPU is
disabled during execution of an ISR so you'll notice if the compiler 
does something
funny.

BTW: I have not, with recent gcc, seen implicit use of the FPU.

- Till

On 12/12/2013 06:47 AM, Sebastian Huber wrote:
> On 2013-12-12 15:26, Matt Wette wrote:
>> But if you don't use FP in ISR you still need to compile the ISR with
>> -fsoft-float because the compiler may dirty the FP registers otherwise.
>> For example: a = b; where a, b are struct timespec may be implemented in FP
>> registers.
> In case the ISR uses operating system services, then this is highly dangerous
> since operating system functions are not compiled with -msoft-float in this
> case.  Also on PowerPC the hard-float and soft-float ABIs are incompatible.
>
> The distinction between floating-point and non-floating-point tasks is
> questionable with modern compilers.
>