![]() |
RTEMS 6.1-rc7
|
Altivec support was developed and maintained as a user-extension outside of RTEMS. This extension is still available (unbundled) from Till Straumann strau.nosp@m.man@.nosp@m.slac..nosp@m.stan.nosp@m.ford..nosp@m.edu; it is useful if an application desires 'lazy switching' of the altivec context.
Altivec support – the unbundled extension, that is – can be used in two ways:
a. All tasks are implicitly AltiVec-enabled.
b. Only designated tasks are AltiVec-enabled. 'Lazy-context switching' is implemented to switch AltiVec the context.
Note that the code implemented in this directory supports mode 'a' and mode 'a' ONLY. For mode 'b' you need the unbundled extension (which is completely independent of this code).
The major disadvantage of this mode is that additional overhead is involved: tasks that never use the vector unit still save/restore the volatile vector registers (20 registers * 16bytes each) across every interrupt and all non-volatile registers (12 registers * 16b each) during every context switch.
However, saving/restoring e.g., the volatile registers is quite fast – on my 1GHz 7457 saving or restoring 20 vector registers takes only about 1us or even less (if there are cache hits).
The advantage is complete transparency to the user and full ABI compatibility (exept for ISRs and exception handlers), see below.
The advantage of this mode of operation is that the vector-registers are only saved/restored when a different, altivec-enabled task becomes ready to run. In particular, if there is only a single altivec-enabled task then the altivec-context never is switched.
Note that this mode of operation is not supported by the code in this directory – you need the unbundled altivec extension mentioned above.
AFAIK, RTEMS uses the EABI which requires a stack alignment of only 8 bytes which is NOT enough for AltiVec (which requires 16-byte alignment).
There are two ways for obtaining 16-byte alignment:
I) Compile with -mno-eabi (ordinary SYSV ABI has 16-byte alignment) II) Compile with -mabi=altivec (extension to EABI; maintains 16-byte alignment but also allows for passing vector arguments in vector registers)
Note that it is crucial to compile absolutely everything with the same ABI options (or a linker error may occur). In particular, this includes
IMO the proper compiler options for Mode 'a' would be
-maltivec -mabi=altivec -mvrsave=no
Note that the -mcpu=7400 option also enables -maltivec and -mabi=altivec but leaves -mvrsave at some 'default' which is probably 'no'. Compiling with -mvrsave=yes does not produce incompatible code but may have a performance impact (since extra code is produced to maintain VRSAVE).
The default GCC configuration for RTEMS contains a -mcpu=7400 multilib variant which is the correct one to choose.
Now that you have the necessary newlib and libgcc etc. variants you also need to build RTEMS accordingly.
In you BSP's make/custom/<bsp>.cfg file make sure the CPU_CFLAGS select the desired variant:
for mode 'a':
Note that since -maltivec globally defines ALTIVEC RTEMS automatially enables code that takes care of switching the AltiVec context as necessary. This is transparent to application code.
It is the BSP's responsibility to initialize MSR_VE, VSCR and VRSAVE during early boot, ideally before any C-code is executed (because it may, theoretically, use vector instructions).
The BSP must
PSIM supports the AltiVec instruction set with the exception of the 'data stream' instructions for cache prefetching. The RTEMS altivec support includes run-time checks to skip these instruction when executing on PSIM.
Note that AltiVec support within PSIM must be enabled at 'configure' time by passing the 'configure' option
Note also that PSIM's AltiVec support has many bugs. It is recommended to apply the patches filed as an attachment with gdb bug report #2461 prior to building PSIM.
The CPU type and corresponding multilib must be changed when building RTEMS/psim:
edit make/custom/psim.cfg and change
to
This change must be performed before configuring RTEMS/psim.