Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!bnrgate!bnr-fos!bigsur!bnr-rsc!bcarh185!schow
From: schow@bcarh185.bnr.ca (Stanley T.H. Chow)
Newsgroups: comp.sys.amiga
Subject: Re: 68040 vs 80246 (Was Re: Xerox sues Apple!!!)
Message-ID: <1624@bnr-rsc.UUCP>
Date: 22 Dec 89 04:29:50 GMT
References: <824@mindlink.UUCP> <1617@bnr-rsc.UUCP> <668@bmers58.UUCP>
Sender: news@bnr-rsc.UUCP
Reply-To: bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow)
Organization: BNR Ottawa, Canada
Lines: 68
Summary:
Followup-To:
Keywords:

In article <668@bmers58.UUCP> keithh@atreus.UUCP (Keith Hanlan) writes:
>In article <1617@bnr-rsc.UUCP> bcarh185!schow@bnr-rsc.UUCP (Stanley T.H. Chow) writes:
>>For myself, I prefer the Intel approach - that is, make the successors
>>have exactly the same bugs as well. That way, a pin-compatible '010 will
>>really be pin-compatible.
>
>Come now Stanley, you're going to get roasted for this one so let me
>start :-) Remember that this philosophy is what has given rise to our
>IBM mainframes with their 30 year old architecture complete with punch
>cards... Heck - they aren't even bugs so much as anachronisms and
>deficiencies. Bugs are even worse.

This depends on your point of view - do you want a pretty architecture
or do you want to get some work done. For esthetics, of course I would
like to see bugs fixed, loosed ends tidied up, but this is of little
concern to the Real World. In order to put bread on the table, work has
to get done. This means bugs that have work-arounds should be left alone.
Changing the behaviour of a system just to remove anachronisms is simply
not a cost-effective thing to do. 

For example, are you happy that the MOVESR instruction is priviledged on
the '010? Or would you rather see it the same as the '000 so that we can
drop '010 into the '000 socket and not worry about decigel, etc.? What 
did this change buy us? The *conceptual* ability to virtualize a '010!
Whoppie. How many people do you know run virtual '010? How many simply
use the '010 as a faster '000?


>
>No, I think it's smarter the bite the bullet as many times as necessary
>to keep the bites small and manageable. This is the only way to permit
>progress.

It all depends on how expensive each bite is. In many cases, a small
bite is just expensive as a big one - it is the existance of a change
that trigers regression testing, etc. The size of the change does not
really affect the cost.

There is also the problem of why should I bite the small bullet now when
I have the option of not biting any bullet ever? This of course depends
on whether you are designing or using a system. I, as a user, don't want
to see incompatible changes. So what the designer of the system has to
sweat bullets to make the new system compatible - this is what they get
paid for.

>>
>>How about the '020 MMU being a subset of the '851 MMU? Not a bug, but
>                ^^^ - do you mean the '030? See Dave Haynie's earlier
 Silly typo, of course I meant the '030,
>comments on this. If you really need it - which most will contend you
>don't - add the '851 anyways.

This is what I call a bug in the "Family Architecture": put an MMU into
the CPU just so that you can disable it and add an off-chip MMU. Brillant
use of the silicon real estate.

What I tried to point out is that in some ways, the 68K family is not
well thought out in terms of functions provided and the partitioning of
the functions that are provided. This is not to say that Motorola is
incompetent, everyone makes mistakes. Considering the age of 68K family,
I think Motorola has done remarkably well, I just don't think they have 
been perfect.


Stanley Chow        BitNet:  schow@BNR.CA
BNR		    UUCP:    ..!psuvax1!BNR.CA.bitnet!schow
(613) 763-2831		     ..!utgpu!bnr-vpa!bnr-rsc!schow%bcarh185
Me? Represent other people? Don't make them laugh so hard.