RTEMS 126.96.36.199 Available -- PowerPC/virtex feedback
Robert S. Grimes
rsg at alum.mit.edu
Fri Aug 10 00:36:03 UTC 2007
Jiri Gaisler wrote:
> 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.
Okay, that would be perfectly acceptable to me - I have no use for
floating point on this project.
> 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.
This is the case here - no FPU.
> It is however necessary to compile all
> code that is used by non-FPU tasks with -msoft-float.
Is this still true when there is no FPU?
> Sharing of sub-routines between FPU and non-FPU tasks must therefore
> be strictly controlled.
Ditto. To clarify, I have no FPU, _and_ no floating point tasks. More
precisely, I want NO floating point tasks.
> 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.
Sounds like this could be my problem, in that I don't _explicitly_
specify the -msoft-float option.
> 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)
Does not apply here, right? Just trying to understand, mind you...
> 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.
Okay, I think I follow. The only problem I have _right now_ with this
discussion is that I don't know how to specify the -msoft-float option.
Is this a configure-time option? Can someone give me an exact syntax
example? Clearly, Jiri, you are saying the RTEMS kernel needs to be
compiled that what, but Greg suggests that newlib needs similar
treatment - sounds logical. I really don't know how to do that -
hopefully, I can just rebuild newlib without the entire toolchain?
Again, I could use some detailed examples. (Just the invocation
commands, and maybe a sentence or two - no manual needed! ;) )
> 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.
>> 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
> rtems-users mailing list
> rtems-users at rtems.com
More information about the users