more patches more newlib-1.16.0 : setjmp & longjmp for 4.9 branch

[Kate Feng]

Hi Ralf,

The patch is really nice.  It automatically checks to see if
the AltiVec vector unit is available on the particular processor.
Without the patch, the  programmer would have to find out
if the processor supports AltiVec vector unit, and one would have
to read through the ASSEMBLY code and decide if the  __ALTIVEC__
flag is needed in the compiler in order to use the setjmp() and longjmp().
This adds pain to programmers and reduces productivity, especially if
one has to support multiple  PPC processors.

Cheers,
Kate

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.
>
>   
>> -> 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
>