RTEMS 4.7.99.2 Available -- PowerPC/virtex feedback

[Jiri Gaisler]

A similar problem exists with the SPARC bsps. The solution
we have made is to always compile the kernel with -msoft-float
to avoid the use of FPU registers. The FPU context handling
is written in assembler and always present in the kernel.
If a task uses the FPU, it will set the FPU enable bit in the
processor status register and the FPU context will be save
if necessary. On systems without FPU, the FPU task attribute is
never used, so no (unimplemented) FPU instructions are executed
to save the context. It is however necessary to compile all
code that is used by non-FPU tasks with -msoft-float. Sharing
of sub-routines between FPU and non-FPU tasks must therefore
be strictly controlled.

There are a additional few issue to consider:

1. If the kernel is not compiled with -msoft-float, sporadic
    use of FPU registers might occur. This can corrupt the
    present FPU context or generate traps since the kernel
    (as far as I understand) is not designed to use FPU registers.

2. Mixing FPU and non-FPU tasks on systems with FPU is
    dangerous. The final image cannot be linked with
    -msoft-float since we might want to use the math library
    for some of the FPU tasks. However, if a non-FPU task
    links in a C-library routine that uses an FPU register
    for integer purposes, an FPU disabled trap will occur.
    This problem may be latent and only activated during
    a certain execution path - e.g. when you are about to
    dock with the space station ... (Murphy)

So what we really need is a switch in gcc to disable the use
of FPU registers for integer operations. If there is such a
switch, please let me know. The back up solution is to always
mark all tasks as FPU tasks in systems with FPU, even if they
don't explicitly use the FPU. This will avoid the FPU trap
problem but waste some time on context save.

Jiri.


gregory.menke at gsfc.nasa.gov wrote:
> The ppc abi allows the C compiler to use fpu registers for regular
> integer stuff- basically as extra general purpose registers.  If the fpu
> is not present or disabled, this causes exceptions- and is why the fp
> enable bit is forced on PPC bsp's.  The alternative is to compile the
> toolchain & then rtems & the user software without fp, forcing gcc to be
> restricted to the usual set of general registers.  When gcc is using the
> fp registers in this way you'll see them as arguments to regular integer
> instructions.  Its a very insidious problem- you have to work against
> gcc's default register selection algorithms.
> 
> There might be a way to convince gcc to compile RTEMS & newlib without
> using fpu registers, but still implement the fpu context switch-
> permitting userspace the use of the fpu (and allowing truely integer
> tasks)- but I don't know how you'd tell gcc to do it.
> 
> Regards,
> 
> Greg
> 
> 
> Chris Caudle writes:
>  > On Thu, August 9, 2007 3:14 pm, Joel Sherrill wrote:
>  > > Exception 7 is a NOFP exception
>  > 
>  > More accurately it is "program exception," which is also triggered by
>  > illegal opcode.  Did the tool chain change between the two RTEMS versions
>  > in question?  If the newer version got compiled with an opcode which
>  > doesn't exist in the 405 core by some mistake it could trigger the same
>  > exception.
>  > FP exception seems more likely, but just wanted to throw that out there.
>  > Might be worth taking a look at the disassembly.
>  > 
>  > -- 
>  > Chris Caudle
>  > 
> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
> 
>