Subject: RE: Floating Point Emulation

From: George France <[email-masked]>
Date: Thu, 8 Jun 2000 18:59:17 -0400

Why are you not using -msoft-float?

--George

-----Original Message-----
From: Dan [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 1:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Floating Point Emulation

Mark Hatle wrote:
> What timing.. :)
[snip]
>
> I am currently working on patching gcc (2.95.2) to do soft-float 
the way
> other platforms do it.  (If you look in the gcc source in 
gcc/config/arm
> you'll see a but of "t-*" files.  all of the files EXCEPT the linux 
one
> use the built-in soft-floating point.  So it should be possible.)  
FYI,
> I have yet to run the tests on the floating point, so what I have 
now
> may not work the way I think it does!
>
> If you would like a copy of my patches email me off the list and 
I'll go
> into exactly what I'm doing.
>
[snip]

Hi Mark:

Thanks for your response. I don't know if I am brave enough
to do battle with gcc and the Linux libraries. I am a wimp
in such matters - I tend not to fight the native development
environments unless absolutely necessary.

I find if I manipulate the environments too much it turns
into a support headache making it difficult to pick up
new releases, etc. It's the "when in Rome, do as the
Romans do" philosophy. :-)

I always wondered where those darn flags were.
Thanks. Good luck.

--------------------------------
Bye!
Dan McDonald
The Late Night Software Shop 
Sign up today for your Free E-mail at: http://www.canoe.ca/CanoeMail 

