Tech Insider					   Technology and Trends


			   USENET Archives

Newsgroups: comp.unix.bsd
Path: sparky!uunet!munnari.oz.au!uniwa!cujo!marsh!manningc
From: mann...@marsh.cs.curtin.edu.au (Colin Manning)
Subject: !fpu compiler
Message-ID: <manningc.708050790@marsh>
Sender: ne...@cujo.curtin.edu.au (News Manager)
Organization: Curtin University of Technology
Date: Tue, 9 Jun 1992 00:46:30 GMT
Lines: 17

Hi,
   Has anyone got a compiler and libraries that don't need a fpu?

   I have installed th no-fpu filesystem, and whenever I compile something
I a message simular to "cc recieved signal 6".  I know this is the abort signal,
but I don't know where it is coming from, so I assume it is caused by the lack 
of a fpu.  (If it fails blame the lack of fpu :-))


   There was some dicussion of compiler and libraries that wouldn't need a fpu
earlier, and also the talk that 0.1 would not require a fpu.  However It has
been a long week :-)


Colin.

mann...@marsh.cs.curtin.edu.au

Newsgroups: comp.unix.bsd
Path: sparky!uunet!usc!sdd.hp.com!ux1.cso.uiuc.edu!news.iastate.edu!
help.cc.iastate.edu!michaelv
From: mich...@iastate.edu (Michael L. VanLoon)
Subject: Re: !fpu compiler
Message-ID: <michaelv.708097983@help.cc.iastate.edu>
Sender: ne...@news.iastate.edu (USENET News System)
Organization: Iowa State University, Ames IA
References: <manningc.708050790@marsh>
Date: Tue, 9 Jun 1992 13:53:03 GMT
Lines: 30

In <manningc.708050790@marsh> mann...@marsh.cs.curtin.edu.au (Colin Manning) writes:

>   Has anyone got a compiler and libraries that don't need a fpu?

>   I have installed th no-fpu filesystem, and whenever I compile something
>I a message simular to "cc recieved signal 6".  I know this is the abort signal,
>but I don't know where it is coming from, so I assume it is caused by the lack 
>of a fpu.  (If it fails blame the lack of fpu :-))

The fix is to make sure you compile WITHOUT the -O option.  (Thanks to
all those who pointed this out to me. :)  The optimization phase in the
compiler uses the fpu, I guess.  You'll have to edit the -O off the
CFLAGS (?) line in the sys.mk file in /usr/share/mk/ if you use the make
command (you might want to put the -msoft-float option on that same line
you took -O off of at this point).

The option to specify that your program is supposed to use floating
point emulation is -msoft-float.  I haven't tested whether it actually
works yet, or not, but things do compile.

>   There was some dicussion of compiler and libraries that wouldn't need a fpu
>earlier, and also the talk that 0.1 would not require a fpu.  However It has
>been a long week :-)

I don't know about that...  It would certainly be nice, though...
-- 
------------------------------------------------------------------------------
Michael L. VanLoon                                     "Ignorance is bliss..."
mich...@iastate.edu      --       Computer Engineering, Iowa State University
------------------------------------------------------------------------------

Path: sparky!uunet!think.com!ames!haven.umd.edu!darwin.sura.net!dtix!mimsy!
nmrdc1!rdc30
From: rd...@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson)
Newsgroups: comp.unix.bsd
Subject: Re: !fpu compiler
Message-ID: <1992Jun9.170339.7815@nmrdc1.nmrdc.nnmc.navy.mil>
Date: 9 Jun 92 17:03:39 GMT
References: <manningc.708050790@marsh> <michaelv.708097983@help.cc.iastate.edu>
Organization: Naval Medical Research & Development Command
Lines: 29

