SPARC fp_disabled exception

Jerry Needell jerry.needell at
Thu Aug 7 01:02:12 UTC 2008

I want to be sure this problem is not more serious than I thought.
I had assumed that, for Floating Point Tasks,  the FPU context always  
saved when an Interrupt is generated? Is there a concern that if the  
compiler allows an ISR to utilize FPU registers, then the FPU  
registers will not be properly restored after the ISR?

Although I have no need to do so, is there any restriction on using  
Floating Point operations in an ISR? The same concern would apply and  
I would have expect this to be clearly documented as a limitation.

The bottom line is, If I create all tasks as RTEMS_FLOATING_POINT, is  
there any concern?


On Aug 6, 2008, at 5:41 PM, Joel Sherrill wrote:

> Ingolf Steinbach wrote:
>> 2008/8/6 Jiri Gaisler <jiri at>:
>>> If gcc cannot be fixed somehow, then the RTEMS_FLOATING_POINT
>>> attribute must be global for the sparc port - either all or none
>>> threads use the FPU.
>> In addition to RTEMS /tasks/, interrupt service routines might be
>> affected by this "optimization", too. AFAIK, there is nothing like
> No there isn't.  We have discussed offline adding a
> standard API service so the user could declare
> an FPU context, save and then restore it under their
> own control.
>> Ingolf
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at
> -- 
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at        On-Line Applications Research
> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>   Support Available             (256) 722-9985
> _______________________________________________
> rtems-users mailing list
> rtems-users at

More information about the users mailing list