RE: Altivec setjmp

["Schwarz, Konrad" <konrad dot schwarz at siemens dot com>]

> Basically on
> RTEMS, just because you are on an
> Altivec CPU, doesn't mean it is enabled
> for a particular thread.

> Any comments?

I ran across a similar issue on a e200-series Power(PC) (a simple Book E core), and posted about it a few weeks ago.

e200 cores don't have AltiVec, but some do have the Signal Processing Engine (SPE) extension, which extends the general purpose registers from 32 to 64 bits on a 32-bit core.  This requires changes to setjmp.S, for example.

The E500 ABI for ELF, which applies to e200 cores, makes SPE available to user-space code on those cores that support it.  Thus, if ABI conformance is relevant to you, this might make you revisit your decision whether to support AltiVec in general, rather than as an option specified during task creation, a la VxWorks.

In my case, newlib contains optimized mem* routines for SPE-enablesd cores; as GCC emits calls to memcpy(), all tasks (and interrupt handlers) need to be able to access these registers, forcing ABI support.

Similar to most floating-point units, the SPE (and AltiVec) can be disabled using a bit in the machine state register (MSR), which is task-specific.  Normally, this can be used to delay context-switching of the extended registers until a task actually uses them.

User-space code cannot access the MSR, so a user-space setjmp.S/longjmp.S has no architecturally-defined way of deciding whether to save extended registers.  This is actually a good thing, as the current setting of the MSR bit actually doesn't indicate whether the current task has used these registers--only whether these registers have been used since the last context switch, if this bit is used to effect delayed context switches.

The PPC ELF ABI, which is the foundation for various Power-based ABIs, specifies a way to signal a variadic function that no floating-point registers where passed.  No similar mechanism exists for setjmp()/longjmp(), ultimately because this is not knownable at the setjmp()/longjmp() call site.  Thus, setjmp()/longjmp() must save and restore extended registers, even if this causes the task to acquire an extended context (and a trap to the operating system to effect the delayed context switch).

Note that the current IBM vector extension for Power dedicates a user-writeable special-purpose register to track the extended registers in use, so the trade-offs might be different there.

Konrad