SPARC fp_disabled exception
jerry.needell at unh.edu
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 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.
>> rtems-users mailing list
>> rtems-users at rtems.com
> 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
More information about the users