unsubscribe: body of `unsubscribe linux-arm-kernel' to
[email-masked]

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Mark Hatle <[email-masked]>
Date: Thu, 08 Jun 2000 17:19:55 -0700

I can answer for myself at least.  The way -msoft-float is setup for the
netwinders isn't the way I want to do things.  The regular -msoft-float
uses an external libfloat library, having to use an external library for
floating point is not the correct solution IMHO, especially when gcc
provides the functionality internally.  I believe Dan didn't want to
deal with external libraries.

FYI, all of the other arm platforms use gcc's built in floating point
emulation except for the linux target.  I have a patch that does the
same for linux.

--Mark

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Sun, 11 Jun 2000 08:40:29 +0100 (BST)

Mark Hatle writes:
> The regular -msoft-float uses an external libfloat library, having to
> use an external library for floating point is not the correct solution
> IMHO, especially when gcc provides the functionality internally.

Please explain what you mean more clearly.  AFAICR, GCC does not
provide any floating point emulation.  Without -msoft-float, GCC
will emit the hardware instructions for floating point operations,
and therefore you will need some floating point emulation code.

There are two possibilities:

1. Build with -msoft-float and use libfloat
2. Build without -msoft-float and use either the Acorn FPE or NWFPE.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: Mark Hatle <[email-masked]>
Date: Mon, 12 Jun 2000 10:07:03 -0700

> 2. Build without -msoft-float and use either the Acorn FPE or NWFPE.

(Hopefully this will answer Russell's, George's and Dan's questions all
at once.)

Gcc (2.95.2 at least) does in fact have an internal floating point
library.  This library is used by other soft floating point targets,
such as PowerPC.  The system compiles in two source files to enable the
built in soft floating point.  fp-bit.c and dp-bit.c  (FYI they are
actually the same source file .../gcc/config/fp-bit.c, but the
t-makefile copies it twice and adds a couple of #defines at the top of
the file.)

My understanding is that the gcc even with the built in floating point
uses the method shown in
http://www.netwinder.org/~scottb/notes/FP-Notes-6.html.  The difference
is that we don't need the external libfloat anymore.  (i.e. things
compiled with -mhard-float and -msoft-float are still not compatable,
and there isn't a way to allow them to be.)

FYI, I have a kernel on my netwinder that does not have NWFPE compile
in, and I do not have libfloat.  Everything I've compiled so far (bash,
ldconfig, util-linux) has worked correctly with my patches.

If you are interested in how I did the patch you can look at the gcc
source in .../gcc/config/arm and then t-arm-elf is a generic config
file, and t-linux is the one for linux.  The t-arm-elf has the pieces in
it to activate the gcc built-in soft floating point.  Other arm targets
seem to do the same.  From what I can tell (quickly) it looks like the
embedded style targets use the built in, and the bsd and linux target
use an external library.

I'll wrap up by changing the "two possibilities" above:

1) Use -msoft-float and use gcc's built-ins (with my patch)
2) Use -msoft-float and libfloat (default)
3) Use (-mhard-float and use) the compiled in NWFPE.

Keep in mind that you can't link soft-float and hard-float items
together.

Questions?  Hopefully I've answered them, but please ask more!
--Mark

---

From: Scott Bambrough <[email-masked]>
Date: Mon, 12 Jun 2000 14:48:54 -0400

> GCC 2.95 does in fact have an internal floating point
> built in soft floating point.  fp-bit.c and dp-bit.c

Mark is correct here.  The file fp-bit.c is a relatively new addition that
resulted from the gcc2 code merges.  It offers the same set of entry points as
libfloat.  However the version on the 2.95 branch has several bugs, and should
be brought up to the same level as the mainline AFAIK.  AFAICT, this work is
meant to be used on the mainline, not on the branch.  There is no reason it
cannot be used in 2.95, it just wasn't tested to my knowledge.  This code wasn't
available when we first did libfloat (that would be gcc 2.81 days).

> ldconfig, util-linux) has worked correctly with my patches.

I would expect this to be the case.  A better test would be the glibc math test
suite or the UCB tests from netlib.  Do the tests
gcc.c-torture/execute/ieee/fp-cmp-[1-4].c pass in the gcc testsuite?

> embedded style targets use the built in, and the bsd and linux target

I have a patch similar to this for the gcc mainline to fix the fp-cmp-4 test
suite failure seen on Linux.  Question is do I patch the specs file as well?  I
see what happens after more testing.

Scott

-- 
Scott Bambrough - Software Engineer
REBEL.COM    http://www.rebel.com
NetWinder    http://www.netwinder.org

---

From: Mark Hatle <[email-masked]>
Date: Mon, 12 Jun 2000 13:04:29 -0700

> available when we first did libfloat (that would be gcc 2.81 days).

Interesting, for our PPC work we have a bunch of items that are
backported from the mainline to the 2.95.2.  I will ask if the floating
point is included in that work.  If it is, then I may already have a
patch for that.

> gcc.c-torture/execute/ieee/fp-cmp-[1-4].c pass in the gcc testsuite?

I have not run any of the gcc testsuites yet.  Mostly I have written
small test programs that do the basic + - * / operations and the correct
results are returned.  I will be testing with the gcc and glibc tests
"soon", but I'm not sure yet when I will have the opportunity to do it.

> see what happens after more testing.

What in the specs file were you considering changing?  On the PPC side,
we've had a bit of internal discussion on various things we can do to
better support soft-float.  One of which is to change the %{msoft-float:
-D_SOFT_FLOAT} to %{!mhard-float: -D_SOFT_FLOAT}.  (The arm define is
different, but I think you can see what I'm getting at.)  Also my patch
activates the --without-fp on the config, and thats what triggers the
SPEC file change.

--Mark

---

From: Scott Bambrough <[email-masked]>
Date: Mon, 12 Jun 2000 16:49:39 -0400

> "soon", but I'm not sure yet when I will have the opportunity to do it.

I'd be interested in the results when you get the chance.

> activates the --without-fp on the config, and thats what triggers the

I don't know whether that would fly on the ARM.  I suspect to conform to the
ATPCS we will need a version where soft, hard and no floating point options
would be available.  Such a change as you describe would preclude that.  As for
what I would change in the specs file, the linux-elf version automatically links
in libfloat.  If we have the soft-float entry points in libgcc, is this really
necessary and is it likely to cause problems, link warnings, etc.

I don't know how many people actually use these routines as well, so I'm not
convinced they work correctly.  It looks like someone has set up the code to
handle the ARM doubles, and little endian/big endian troubles.  The code makes
liberal use of structs, and that always makes me nervous, given the alignment
constraints on structs.

Everything may be fine, but to date, nothing with ARM floating point has been
easy.  Just about every package that handles floats/doubles seems to require a
measure of porting on the ARM.  Why should this be any different?  I need to be
convinced it is ok.  This requires testing.

Scott

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 12 Jun 2000 21:58:38 +0100 (BST)

> convinced it is ok.  This requires testing.

Care to enlighten us a little more with a list of "typical" problems with
the floats/doubles?
   _____

---

From: Scott Bambrough <[email-masked]>
Date: Mon, 12 Jun 2000 17:13:29 -0400

> Care to enlighten us a little more with a list of "typical" problems with

Typically most software is written for little endian Intel architechures.  In
the stuff I have ported, the biggest trouble is with the ARM double format.  The
next biggest problem is with masks for testing for things like NaN's, masking
out the exponent etc.  Well designed code seems to have a define for the masks
they use, other stuff uses numeric literals, which have to be hunted down
individually.  I've never had to deal with little/big endian issues myself.

The only other thing that I would actually check in this code is the structures
used to represent floats.  People who work on x86 platforms  expect packed
structs; they never consider alignment issues.

All this being said, I've only had a cursory look at fp-bit.c.  It may suffer
from none of these potential problems.  I only wanted to point out the possible
pitfalls garnered from my experiences.

Scott

---

From: Mark Hatle <[email-masked]>
Date: Mon, 12 Jun 2000 14:33:05 -0700

> necessary and is it likely to cause problems, link warnings, etc.

I think I stated that poorly.  What I ment to say was that if during the
config of gcc you passed in --without-fp, the spec files default would
change as I noted above.  If you did not pass in a --without-fp, then
the default would be used.

I understand a version for soft and hard, but what is a no floating
point version?  On the PowerPC the default version is "hard" while a
version compiled into the "nof" directory (MULTILIB in the t- makefiles)
is for the soft-float.

THe -lfloat in the current spec file should be removed.  TO use the
internal floating point.  If it's not removed linking problems occur.

> liberal use of structs, and that always makes me nervous, given the alignment

I honestly don't know anything about the alignment on ARM.  Certain PPC
cores are required to be 8-byte aligned, things like the stack must be
16-byte aligned.  Most of these cores do not have FPUs, and this soft
floating point has been used successfully on them.

> ... This requires testing.

I agree 100%!

--Mark