NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/mac/misc/19557

Internet Message Format | 1992-11-22 | 6.0 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!netnews.upenn.edu!netnews.noc.drexel.edu!king.mcs.drexel.edu!tjhendry
From: [e-mail] (Jonathan Hendry)
Newsgroups: comp.sys.mac.misc
Subject: Re: Apple Crippling Systems?!?
Message-ID: <[e-mail]>
Date: 23 Nov 92 05:10:58 GMT
References: <[e-mail]> <[e-mail]>
Distribution: usa
Organization: Drexel University
Lines: 116

In article <[e-mail]> [e-mail] (Operator) writes:
>In article <[e-mail]> [e-mail]
>(Jonathan Hendry) writes:
>> In article <[e-mail]>
>[e-mail] (Avery Wang) writes:
>> >In article <[e-mail]> [e-mail]
>(Evan
>> >Torrie) writes:
>> >> [e-mail] (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" :)
>> [e-mail] (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

The point is that, I believe, the floating point operations that WERE
implemented don't work. In other words, Motorola makes an 040. They test
it, and find that the floating-point operations are not "up to spec". So
they sell it as the 680LC40 (or something to that effect) as an 040
minus the floating point functions. You are correct about the 68040 and
floating point operations. However Motorola does sell a low-cost 040.
How else would they do that? The on-chip PMMU operations are more crucial
than FPU operations, I would think, so they would sell 040's without functional
fpu operations.

Another way of looking at it is that on the 680LC40, ALL floating-point is done in software, and not just the trans. functions.

Remember, I'm not knocking the 040. Hell, I own a NeXT Cube 040, and it
doesn't suffer from not having a coprocessor. (After all, Postscript
coordinates are floats, and it runs pretty darn quick).

In a nutshell, "crippled" doesn't refer to the 68040 itself, but to a less expensive verion of the 68040.

No offense intended!
--
Jonathan W. Hendry
Drexel University College Of Information Studies
Anderson Financial Systems "Programmer-in-Exile" :)
[e-mail] (No NEXTMail :( )