9

Is it (easily) possible to use software floating point on i386 linux without incurring the expense of trapping into the kernel on each call? I've tried -msoft-float, but it seems the normal (ubuntu) C libraries don't have a FP library included:

$ gcc -m32 -msoft-float -lm -o test test.c
/tmp/cc8RXn8F.o: In function `main':
test.c:(.text+0x39): undefined reference to `__muldf3'
collect2: ld returned 1 exit status
bdonlan
  • 224,562
  • 31
  • 268
  • 324

4 Answers4

11

It is surprising that gcc doesn't support this natively as the code is clearly available in the source within a directory called soft-fp. It's possible to compile that library manually:

$ svn co svn://gcc.gnu.org/svn/gcc/trunk/libgcc/ libgcc
$ cd libgcc/soft-fp/
$ gcc -c -O2 -msoft-float -m32  -I../config/arm/ -I..  *.c
$ ar -crv libsoft-fp.a *.o

There are a few c files which don't compile due to errors but the majority does compile. After copying libsoft-fp.a into the directory with our source files they now compile fine with -msoft-float:

$ gcc -g -m32  -msoft-float test.c -lsoft-fp -L. 

A quick inspection using

$ objdump -D --disassembler-options=intel a.out  | less

shows that as expected no x87 floating point instructions are called and the code runs considerably slower as well, by a factor of 8 in my example which uses lots of division.

Note: I would've preferred to compile the soft-float library with

$ gcc -c -O2 -msoft-float -m32  -I../config/i386/ -I..  *.c

but that results in loads of error messages like

adddf3.c: In function '__adddf3':
adddf3.c:46: error: unknown register name 'st(1)' in 'asm'

Seems like the i386 version is not well maintained as st(1) points to one of the x87 registers which are obviously not available when using -msoft-float. Strangely or luckily the arm version compiles fine on an i386 and seems to work just fine.

user1059432
  • 7,518
  • 3
  • 19
  • 16
5

Unless you want to bootstrap your entire toolchain by hand, you could start with uclibc toolchain (the i386 version, I imagine) -- soft float is (AFAIK) not directly supported for "native" compilation on debian and derivatives, but it can be used via the "embedded" approach of the uclibc toolchain.

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
  • Thanks for the response. I tried bootstrapping uclibc using buildroot but it seems to be ignoring the .config I provided it under BR2_UCLIBC_CONFIG, at least for the UCLIBC_HAS_FPU option :/ – bdonlan Jun 19 '09 at 18:07
  • @Alex The uclibc toolchain link is broken. http://uclibc.org/toolchains.html should be appropriate? – zengr Jan 14 '12 at 14:50
5

GCC does not support this without some extra libraries. From the 386 documentation:

-msoft-float Generate output containing library calls for floating point. Warning: the requisite libraries are not part of GCC. Normally the facilities of the machine's usual C compiler are used, but this can't be done directly in cross-compilation. You must make your own arrangements to provide suitable library functions for cross-compilation.

On machines where a function returns floating point results in the 80387 register stack, some floating point opcodes may be emitted even if -msoft-float is used

Also, you cannot set -mfpmath=unit to "none", it has to be sse, 387 or both.

However, according to this gnu wiki page, there is fp-soft and ieee. There is also SoftFloat.

(For ARM there is -mfloat-abi=softfp, but it does not seem like something similar is available for 386 SX).

It does not seem like tcc supports software floating point numbers either.

Good luck finding a library that works for you.

Alexander
  • 9,737
  • 4
  • 53
  • 59
0

G'day,

Unless you're targetting a platform that doesn't have inbuilt FP support, I can't think of a reason why you'd want to emulate FP support.

Doesn't your x386 platform have external FPU support? Pity it's not a x486 with the FPU built in!

In my experience, any soft emulation is bound to be much slower than its hardware equivalent.

That's why I finished up writing a package in Ada to taget the onboard 68k FPU instead of using the soft emulation provided by the compiler manufacturer at the time. They finished up bundling it in their compiler as a matter of fact.

Edit: Just seen your comment below. Hmmm, if you don't need a full suite of FP support is it possible to roll your own for the few math functions you do need? That how the Ada package I mentioned got started.

HTH

cheers,

Rob Wells
  • 36,220
  • 13
  • 81
  • 146
  • 3
    We're looking at porting a product to an embedded x86 CPU, and a number of them do not have a FPU. We're currently running on a platform without a FPU, but we don't incur penalties for trapping to the kernel either :) – bdonlan Jun 19 '09 at 16:02