FLOATING POINT with rtems

Daniel Hellstrom daniel at gaisler.com
Fri Dec 6 15:31:38 UTC 2013


On 12/05/2013 05:15 PM, Jiri Gaisler wrote:
>
> On 12/03/2013 11:52 AM, Sebastian Huber wrote:
>> On 2013-12-03 10:10, Jiri Gaisler wrote:
>>>
>>> On 12/03/2013 09:02 AM, Sebastian Huber wrote:
>>>
>>>> Recent GCCs will use (at least on PowerPC and ARM) floating point registers for integer operations if the register pressure is high for example.  So this separate integer/floating point context is an anachronism on these targets. Due to this the VFP/Neon on ARM and the
>>>> SPE/Altivec for PowerPC context is part of the normal thread context since also interrupt handlers may use the floating point unit (GCC may use for example the multi-byte vector copy operations).
>>>>
>>>> Are the soft-float and hard-float ABIs compatible on SPARC?
>>> Yes, floats/doubles are always passed in integer registers.
>> Ok, this is good.
That holds for arguments, unfortunately is floating point return values passed in %f0 and %f1 depending on precision.

Regards,
Daniel

>>
>> The only drawback I see at the moment is that, in case we don't use the FPU, then we still reserve space for the FPU contexts in the workspace and carry some dead code around.
>>
>> The current situation is confusing for users.  So we should either add a FPU BSP variant or use the proposal from Jiri.
> There is an issue with a FPU bsp. If a non-FPU task will call an RTEMS primitive
> where the compiler has used %fp registers for integers, an exception will occur.
> So all tasks must have the floating-point attribute if the kernel is compiled
> with -mhard-float.
>
> The only solution I see is to compile the kernel with -msoft-float and SPARC_HAS_FPU=1.
>
> Jiri.
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users




More information about the users mailing list