In article <michaelv....@help.cc.iastate.edu> 
mich...@iastate.edu (Michael L. VanLoon) writes:
>In <manningc.708050790@marsh> 
>mann...@marsh.cs.curtin.edu.au (Colin Manning) writes:
>
[gcc dies with signal 6]
>
>The fix is to make sure you compile WITHOUT the -O option.  (Thanks to
>all those who pointed this out to me. :)  The optimization phase in the
>compiler uses the fpu, I guess.  You'll have to edit the -O off the
>CFLAGS (?) line in the sys.mk file in /usr/share/mk/ if you use the make
>command (you might want to put the -msoft-float option on that same line
>you took -O off of at this point).
>
>The option to specify that your program is supposed to use floating
>point emulation is -msoft-float.  I haven't tested whether it actually
>works yet, or not, but things do compile.

You must not have compiled anything that generates floating point
instructions yet. (Try df)  When you do you get a string of errors from ld
looking for the float emulation routines.  So far there is no libsoft.a :-(

Mike



-- 
LCDR Mike Dobson, Sys Admin for | Internet: rd...@nmrdc1.nmrdc.nnmc.navy.mil
nmrdc1.nmrdc.nnmc.navy.mil      | UUCP:   ...uunet!mimsy!nmrdc1!rdc30
AT&T 3B2/600G Sys V R 3.2.3     | BITNET:   dobson@usuhsb or nrd0mxd@vmnmdsc
WIN/TCP for 3B2  R3.2           | MCI-Mail: 377-2719 or 00037...@mcimail.com

Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.unix.bsd
Subject: Re: !fpu compiler
Message-ID: <1992Jun9.191557.17631@klaava.Helsinki.FI>
Date: 9 Jun 92 19:15:57 GMT
References: <manningc.708050790@marsh> 
<michaelv.708097983@help.cc.iastate.edu> 
<1992Jun9.170339.7815@nmrdc1.nmrdc.nnmc.navy.mil>
Organization: University of Helsinki
Lines: 24

In article <1992Jun9.1...@nmrdc1.nmrdc.nnmc.navy.mil> 
rd...@nmrdc1.nmrdc.nnmc.navy.mil (LCDR Michael E. Dobson) writes:
>>  [ no comprocessor, no -O and -msoft-float ]
>
>You must not have compiled anything that generates floating point
>instructions yet. (Try df)  When you do you get a string of errors from ld
>looking for the float emulation routines.  So far there is no libsoft.a :-(

Just libsoft.a isn't enough: unless somebody has hacked gcc, it still
emits the floating point load and store instructions even when compiling
with -msoft-float.  Bruce Evans fixed this at least for the 1.40
version, but the real fix is to move some emulation into the kernel. 
That also means there is no problem with binaries that work on some
machines, but not on others. 

Linux does some floating point emulation, and the source is free (but
copylefted), although I'm the first to admit that the emulation is not
very good (good enough for most things).  If somebody is interested to
use the linux code (but note that it's pretty linux-specific), I can
certainly consider changing the copyright of that part of the linux
kernel and make it totally free.  Mail me if interested, but take a look
first to see if it's too much of a bother..  Linux sources are available
at nic.funet.fi: pub/OS/Linux/kernel. 

		Linus

Newsgroups: comp.unix.bsd
Path: sparky!uunet!email!hp
From: h...@vmars.tuwien.ac.at (Peter Holzer)
Subject: Re: !fpu compiler
Message-ID: <1992Jun11.181144.11046@email.tuwien.ac.at>
Sender: ne...@email.tuwien.ac.at
Nntp-Posting-Host: quasi.vmars.tuwien.ac.at
Organization: Technical University Vienna, Dept. for Realtime Systems, AUSTRIA
References: <manningc.708050790@marsh> 
<michaelv.708097983@help.cc.iastate.edu> 
<1992Jun9.170339.7815@nmrdc1.nmrdc.nnmc.navy.mil> 
<1992Jun9.191557.17631@klaava.Helsinki.FI>
Date: Thu, 11 Jun 1992 18:11:44 GMT
Lines: 23

torv...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:

>Just libsoft.a isn't enough: unless somebody has hacked gcc, it still
>emits the floating point load and store instructions even when compiling
>with -msoft-float.  Bruce Evans fixed this at least for the 1.40
>version, but the real fix is to move some emulation into the kernel. 
>That also means there is no problem with binaries that work on some
>machines, but not on others. 

While this may be the real solution from the view-point of an OS-writer
(see, my kernel runs your binaries even though I don't have a 387!),
a compiler with an option -msoft-float should certainly be able to emit
code which doesn't rely on the presence of a (possibly emulated)
co-processor.

BTW, how fast is your FP emulation? The method used in Minix-GCC is
very slow (in fact unusable for any half-serious application).

-- 
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | h...@vmars.tuwien.ac.at                 |     Tony Rand |

Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.unix.bsd
Subject: Re: !fpu compiler
Message-ID: <1992Jun11.234203.12877@klaava.Helsinki.FI>
Date: 11 Jun 92 23:42:03 GMT
References: <1992Jun9.170339.7815@nmrdc1.nmrdc.nnmc.navy.mil> 
<1992Jun9.191557.17631@klaava.Helsinki.FI> 
<1992Jun11.181144.11046@email.tuwien.ac.at>
Organization: University of Helsinki
Lines: 54

In article <1992Jun11.1...@email.tuwien.ac.at> 
h...@vmars.tuwien.ac.at (Peter Holzer) writes:
>torv...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>
>>Just libsoft.a isn't enough: unless somebody has hacked gcc, it still
>>emits the floating point load and store instructions even when compiling
>>with -msoft-float.  Bruce Evans fixed this at least for the 1.40
>>version, but the real fix is to move some emulation into the kernel. 
>>That also means there is no problem with binaries that work on some
>>machines, but not on others. 
>
>While this may be the real solution from the view-point of an OS-writer
>(see, my kernel runs your binaries even though I don't have a 387!),
>a compiler with an option -msoft-float should certainly be able to emit
>code which doesn't rely on the presence of a (possibly emulated)
>co-processor.

The problem seems to be the sysv floating point standard: floating point
functions are expected to return their values in the fpu registers in
order to be conformant.  Thus gcc uses the fpu for loads/stores so that
library functions etc will work correctly in all cases.  It's not really
a gcc problem: gcc does the right thing for the 68k family, and it's
just the i386 binary specification that messes things up. 

>BTW, how fast is your FP emulation? The method used in Minix-GCC is
>very slow (in fact unusable for any half-serious application).

The original Minix-gcc fp emulation isn't real emulation in any normal
sense: it's more of a hack to allow minix to run the gcc-produced
binaries.  The linux emulation, on the other hand, is a real 387 emu,
even though it's not 100% complete. 

It seems the linux code might be in 386BSD version 0.1: at least Lynn
Jolitz mailed me about it, and there already seems to be a working
version available.  We'll see.. 

As to speed: the linux emulator is simple, and not too slow: the problem
is mostly in handling special cases.  There is no support for NaN's etc:
they are seldom needed under "normal" use.  I wrote the emulator so that
non-387 systems could run normal applications, and it handles that
pretty well. 

Apart from not supporting NaN's (and denormals etc), the linux emulator
doesn't try to emulate the more exotic math functions.  sqrt/sin/exp etc
still have to be done in user mode: these aren't used directly by gcc,
though, so that's not a problem.

The linux 387-emulator code is pretty simple and modular, so if somebody
wirtes these (or better add/mul/div-routines) it doesn't mean the whole
emulator has to be changed.  It also looks like a 387 to the kernel
itself for all practical purposes (using the same internal
datastructures), so dumping core etc don't have to change between
different formats. 

		Linus

			   USENET Archives


The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or 
research.


Electronic mail:			      WorldWideWeb:
   tech-insider@outlook.com		         http://tech-insider.org/