🚀 go-pugleaf

In article <394@houxs.UUCP>, daw@houxs.UUCP (D.WOLVERTON) writes:
> In some systems, the hardware floating point (fp) unit is _optional_.

> 4)  Code generation emits code which always causes transfer to the
> OS, e.g. by illegal opcodes or TRAP instructions.  The OS then
> proceeds like (3a) or (3b) above except that the fp unit may be used 
> if present.
> 
> 	Are there other scenarios in use?

According to my memory, (which operates on fuzzy logic :-), the
Sun-2 had several different optional FPU boards.  The compiler
would generate code that always trapped to the OS.  Then:

No FPU:
	OS calls a subroutine to do the work.

FPU:
	OS replaces the user instruction (a 68010 TRAP) with
	the equivalent hardware instruction.  The user program
	is then restarted at the new instruction, which now
	causes the FPU to do the work.

I like this scheme.  The overhead of going into the OS is only
paid once (assuming you actually have a FPU).  Once the OS changes
the TRAP instruction, further FP work goes directly to the hardware,
without software intervention.

Of course, this had to be done once to each different FP instruction.
In a large program, that could take a while.  On the other hand, the
most popular instructions should be replace fairly quickly.

Anyone (particularly old Sun engineers) care to correct my memory?
-- 
	David S. Hayes, The Merlin of Avalon
	PhoneNet:	(202) 694-6900
	ARPA:		merlin%hqda-ai@brl
	UUCP:		...!seismo!sundc!hqda-ai!merlin