[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RTEMS bsps/847: data corruption on powerpc due to implicit gcc FPU utilization
- Date: Thu, 03 Nov 2005 21:22:27 -0800
- From: Till Straumann <strauman at slac dot stanford dot edu>
- Subject: Re: RTEMS bsps/847: data corruption on powerpc due to implicit gcc FPU utilization
Ralf Corsepius wrote:
On Fri, 2005-11-04 at 04:21 +0000, RTEMSfirstname.lastname@example.org wrote:I'm not sure if I got my point across. This is not about any fancy
optimization I want
Synopsis: data corruption on powerpc due to implicit gcc FPU utilization
Unfortunately, there is no way to tell gcc not to use FP registers for
other data than double/float. Unless compiling with -soft-float, gcc
may use FP registers for optimization.
E.g., full safety would require moving all ISRs to separateThis road leads to nowhere - Maintainence-wise, the rtems powerpc port
compilation units and compiling those with -msoft-float!
already is a nightmare, but this would render it absolutely
to add or yet another library variant. I'm not even thinking about the
I'm talking about the fact that currently the only way of being certain
that gcc generates
rs6000/powerpc code without touching the FPU is -msoft-float! (Same
applies to altivec).
If we don't want to save/restore all FPU registers across interrupts
then ISRs (and libraries they
call) *must* be compiled separately with -msoft-float.
If we dont' want to save/restore FP registers across context switches
for all tasks then the
whole kernel, the libraries it uses and all integer-only tasks must be
compiled with -msoft-float.
[Hence the suggestion that on PPC all tasks should be forced to FP].
(Assuming that you *do* want to use the FPU for FP tasks, of course).
This behavior of gcc and the lack of options to suppress implicit usage
of the FP and vector
units has been a problem for quite a while (netbsd, rtems, other RTOSes,
packages,...). AFAIK, vxWorks have their own gcc patches.
IMO this is a quite serious problem - someone with deep gcc
understanding should try to
implement -fno-implicit-fp / -fno-implicit-altivec but it doesn't seem
to be trivial as the discussions
on the gcc mailing list indicate.
On x86 this doesn't exist because gcc apparently never uses the FPU for