Re: mpc8xx fpu emu

Re: mpc8xx fpu emu

[Conn Clark]

Alban Wood wrote:

<snip>

> I was unaware of this. I guess I would have realized this at some point
> but would have lost a lot of time.
>
> Are there specific known cases or instructions for which the emulator
> doesn't behave correctly?
>

	Unfortunatly I haven't tried using the fpu emulation, I'm just
relaying to you what I've been told when I pursued it hoping to save ram.
After finding out it would only shave about 4K off of glibc I abandoned
the quest. I determined it was just not worth the hassel for such small
gains and applying my efforts elsewhere would yeild greater savings.

	I don't know of anyone who has tried it lately, so the bugs may
no longer exist. Wolfgang Denk (who's opinion I hold with high regard)
has said that he could get it to fail with the "ls -l" command as I
recall.
<snip>

>
> Yes it does. Thank you!
>
> Alban

	Exactly why do you want to use fpu emulation?



Hope I'm helping

	Conn

--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: mpc8xx fpu emu

[Dan Malek]

Conn Clark wrote:


> 	Unfortunatly I haven't tried using the fpu emulation,

The kernel fpu emulation works, it's just slower than using
the soft-float in the C library.

> .... I'm just
> relaying to you what I've been told when I pursued it hoping to save ram.

I wouldn't use the reason for trade off as memory savings.  The things
you trade are performance and "big brother" (those processors with floating
point) :-) binary compatibility.

> 	I don't know of anyone who has tried it lately,

I run some systems with kernel FPU and some without.  Just depends upon
the libraries and applications I have available.  Since most libraries
these days for the 8xx are built with soft-float, I tend to use that.
In this case, it doesn't matter if the kernel has the fpu emulation
option enabled or not.

The only bugs you will find is when you mix applications and libraries
that aren't compiled to match.  The function calling conventions are
different between the FPU enabled programs/libraries and the soft-float
programs/libraries.

Even when you don't enable the kernel FPU emulation, we still emulate a
few FP instructions.  This is to allow programs that use absolutely no
floating point to work with the generic FPU PowerPC libraries.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: mpc8xx fpu emu

[Kumar Gala]

Dan,

> Even when you don't enable the kernel FPU emulation, we still emulate a
> few FP instructions.  This is to allow programs that use absolutely no
> floating point to work with the generic FPU PowerPC libraries.

Can you elaborate on this?  Why exactly is this done?  Is it because
glibc has some minor FP code @ startup?

thanks

- kumar


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: mpc8xx fpu emu

[Dan Malek]

Kumar Gala wrote:

> Can you elaborate on this?  Why exactly is this done?  Is it because
> glibc has some minor FP code @ startup?

The best example is the setjmp/longjmp code and associated signal functions.
There is lots of assembly code in the C library specific to processors to
support this.  When you call some setup functions or use signals (in this
case) you will execute load/store FP instructions.

I originally added these minimal emulations so I could use the standard
PowerPC libraries even though I didn't do any floating point in the application.
It was also necessary to simply get a shell running :-)

Note 1, just because you compile libraries with -msoft-float doesn't mean
there won't be floating point instructions in the code.  You have to go through
the libraries and fix up all of the assembly code that may use floating
point instructions.

Note 2, don't ever mix real float instructions, soft-float libraries, soft-float
applications and kernel emulation.  Everything must properly match for context
switching and passing of arguments between functions.  A tempting combination
is an FP enabled library, minimal FP emulation in the kernel, and a soft-float
application to get maximum performance with minimal effort......don't do that,
it will not work.  Either use complete user-land soft-float, or real FP
instructions with complete kernel emulation.


	-- Dan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: mpc8xx fpu emu

[Alban Wood]

I forgot to mention that I was able to verify that the floating point
emulator *works*. I examined the result of a floating point division in
memory and it was valid. So I guess it is the libc I am using. Like I
said, could it be that it was compiled with -msoft-float?

I'm also not sure I can draw conclusions from the following fact, but I
disassembled the libc used on the board, and found no floating point
instructions. I did the same with a libc on a powerpc 604 I have here, and
did find floating point instructions.

Regards,

Alban



Alban Wood wrote:
> hello,
>
> Regarding my problem, I searched the list archives and did found some
mpu
> emul related posts but they were not exactly like my case.
>
> Basically, I have an RPX Lite-M board. The mpc850 does not have an fpu,
> but I have a need for non-intensive fpu operations. I don't want to
> compile applications and librairies with -msoft-float - for my needs the
> fpu emulator is really the way to go.
>
> The board successfully boots a slightly modified linux 2.4.9. I've
> compiled the kernel with and without math emulation.
>
> I also compiled a very simple application that does a floating point
> division and prints it. I explicitly specified -msoft-hard. (same with
the
> kernel btw), checked out the resulting assembly and did in fact find an
> fdiv instruction.
>
> Without the emulation, executing the program results in a floating point
> exception. This is normal.
>
> With the math emu kernel, the exception is caught and seemingly handled
as
> it should. However, a printf of a float results in "nan" (not a number).
>
> If I invoke the printf binary (printf "%f\n" 43.34343) it is able to
print
> a float.
>
> I didn't compile my own toolchain. I switch between the binary
> distributions I got from www.qslinux.org and timesys. I'm not sure this
is
> a good idea.
>
> Any ideas as to what could be wrong? Could it be that the libs in the
root
> filesystem I'm using for the board were compiled with -msoft-float,  and
> that as a result printf cannot properly output a float? (even though
it's
> been properly handled by the fpu emulator?)
>
>
> Thank you,
>
>
> Alban
>
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: mpc8xx fpu emu

