Path: utzoo!attcan!uunet!mcsun!ukc!edcastle!aiai!richard
From: richard@aiai.ed.ac.uk (Richard Tobin)
Newsgroups: comp.os.minix
Subject: Re: 386 Minix with GCC, and what it can do.
Keywords: Minix 386 GCC
Message-ID: <3433@skye.ed.ac.uk>
Date: 19 Sep 90 19:17:35 GMT
References: <12653@sdcc6.ucsd.edu>
Reply-To: richard@aiai.UUCP (Richard Tobin)
Organization: AIAI, University of Edinburgh, Scotland
Lines: 33

In article <12653@sdcc6.ucsd.edu> dbrown%ece@ucsd.edu (David L. Brown) writes:
>The biggest problem I have encountered is the need for an 80387.
>This chip is expensive.  The compiler currently performs a small
>floating point operation in the optimizer.  This supposedly can be
>faked without using floating point routines.  The compiler will
>still crash the machine if it encounters a floating point constant
>in a program.

I have also been looking at gcc for 386 Minix.  Cross-compiling was
*very* tedious.

Unfortunately, the gcc machine description for the 386 uses floating-
point instructions even if -msoft-float is used, so it's not enough
to find the usual floating-point routines.  I suspect it wouldn't be
hard to change the machine description to fix this (it may be just
that it expects to receive floating function return values in an fp
register).

Of course, this shouldn't crash the machine.  The reason it does is
that Minix doesn't set the EM bit to indicate that 387 instructions
should be trapped.  If it did, you would just get a core dump.  This
is easily fixed - perhaps someone more familiar with the kernel code
could decide just where it should be done.  The 387 programmer's
reference provides a routine for detecting whether a 387 is present.

More ambitiously, has anyone written 387 emulation routines for
Minix so that programs can just pretend the 387 is present?

-- 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