From: root@cmn4.Stanford.EDU (Operator)
Subject: Re: Apple Crippling Systems?!?
Organization: DSO, Stanford University
Date: Mon, 23 Nov 92 02:20:47 GMT

In article <1992Nov22.192801.25870@mcs.drexel.edu> tjhendry@mcs.drexel.edu  
(Jonathan Hendry) writes:
> In article <1992Nov22.045325.23107@leland.Stanford.EDU>  
avery@ccrma.stanford.edu (Avery Wang) writes:
> >In article <torrie.722399595@Xenon.Stanford.EDU> torrie@cs.stanford.edu  
(Evan  
> >Torrie) writes:
> >> avery@cmn7.Stanford.EDU (Avery Wang) writes:
> >> 
> >> >Well, let me point out that the NeXT doesn't have a FPU either, and  
> >> >although it could benefit from a coprocessor, it does reasonably.   
The  
> >> >reason is that the 040 has half a math coprocessor built in.  It  
does  
> >> >+,-,*,/, sqrt, abs, and a few others, but not the trancendentals.   
On the  
> >> 
> >>   Ahhh, misinformation reigns supreme.
> >>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >>   There is no such thing (as far as I'm aware on the market) of a 
> >> separate math coprocessor for the 68040.  The 68040 has a built-in
> >> math coprocessor, albeit does not include transcendentals (in 
> >> this respect, it is just keeping up with the RISC chips).  
> >
> >
> >Wait a minute--I didn't claim that there was a coprocessor for the  
'040! And  
> >the rest of what you said is just what I said!  Where's the  
misinformation?  
> >
> >-Avery
> 
> The point is that you misunderstood the original post. There is no  
separate
> FPU chip. No one in this thread has claimed otherwise. The issue is that 
> Apple will sell computers which use Motorola's "crippled" 040. That  
chip's
> floating-point capabilities are non-existent. In other words, the  
on-chip
> fpu is non-functional.
> -- 
> Jonathan W. Hendry
> Drexel University College Of Information Studies
> Anderson Financial Systems "Programmer-in-Exile" :)
> hendryjw@duvm.ocs.drexel.edu (No NEXTMail :( )

Now this is getting out of hand!  Be careful of such potentially  
inflammatory language.  Go back and read what I said more carefully before  
telling me that I misunderstood anything.  If people keep insisting on  
misunderstanding me then I refuse to participate further in this thread.   
I have better things to do with my time.

I don't know what you mean by the on-chip FPU being non-functional.   
Motorola never claimed (to my knowledge) to have implemented the full FPU  
instruction set in the '040.   And what I said stands, but let me  
elaborate slightly.  They implemented *some* of the FPU instructions, but  
not the transcendentals.  I agree that this is not the best of all  
possible worlds, but the thinking (as was explained to us NeXT users) was  
that these instructions could be implemented in software, and there are  
very efficient algorithms for doing so.  The FP registers, etc. are now  
on-board, and the '040 averages about 1.3 clock cycles per instruction.   
With an FPU coprocessor you have to sit there and wait for it to do  
iterations for the transcendental algorithms anyway (like for the CORDIC  
algorithms, etc.), unless your CPU can do parallel fetch/execute and  
dependency checking (like any superscalar RISC).  So the extra silicon  
real-estate may not be worth it.  So this is the theory anyway.

So the distinction in interpretation is between:
	(1) Trying to implement the full FPU and failing
			OR
	(2) Trying to implement a partial FPU and succeeding.
Your interpretation of what happened at Motorola is (1).  I don't have a  
strong interpretation of what happened.  Maybe they were more ambitious at  
one point in the design stage.  Maybe not.  I don't know.  Whether it's  
"crippled" is another issue.

  The point I made in my original contribution to this thread is that the  
NeXT doesn't seem to suffer drastically from the lack of a math  
co-processor.  Although their implementation isn't optimal because they  
use system traps instead of direct compiles in order to maintain  
compatibility with the 68030/68882 mix, which is obsolete anyway.  I hope  
that they support direct FP code simulation in their compiler in the  
future.  But this may be moot because they will introduce a RISC  
workstation "Real Soon Now"...  Any elaboration on this topic belongs in a  
different newsgroup.

But doesn't the Mac use instruction traps shamelessly instead of civilized  
shared-library subroutine calls?

-Avery