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

[Kate Feng]

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 
overloaded
system.  However, I believe that it is useful to have this option, 
especially
for some slower processors.  I still vote for this patch.  The entire
patch should be applied to the  newlib-1.16.0 and up.

Cheers,
Kate
>   
>> -> 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
>