Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!van-bc! From: lphillips@lpami.wimsey.bc.ca (Larry Phillips) Newsgroups: comp.sys.amiga Subject: Re: 68040 vs 80246 (Was Re: Xerox sues Apple!!!) Message-ID: <943@lpami.wimsey.bc.ca> Date: 23 Dec 89 20:54:26 GMT Lines: 116 Return-Path: To: van-bc!rnews Keywords: In <1627@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes: >In article <936@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >>In <1617@bnr-rsc.UUCP>, schow@bcarh185.bnr.ca (Stanley T.H. Chow) writes: >>>In article <824@mindlink.UUCP> a218@mindlink.UUCP (Charlie Gibbs) writes: >>>> >>>>Does anyone have any more horror stories? >>>> >>> >>>How about the inconsistancy between 68000 & 68010? (Specifically the MOVESR >>>problem). >> >>The 'inconsistency', as you call it, is a bug fix. Is it a big deal for you? >>Was it worth leaving in the machine so future genrations of the chip would have >>to have ever more kludges to work around the problem? > >You know, Charlie Gibbs asked for horror stories, I pointed out the MOVESR >*inconsistancy* and here you are calling it a *bug*! Boy, are you gonna to >get flamed by the Motorola-lovers. :-) Call it what you will... bug, inconsistency, design flaw. The point remains that MOVESR should have been a priviledged instruction. It was not, on the 68000. It is, on the rest of the line, starting with the 68010. The inconsistency/bug/design flaw was removed as of the 68010. In any case, it is far from being a 'horror story'. >It sure is nice to have my point confirmed by experts like Larry (and Dave). I don't claim to be an expert. Do you? >>>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. >> >>You are one sick puppy. You remind me of the fellow with the broken watch who >>won't get it fixed because he is used to the way it loses time, and having one >>that worked would only confuse him. >You are one closed-minded loud-mouth sicko bleeding-heart conservertive. Thank you. I see you have me pegged quite nicely. >Now that I called you names right back, feel better? Shell we get on with >a discussion with information? Would you like to tell me *why* you object >to that approach? Yes. I object to that approach because every succeeding incarnation that carries the bugs/design flaws/inconsistencies of the previous incarnations needs the same workarounds; the same gyrations, and stifles progress. If a processor is well thought out to start with, there need be no carryover of braindead bits. In my opinion, Intel should have done a complete redesign at the 8086/8088 level, and stopped mucking with full compatibility to their previous stuff. >>>How about the '020 MMU being a subset of the '851 MMU? Not a bug, but >>>certainly an extremely undesirable feature for a later member of any >>>architecture family. > ^^^^^^^^^^^^^^^^^^^^ >> >>Undesirable feature? How would you suggest implementing the I/O stuff, when the >>MMU has been moved inboard and made inaccesible to the I/O? > >Are you saying there is no other difference? As I recall, the difference is >quite a bit more than that. But then, I haven't checked the details for >quite sometime. I haven't either. I happened to use that one example to point out that the internal MMU need not be a full implementation of the external MMU. >>Tell me.. how many 8080's are in the latest CPU array from Intel? > >I don't know. Why do you ask? > >Ohh, I get it. This is a clever way of saying that Intel does as badly as >Motorola! No, this is a way of saying that all the anachronisms of the 8080 are present in the entire family. Motorola learned a lot from the 6800 and 6809, and decided that carrying the baggage into their next line was no appropriate. That there was a problem in the 68000 is beside the point. It was changed to be a non-problem in the 68010, requiring workarounds only in the single processor that had the problem, rather than in all succeeding processors. >It is really strange and annoying that critizism of Mac's automatically >trigger attacks on PC's, any discussion of Motorola gets Intel draged in >as well. Why can't we discuss the 68K on its own merits? Do you consider >its case so weak that you have to bloster it with weaknesses of other >processors? It is really strange and annoying that you say this, when you yourself have brought up points about Intel, as in your statement above: "For myself, I prefer the Intel approach -". I am addressing those statements, among others. I am not addressing Mac issues. >In any case, your question is truly unrelated to this discussion. I was >talking about members of one architecture family. You may be talking about members of one architecture family, but I assure you that the perception from this end is that you are talking about two different philosophies of architectural design, and are including Intel and Motorola's examples of the two philosophies. >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. Merry Christmas, Stanley. -- " All I ask of my body is that it carry around my head." - Thomas Alva Edison - +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+