🚀 go-pugleaf

In article <165100001@uiucdcsb> robison@uiucdcsb.cs.uiuc.edu writes:
>Code generation emits a call to a floating point library.
>If the FP hardware is available, the library routine changes 
>(at run time) the call instruction to the equivalent hardware 
>instruction.  This way you pay for the subroutine linkage only 
>on the first call. The disadvantage is that self-modifying code 
>is not allowed on some architectures.

An interesting notion.  The ibm pc&at do this the other way 'round.
They get a fault (interrupt) from the instruction faulting due to
the missing floating point hardware, and insert the emulation call
in its place.  This is atleast the run-time environment provided
by PC/IX, your mileage may very.  In supervisor mode you can get away
with anything, in this case there was no protected mode (but that
is another nightmare altogether).

Modifying code in this instance is not such a bad thing, after all
what are the chances that the device will appear suddenly?  It has
the nice aspect of allowing for hardware upgrade without having to
recompile the code (which you may have only a binary for).

With the overhead only increased on the first call/execution, what is
the big flaw in this design?  Noting that in shared/retained text that
this overhead is removed by the first execution over all uses.

-- 
=
    Jim Hutchison   		UUCP:	{dcdwest,ucbvax}!sdcsvax!hutch
		    		ARPA:	Hutch@sdcsvax.ucsd.edu
panic -- no witty phrase