Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!uunet!mcsun!ukc!edcastle!aiai!richard
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.os.minix
Subject: Re: Software floating point for 386 Minix with GCC (and 286 Minix?)
Keywords: Minix 386 GCC Floating Point FP 387
Message-ID: <3449@skye.ed.ac.uk>
Date: 25 Sep 90 18:55:50 GMT
References: <12653@sdcc6.ucsd.edu> <3433@skye.ed.ac.uk> <1990Sep25.055949.15631@syd.dit.CSIRO.AU>
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 25

In article <1990Sep25.055949.15631@syd.dit.CSIRO.AU> evans@syd.dit.CSIRO.AU (Bruce.Evans) writes:
>-msoft-float doesn't actually work in gcc 1.37 for the 386. 

I posted a bug report to bug-gcc about this.

>The main thing wrong was indeed returning soft
>floating point values in a hard FP register! 

The example I posted was doing this.  Could you send a bug report
showing the other cases you mention to bug-gcc?  I imagine they'll want
to fix it.

Since I couldn't understand gcc's machine description, I adopted a
different approach (read: hack).  I wrote __adddf3() etc in C, and
wrote an emulator for the load/store instructions only and linked it
in as a signal handler.  I also modified crtso.s to install the signal
handler and signal.c to (yuck) prevent it from being uninstalled.
Sick, but it seems to work (not seriously tested yet).  I don't care
about fp speed.

-- Richard
-- 
Richard Tobin,                       JANET: R.Tobin@uk.ac.ed             
AI Applications Institute,           ARPA:  R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk
Edinburgh University.                UUCP:  ...!ukc!ed.ac.uk!R.Tobin