setjmp/longjmp, ALTIVEC & FPU
Kate Feng
feng1 at bnl.gov
Fri Oct 2 13:30:08 UTC 2009
Till Straumann wrote:
> If you want to use setjmp/longjmp (and to some extent 'printf' and
> its vector extensions) the issues are:
>
> W/o the newlib patch you must make all threads FP threads
> (or use soft-float everywhere).
> AFAIK we currently (implicitly) make all threads FP-threads anyways to
> handle implicit use of FP-regs by gcc
Do we all ? I thought I did not. At one point,
for my applications using RTEMS4.8, which uses the version of patched
newlib,
I created some tasks (e.g. rtems_task_create) that use the option of
RTEMS_NO_FLOATING_POINT.
I was glad that I had the option to do so because I had the same
when I was using another real-time O.S. many years ago.
> (but implicit use of the FPU
> by gcc still crashes ISRs if they try to use the FPU).
Yes, the usage of FPU in a user ISR is not encouraged and
can be gotten around.
>
> If you want to use altivec then things are more complicated:
>
> - you'd have to build a -maltivec -mabi=altivec multilib variant.
> longjmp/setjmp then save/restore the altivec registers because
> __ALTIVEC__ was defined when building longjmp/setjmp.
>
> - w/o the patch longjmp/setjmp always save/restore the altivec
> registers and thus the altivec extension must be built with
> ALL_THREADS_ALTIVEC defined and installed as a 'initial'
> RTEMS extension (restrictions apply, see 'vec_context.c' in
> the altivec extension package).
> This results in all threads being vector-enabled.
>
> Note that a RTEMS build with -maltivec may result in gcc
> implicitly vectorizing stuff which would crash if it happened
> in an ISR or during an early stage before the BSP (or application)
> gets a chance to enable the vector-unit.
>
> Personally, I do the following:
>
> a) never use longjmp/setjmp, especially not from vector-enabled tasks
I do remember reading about the risk of using the setjmp and longjmp
in the last century. However, if the code is currently released
in RTEMS, it should not be so fragile. If it is a piece of code that
should
never be used, it should not be released at all. It should be invisible.
Since setjmp/longjmp are released in standard newlib in almost all
other O.S., I propose to keep the code and patch it so that it is less
brittle,
and even 100% robust.
> b) build everything with -mno-altivec -mabi=altivec (note that recently,
> the -mno-eabi switch has been removed from the rtems-gcc multilib
> madness
> and you need to ensure 16-byte stack alignment somehow; either with
> -mno-eabi or -mabi=altivec).
I used (and still use) -mno-altivec -mabi=altivec for all threads, and
the code
broke without the patch. I propose either
1) Use the original patch from the older version of newlib, and add the
comment
in setjmp.S about the risk of RTEMS build with -maltivec.
Or
2) Do not allow one to use setjmp/lonjmp at all if RTEMS is built with
-maltivec.
The compilation would exit.
I actually prefer 2), but who knows one day gcc might fix the problem with
RTEMS built with -maltivec.
> c) build stuff that executes in a vectorized task with -maltivec
> -mabi=altivec
> d) let the altivec extension enable the vector-unit on vector tasks and
> do lazy-context switching.
If RTEMS is built with -maltivec, then do c) and d), no setjmp/lonhjmp code,
at least for now.
Please let me know what you think.
Thanks,
Kate
>
> FWIW
> -- T.
>
> Joel Sherrill wrote:
>> Feng, Kate wrote:
>>> Yes, I read the code this morning, and it looks like the patch for
>>> HAVE_BLKSIZE is in. However, the patch
>>> for setjmp() and longjmp() were not considered. I am
>>> not too sure why Ralf sees it controversial. Please
>>> advise.
>>>
>>>
>> Go back to the newlib archives. There was a discussion
>> there and concern that it needed to run in supervisor
>> mode which is not always the case and introduced an OS
>> ifdef into code which shouldn't need it. If you want to
>> resubmit it to the newlib list and champion it, go ahead.
>>
>> When it was submitted last time, there was no champion
>> to address any concerns.
>>
>> --joel
>>> Thanks,
>>> Kate
>>>
>>> ________________________________
>>>
>>> From: rtems-users-bounces at rtems.org on behalf of Joel Sherrill
>>> Sent: Thu 10/1/2009 9:58 PM
>>> To: Chris Johns
>>> Cc: RTEMS Users; Ralf Corsepius
>>> Subject: Re: 4.10 Approaching
>>>
>>>
>>>
>>> Chris Johns wrote:
>>>
>>>> Till Straumann wrote:
>>>>
>>>>
>>>>> I actually would really recommend the HAVE_BLKSIZE patch - which
>>>>> BTW has been recommended for a looong time; see e.g.,
>>>>> libfs/src/nfsclient/README. It greatly improves stdio on any blocked
>>>>> filsystem.
>>>>>
>>>>> msdosfs and NFS already do provide the necessary blocksize
>>>>> information.
>>>>>
>>>>> IMFS currently sets the blocksize to 0 for directories. zero is also
>>>>> the default if a filesystem does not set/provide a blocksize.
>>>>>
>>>>> newlib stdio correctly handles the case of a zero blocksize but
>>>>> some 'fseek()' performance gain could be achieved by using
>>>>> BUFSIZ/1024 in these cases.
>>>>>
>>>>> I can't really see *anything* controversial in this case.
>>>>>
>>>>>
>>>> I have just looked in my local copy of newlib-1.17.0 and
>>>> ChangeLog.rtems
>>>> has:
>>>>
>>>> 2009-02-24 Ralf Corsépius <ralf.corsepius at rtems.org>
>>>>
>>>> * libc/unix/ttyname.c: Sync with newlib-cvs.
>>>> * configure.host: Add -DHAVE_BLKSIZE to newlib_cflags.
>>>>
>>>> Is this change already in newlib ? I cannot remember if I applied
>>>> any of
>>>> Ralf's patches to this or if they are clean. I seem to remember them
>>>> being clean.
>>>>
>>>>
>>> Looks like it. My newlib cvs has this:
>>>
>>> 2009-09-22 Ralf Corsépius <ralf.corsepius at rtems.org>
>>>
>>> * configure.host (*-rtems*): Remove -DMISSING_SYSCALL_NAMES.
>>> Add -DHAVE_BLKSIZE, -D_NO_WORDEXP -D_NO_POPEN.
>>>
>>>
>>>> FYI I have code I am working on that allows the block size to
>>>> change at
>>>> the bdbuf layer and below. Currently the coming RFS file system has
>>>> support for changing the block size. The MSDOS file system could be
>>>> changed to do this and so removed the way it handles the buffers.
>>>> Along
>>>> with this change I have a statvfs call to add to libcsupport. The call
>>>> returns the file system block and the media block sizes.
>>>>
>>>> Regards
>>>> Chris
>>>> _______________________________________________
>>>> rtems-users mailing list
>>>> rtems-users at rtems.org
>>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> rtems-users mailing list
>>> rtems-users at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-users
>>>
>>>
>>>
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-users
>
More information about the users
mailing list