Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ucla-cs!sdcrdcf!trwrb!desint!geoff From: geoff@desint.UUCP (Geoff Kuenning) Newsgroups: comp.sys.m68k,comp.sys.intel Subject: Re: Re: Re: Recent Motorola ad seen in Byte Message-ID: <652@desint.UUCP> Date: Tue, 21-Apr-87 01:28:37 EST Article-I.D.: desint.652 Posted: Tue Apr 21 01:28:37 1987 Date-Received: Wed, 22-Apr-87 03:40:22 EST References: <930@intsc.UUCP> <1517@ncr-sd.SanDiego.NCR.COM> <932@intsc.UUCP> Reply-To: geoff@desint.UUCP (Geoff Kuenning) Distribution: comp Organization: Interrupt Technology Corp., Manhattan Beach, CA Lines: 86 Xref: mnetor comp.sys.m68k:381 comp.sys.intel:172 In article <932@intsc.UUCP> tomk@intsc.UUCP (Tom Kohrs @fae) writes: > Not at all! The 8086 architecture was a real nice way of extending the > address range back in the days when the dominate machine was the 8085 and > Z-80. Swapping segment registers to change address was so much nicer than > doing bank selections or overlays. The 286 architecture is considerably > nicer than what was the dominate 16bit mini at the time, the PDP-11. In > 1980 the idea that you could get the cpu power of an 11/70 on a chip with > a cleaner memory management model got a lot of people excited. What a blatant misrepresentation: (1) The PDP-11 is a 1960's architecture. The 8086 was designed in the late 70's, *after* the publication of Gordon Bell's book where he states, "the most embarassing thing about the PDP-11 was that, only two years after its introduction, we found it necessary to widen the processor address." But did Intel learn from DEC's mistake? (2) The *only* place where the PDP-11 loses to the 8086 is in the 8086's clever use of instruction prefixes to provide bank switching (that's all segments are). The PDP-11 doesn't have any registers with wierd private characteristics. By contrast, even on the 80386, if you want to shift by a variable shift count, it *has* to be in a particular register. How flexible. (3) Although it is true that the 808x series was the dominant MICROPROCESSOR CHIP (not the dominant machine, by any stretch of the imagination), it is also true that there were *lots* of better architecture examples around. The 6800 literally leaps to mind. (4) Tom also conveniently ignores what a loser the 8085 was. Essentially no changes from the 8080. Check out the 6809 by contrast, or compare the PDP-11/70 with the original 11, the 11/20. (5) The basic reason for the 8086's kludgey architecture was not because it was a better design than the 11/70. It was because Intel saw binary compatibility with the 8080/8085 as a critical goal. That's forgivable; nobody at the time could have seen that MS/DOS was going to kill CP/M-86. But contrast DEC's approach with the VAX. They got compatibility with no kludges, and their customers don't seem too unhappy. > What caused most of the frustration toward the 286 was DEC and Motorola > both went to a 32bit programming model at that time. Programmers quickly > jumped to arms to adhere to the old maxim of using all of the available > memory plus one byte. When these neat new programs (ie BSD 4.x) were > forced back down to the 16 bit architecture things got tricky. Many > programmers decided that programming in a 32 bit environment required > less effort and less need for structure than the 16 bit environment and > so to justify their not liking to work on 16 bit machines they were labled > as being kludges or obsolete. Again a blatant misrepresentation, if not an out-and-out lie. Having just finished mentioning the difficulty of doing overlays on the PDP-11, Tom now tries to sell us on the idea that it's lazy programming that creates such big code. And he conveniently ignores the need of many programs for large data spaces. I did a PDP-11 application once that called for "arbitrarily complex" databases (within the limitations of disk space) in the spec. We did it, but the 64K restriction was a bloody *pain*. I guess it's just "lazy programming" that kept me from doing arbitrary complexity within 64K... > The only thing I could fault Intel for is possibly not going to a 32 bit > architecture sooner, but we were too busy building 80186's (5-6 million > sold so far). Also we were learning about how to build an MMU (the hard > part) without having to debug 32 bit ALU's at the same time. Funny, I don't recall Intel introducing an MMU before the 80386 (certainly the garbage in the 286 doesn't qualify as an MMU, not given what competitors were doing). Guess the learning curve was pretty steep. And 32-bit ALU's are not much of an excuse; there was something of a surfeit of examples, and in any case widening an ALU is not what most people consider a difficult problem. (On the other hand, to be fair, the '386 MMU is a big winner.) As to number of parts sold, the IBM 650 was pretty successful in its day, too, but I wouldn't defend it as a modern architecture. > The design > decision that was made 9+ years ago was do we build a slow 32bit machine > or a fast 16 bitter. Intel decided on the fast 16bit, Motorola went for > the slow 32 bit. The rest is history. One of Intel's favorite misrepresentations. It handily ignores the fact that the 68k is just as fast in "small model" and that it is *much* faster in "large model" or even in any application where you have to store numbers bigger that 64K (accounting? what's that?). And it also completely ignores the 6809, which was pretty successful in its own right. Back to used cars, Tom. At least then your customers won't see through you. -- Geoff Kuenning geoff@ITcorp.com {hplabs,ihnp4}!trwrb!desint!geoff