[Conn Clark]

Hello Alban,

	Unfortunatly the ppc code generated by the -msoft-float option does not
pass values in the same way as code generated for a chip with a fpu or a kernel
with fpu emulation. This is done to get a boost in speed on fpuless chips. This
renders software/libraries compiled one way to not be compatible with stuff
compiled the other way when passing floating point values(Note: there are some
cases where they will work correctly together).

	The -msoft-float option does not increase executable/library size in
any signifigant way and provides a signifigant speed boost. Also a few people
say that the fpu emulation code in the kernel is buggy. The -msoft-float has
become the default way things are done on the fpuless Motorola 8xx family for
these reasons.

	This means you must compile everything (and I mean everything) to use
-msoft-float or compile everything to use the fpu. So if you are not interested
in building and maintaining your own tool chain and possibly squishing some fpu
emulation bugs, you are better off using -msoft-float like everybody else.

Hope this answers your question.

	Conn
--

*****************************************************************
  If you live at home long enough, your parents will move out.
 (Warning they may try to sell their house out from under you.)
*****************************************************************

Conn Clark
Engineering Stooge				clark@esteem.com
Electronic Systems Technology Inc.		www.esteem.com


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: mpc8xx fpu emu

[Wolfgang Denk]

In message <Pine.LNX.4.44.0209111537420.1731-100000@manoir.bloodwolf.org> you wrote:
>
> I forgot to mention that I was able to verify that the floating point
> emulator *works*. I examined the result of a floating point division in
> memory and it was valid. So I guess it is the libc I am using. Like I
> said, could it be that it was compiled with -msoft-float?

You are right: the whole ELDK environment for the 8xx  (and  for  the
4xx, btw.) uses -msoft-float.


Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Beware of bugs in the above code; I have only proved it correct, not
tried it."                                             - Donald Knuth

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

mpc8xx fpu emu

[Alban Wood]

hello,

Regarding my problem, I searched the list archives and did found some mpu
emul related posts but they were not exactly like my case.

Basically, I have an RPX Lite-M board. The mpc850 does not have an fpu,
but I have a need for non-intensive fpu operations. I don't want to
compile applications and librairies with -msoft-float - for my needs the
fpu emulator is really the way to go.

The board successfully boots a slightly modified linux 2.4.9. I've
compiled the kernel with and without math emulation.

I also compiled a very simple application that does a floating point
division and prints it. I explicitly specified -msoft-hard. (same with the
kernel btw), checked out the resulting assembly and did in fact find an
fdiv instruction.

Without the emulation, executing the program results in a floating point
exception. This is normal.

With the math emu kernel, the exception is caught and seemingly handled as
it should. However, a printf of a float results in "nan" (not a number).

If I invoke the printf binary (printf "%f\n" 43.34343) it is able to print
a float.

I didn't compile my own toolchain. I switch between the binary
distributions I got from www.qslinux.org and timesys. I'm not sure this is
a good idea.

Any ideas as to what could be wrong? Could it be that the libs in the root
filesystem I'm using for the board were compiled with -msoft-float,  and
that as a result printf cannot properly output a float? (even though it's
been properly handled by the fpu emulator?)


Thank you,


Alban


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: mpc8xx fpu emu

[Wolfgang Denk]

Dear Alban,

in message <Pine.LNX.4.44.0209111451510.1731-100000@manoir.bloodwolf.org> you wrote:
>
> Basically, I have an RPX Lite-M board. The mpc850 does not have an fpu,
> but I have a need for non-intensive fpu operations. I don't want to
> compile applications and librairies with -msoft-float - for my needs the
> fpu emulator is really the way to go.

Believe me: it is _not_.

> I also compiled a very simple application that does a floating point
> division and prints it. I explicitly specified -msoft-hard. (same with the
> kernel btw), checked out the resulting assembly and did in fact find an
> fdiv instruction.

You can do this, and you may even get simple  programs  working.  But
other  simple program may crash, or produce bad results, or both. Not
to speak about complicated programs.

The FPU emulation code is *far* from being production quality.

Do NOT use it. You have been warned.


And BTW: why should you want to use it? If you just have to deal with
"non-intensive fpu operations" then software FP is just  fine  -  you
probably won;t even notice the slightly larger memory footprint - but
you definitely will notice the much, much higher speed of soft-float.

> I didn't compile my own toolchain. I switch between the binary
> distributions I got from www.qslinux.org and timesys. I'm not sure this is
> a good idea.

Be aware that you cannot mix harware FP and software FP in one binary
and the libraries you link against.

> Any ideas as to what could be wrong? Could it be that the libs in the root
> filesystem I'm using for the board were compiled with -msoft-float,  and
> that as a result printf cannot properly output a float? (even though it's
> been properly handled by the fpu emulator?)

This is very likely the cause.

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Here's a fish hangs in the net like a poor man's right in  the  law.
'Twill hardly come out."     - Shakespeare, Pericles, Act II, Scene 1

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/