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