jcd@ecersg.ncsu.edu (Joseph C. Davis) (03/26/91)
I have a question for the Next people. there has been some lengthy discussion about the slowness of the traps for the trancendental functions in the compiler. 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?' i think that this would be a good addition for 3.0, don't you? you see, i am having this problem showing off my super fast 15MIPS machine when all fo the useful things that i do ( spice mostly ) contain **LOTS** of trancendental calls. my DEC3100 definitely beats the pants off of my Station, and it shouldn't. jcd -- Joseph C. Davis North Carolina State University e-mail: jcd@ecegabriel.ncsu.edu * People are not basically stupid - they just act that way.* -me
tilley@ccu.umanitoba.ca (Richard Tilley) (03/27/91)
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?
oneill@fornax.UUCP (Richard Oneill) (03/28/91)
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