SPARC fp_disabled exception

[jerry.needell at unh.edu (Jerry Needell)]

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?

thanks,
Jerry


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

> Ingolf Steinbach wrote:
>> 2008/8/6 Jiri Gaisler <jiri at gaisler.com>:
>>
>>> 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
>> RTEMS_FLOATING_POINT for ISRs.
>>
> 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 rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>
>
>
> -- 
> Joel Sherrill, Ph.D.             Director of Research & Development
> joel.sherrill at OARcorp.com        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 rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users