[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
more patches more newlib-1.16.0 : setjmp & longjmp for 4.9 branch
- Date: Tue, 03 Mar 2009 11:11:55 -0500
- From: feng1 at bnl.gov (Kate Feng)
- Subject: more patches more newlib-1.16.0 : setjmp & longjmp for 4.9 branch
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.
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
> 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.
> rtems-users mailing list
> rtems-users at rtems.com