PowerPC BSP mvme5500 and hardfloat.

[Till Straumann]

Looking at the code suggested that the FPU is disabled during execution
of exception handlers and interrupts. Because this is quite complex I also
ran a simple test (rtems 4.9.4) which confirms this: you definitely run
into an exception if you try to use the FPU from an exception handler or
ISR.

For the same reasons we have made all threads implicitly FP threads
I believe that it would be a good idea to also save (volatile) FP context
across exceptions. The code would not be very complex and it could
be added in proximity to where altivec context is saved/restored.

- Till

BTW: AFAIK the current code saves/restores all FP registers when performing
a task context switch - wouldn't it be enough to just save/restore 
non-volatile
registers?


On 12/12/2013 10:06 AM, Joel Sherrill wrote:
>
> Then the bsp should user the correct cpu cflags and the isr vectoring 
> code should disable the fpu if possible.
>
> On Dec 12, 2013 8:45 AM, Sebastian Huber 
> <sebastian.huber at embedded-brains.de> 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.
>
> -- 
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20131213/39941e14/attachment-0001.html>