(FPU issue) Re: more patches for newlib-1.16.0 : setjmp & longjmp for 4.9 branch

Kate Feng feng1 at bnl.gov
Tue Mar 3 16:27:57 UTC 2009

Ralf Corsepius wrote:
> Till Straumann wrote:
>> IIRC I had contributed a (maybe similar) patch in the past
>> which addressed saving/restoring FP context as part of
>> setjmp/longjmp.
> I vaguely recall you patches - IIRC, they lacked generality because of 
> the same issues as being raised here.
>> Indeed, there were __rtems__ specific pieces:
>>  - on rtems not all threads are necessarily FP-enabled
>>  - on rtems lazy-FP context switching is possible
>>  - on rtems we can read MSR to find out if the FPU is
>>    enabled or not (since we run in supervisory mode).
> This doesn't parse to anything I understand.
Sometimes, one can disable the FPU in some threads to improve
the performance of the applications.  I tried it before on the mvme5500. 
It did not seem to be significant on this processor based on the
application I tested.  I never tried further to see the impact on an 
system.  However, I believe that it is useful to have this option, 
for some slower processors.  I still vote for this patch.  The entire
patch should be applied to the  newlib-1.16.0 and up.

>> -> my patch (#ifdef __rtems__ only) used the MSR[FE]
>>    information to dump/load FP registers when possible/necessary.
>> Under these premises the test for __rtems__ seems to
>> make sense but you might have a better idea.
> First of all, I need to understand these patches. So far, even with your 
> attempts to explain, this hasn't happened.
> Ralf
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users

More information about the users mailing list