about SPARC_HAS_FPU = 1
pierre.kestener at cea.fr
Fri Oct 17 13:33:59 UTC 2008
Aleix Conchillo Flaqué a écrit :
> On Fri, Oct 17, 2008 at 13:41, Ralf Corsepius <ralf.corsepius at rtems.org> wrote:
>> On Fri, 2008-10-17 at 12:37 +0200, pierre kestener wrote:
>>> i have read some messages in this list from Jiri Gaisler in March 2008 :
>>> stating that one should always have
>>> #define SPARC_HAS_FPU 1
>>> It seems that this patch has not been integrated in mainline RTEMS sources.
>>> Is there a reason or has this just been forgotten ?
>> I don't recall the details, but to me this patch is simply wrong.
> Which one? The one I proposed initially (before Jiri answers) is
> wrong, yes. I think Pierre is referring to the one from Jiri where
> SPARCH_HAS_FPU is always 1.
Yes, i am referring to the statement
#define SPARC_HAS_FPU 1
My understanding is that if the kernel is compiled with -msoft-float
then we have
#define SPARC_HAS_FPU 0 (from the header file
and then both symbols CPU_HARDWARE_FP and CPU_SOFTWARE_FP are FALSE.
So now I don't understand how a user application using floating point
computations (compiled without -msoft-float and with attribute
RTEMS_FLOATING_POINT) can work on a target with a FPU.
Actually, i have such an application which does not work if I do not
block SPARC_HAS_FPU to 1.
The same application compiled with -msoft-float is of course working well.
To me it looks like, a single flag (-msoft-float) triggers two things
- does the hardware has FPU ?
- do we want floating point emulation ?
Am I missing something ?
More information about the users