Newsgroups: comp.os.minix
Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!geac!maccs!mc2
From: mc2@maccs.dcss.mcmaster.ca (Dan McCrackin)
Subject: Re: Floating point support in GCC
Message-ID: <280C657A.14449@maccs.dcss.mcmaster.ca>
Organization: McMaster University, Hamilton, Ontario, Canada
References: <AWB.91Apr15132912@mink.uk.ac.ed.aipna>
Date: Wed, 17 Apr 91 15:10:50 GMT


Hello, folks!  I've been enjoying comp.os.minix for quite some time now
(I'm running PH 1.5.10 + BDE 386 + virtual consoles + shared text + gcc on
a 25MHz 80386 with 80387), and thought I would throw my $.02 in:


In article <AWB.91Apr15132912@mink.uk.ac.ed.aipna> awb@uk.ac.ed.aipna (Alan W Black) writes:
>
>I am not sure how this would work if you actually have a 387.  I
>suspect you could recompile gcc without -msoft-float and it would 
>then generate 387 instructions, then do not load the floating point
>handler and it should work.
>

	I was all set to get out my proverbial (software) hacksaw and pliers
to get my coprocessor going, when I realized that there is, alas, a major 
problem with using a '387 (or '87 or '287 for that matter) under Minix.  At
present the kernel doesn't save the context of a coprocessor during a
context switch.  This is fine if you are only running one task that uses the
coprocessor, but would produce a fearsome mess with more than one task. :-(

There are three possible solutions
	(1) only run one fp task  (simple, but impractical)
	(2) modify mpx.x (the save and _restart sections) to always
	    save / restore the coprocessor context
	(3) use the MP and TS flags of CR0 (on the 80386) to implement
	    saving / restoring the coprocessor's context only as required.

	The problem with (3) is that while it is the most efficient approach
(save only when absolutely needed), it would (IMHO) complicate the kernel
a fair bit.
	The problem with (2) is (according to ye olde Intel manual)
an FSAVE takes > 100 clock cycles and dumps 90-some-odd bytes from the
coprocessor.  FRSTOR has similar characteristics. The $64K question is
how much impact would this have on system performance?  At least the 
method of (2) is generally applicable to 8087's through 80386's.


I ask:

(1) Has anybody patched the kernel to support the coprocessor?  (Bruce?)
If so, could you please send me a copy of the patches? 

(2) Would anybody be interested in such a patch? (I'm willing to see if I
can get solution (2) to work.)  

On an unrelated tack:
(3) Is anyone looking at getting paging (a la "virtual memory") to go on
the 386?  


				Thanks,

				  Dan McCrackin


-- 
Daniel C. McCrackin (mc2@maccs.dcss.mcmaster.ca)
Dept. of Electrical and Computer Engineering
McMaster University, Hamilton, Ontario, Canada
