FPU on the UNIX pc

[Vernon C. Hoxie]

In article <528 at icus.islp.ny.us>, lenny at icus.islp.ny.us (Lenny Tropiano) writes:
> In article <3462 at rphroy.UUCP> tkacik at rphroy.UUCP (Tom Tkacik) writes:
> |>In article <368 at uncle.UUCP> jbm at uncle.UUCP (John B. Milton) writes:
> |>
> |>The software will be the tricky part.  First the math libraries will need to
> |>be re-written, and made compatible with the existing ones.  
> 
> I'm not to sure about this, but reading the UNIX System V User's Manual
> (vol. II) on cc(1), I saw this:
> 
> 	"The C compiler uses one of three code generators for the
> 
> 		CPU=xxxxx,FPU=yyyyy

     The Motorola Manual for the 68010 gives the following:
"Word patterns with bits 12-15 equaling 1010 or 1111 are distinguished
as unimplemented instructions and separate exception vectors are given
to these patterns to permit efficient emulation.  This facility allows
the operating system to detect program errors, or to emulate
unimplemented instructions, such as the MC68881 Floating Point
Coprocessor instructions, in software."

     The idea was that if a co-processor is on board, the control is
handed over to it, otherwise the Supervisor mode will process the data
in software.  Now the question is: Did ATT/Convergent implement the
software with this in mind?  or did they put all the options control in
the compiler?

     If they built the software as Motorola designed the chip, the FPU
instructions were used and trapped to software emulation.  The object
code produced would then work whether the machine had an FPU or not.  It
would just run slower if not.

     This is going to take some reverse engineering with a dis-assembler
if someone at ATT doesn't come up with a definitive answer.
-- 
Vernon C. Hoxie		       {ncar,nbires,boulder,isis}!scicom!zebra!vern
3975 W. 29th Ave.					voice: 303-477-1780
Denver, Colo., 80212					 uucp: 303-455-2670