setjmp/longjmp, ALTIVEC & FPU

[Till Straumann]

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 (but implicit use of the FPU
by gcc still crashes ISRs if they try to use the FPU).

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

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