Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!cornell!uw-beaver!ubc-cs!fornax!oneill
From: oneill@fornax.UUCP (Richard Oneill)
Newsgroups: comp.sys.next
Subject: Re: Compiler option for Rel 3.0???? (make it a loader option)
Message-ID: <2370@fornax.UUCP>
Date: 27 Mar 91 17:20:06 GMT
References: <1991Mar26.141452.21620@ncsu.edu> <1991Mar27.062525.14935@ccu.umanitoba.ca>
Reply-To: oneill@phoenix.UUCP (Richard Oneill)
Distribution: world
Organization: School of Computing Science, SFU, Burnaby, B.C. Canada
Lines: 35

In article <1991Mar27.062525.14935@ccu.umanitoba.ca> tilley@ccu.umanitoba.ca (Richard Tilley) writes:
>In <1991Mar26.141452.21620@ncsu.edu> jcd@ecersg.ncsu.edu (Joseph C. Davis) writes:
>>i have heard all of the arguements,and know that Next left it this way 
>>to help out the 030 guys.  However, wouldn't it be possible for them to 
>>add a compiler option that replaced the trappable functions with the 
>>proper routines that the 040 can do 'lickety split?'
>
>Is it not usual for the trap, on first call, to check for hardware and, if
>not found, change the code to call a subroutine instead of taking a trap?
>
>Is this difficult on a 68K?

As I understand it, self-modifying code is not well liked by the 68040, 
since it would have to flush its code cache after the code is changed.
Also, I don't know whether you can fit a subroutine call into the space
of an FPU instruction.

However, there is a sensible idea here. Get the linking-loader (or whatever
its called) to do the work. If there is an external FPU (68030 with 68882)
then load the code into memory putting in real FPU instructions, otherwise
load the code with calls into a shared library. I wouldn't have thought
this would be too difficult.

Lets hope NeXT does do something like this, or something else, to fix
this.

	Richard.





-- 
Composing a suitably apt and witty .signature is left | oneill@fornax.UUCP
as an exercise for the reader.                        | oneill@cs.sfu.ca