Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.micro Subject: Re: ANOTHER 32-BIT MACHINE??? (L O N G) Message-ID: <5546@utzoo.UUCP> Date: Fri, 26-Apr-85 13:34:23 EST Article-I.D.: utzoo.5546 Posted: Fri Apr 26 13:34:23 1985 Date-Received: Fri, 26-Apr-85 13:34:23 EST References: <9254@brl-tgr.ARPA> <1549@watcgl.UUCP> <5355@utzoo.UUCP> <5371@utzoo.UUCP>, <103@daisy.UUCP> Organization: U of Toronto Zoology Lines: 143 > Mr. Spencer claims the 80386 must use 8086 addressing constructs. ... Not quite in so many words. I claimed that the thing cannot simultaneously be 100% 8086 compatible and still have large (>64KB) contiguous chunks of memory. Your comments confirm this: you either run in 8086 mode, with 8086 addressing, or run in native mode and lose complete 8086 compatibility. Actually, I'm not complaining so much about this tradeoff, as about the Intel marketing hype that tries to sweep it under the rug. > Mr. Spencer suggests that delivery on the 80286 is poor. This is untrue. > My company has no problems getting production delivery of 6 MHz '286s... Since I personally wouldn't touch an 80anything with a ten-foot pole, I obviously have no personal experience with 80286 delivery. But there's certainly been a remarkable chorus of "we're late because Intel's late" from the industry. > Mr. Spencer states "They [Intel] made a conscious decision (well, they > may not have considered it in quite those terms) to go for quantity rather > than quality." Again, this is untrue. The former head of the design team > for the Intel 80186 is a founder and employee of my company. Many other > members of the 80186 design team are now employees of Daisy as is one of the > lead microcoders for the 80286 and one of the members of the 8087 team. I > have talked with most of them, complaining about the 8086 architecture. The > universal answer is that Intel optimized time-to-market and compatibility. > Intel succeeded. Precisely! They succeeded in a strategy that stressed time-to-market (getting in before the competition, to increase *quantity* sold) and compatibility (making it look like previous products, to make it more attractive and increase *quantity* sold) rather than paying attention to quality and giving it a decent-sized address space and a civilized register structure. Note here that I am not knocking Intel for getting a mediocre product to market quickly, instead of taking the time to produce something better. The relative sales figures clearly demonstrate that their decision was reasonable. I just wish Intel would stop pretending that their out-the-door-fast chip is every bit as good as the products from people who *did* invest the time in improving the architecture. Note also that I am not contending that Intel's chips themselves were shoddy. The quality issues of which I speak are matters of architecture, not design bugs or fabrication problems. > ... As of this writing, Motorola is sampling the > 68020 and National is sampling the 32032 and some day, both of these fine > companies will deliver their beautifully architectured chips. ("Archi- > tectured"?!) But Intel is delivering '286s now! ... Motorola has been delivering 68000s and 68010s for rather a long time, well before Intel started delivering 80286s. Let us not even *mention* when deliveries of the 80386 will start; I was reading about the wonders of the 80286 quite a while ago, and it's just starting to show up. > My company chose Intel because, at the time, only Intel had [support and > delivery]... Similarly, I'm not criticizing *you* for choosing stew now rather than filet mignon this evening. But some people would choose differently. > ... In non-partisan CAE > benchmarks, the '286 at 6 MHz beats a bit-slice version of the 68000, the > 68010, and various 68000s time and time again. By any chance, were these "non-partisan CAE benchmarks" such that none of them needed arrays larger than 64KB? > 4) Mr. Spencer claims "software package X is either totally unavailable or > is very late, because the producers had trouble making it fit the 8086." Tell > that to the developers of Lotus 1-2-3, DBase II, Wordstar (ugly but verrrry > profitable), and so on. Then ask them how much earlier the stuff would have been done with a better architecture. Especially one that was hospitable to a high-level language. (Don't claim the 80*86 is hospitable to HLLs until you have computed the performance hit taken by "large model" code.) Certainly the people *I* know who've done applications work on an 80*86 have not been happy about it. > The biggest number of software packages are available for the Apple ][. The > IBM PC, based on the 80*86 architecture, is in second place. The IBM 370 is, > I believe, in third place. Somewhere much farther down the list are the > Motorola and National architectures. Since the Apple II is in first place, are we to conclude that the 6502 is a better processor than the 80*86? Or that writing software for the (truly vile) 6502 is easier? All this argument demonstrates is that if you want to make money, you make whatever sacrifices are necessary to get your software to run on popular abominations rather than on well- designed machines that don't sell as well. > 5) Mr. Spencer states that although machines with artistically nicer > architectures cost more than machines based on the abysmal 80*86 architecture, > "Tinplate is cheaper than steel." His statement is true but not particularly > relevant. You may be willing to wait for perfection but your competitors > aren't! I'd rather drive a Civic now than wait to save the money for a > Cadillac with tail fins and power seats. But if you want to move heavy loads, you'll save up for a truck rather than wrecking the suspension in your Civic. My statement *is* relevant: tinplate is generally available sooner than steel, but it's not as useful. By all means, use tinplate if it's good enough... but remember that things change, and your future needs may require messy and expensive reinforcing. > The end user is not going to notice > the beauty of the underlying machine architecture. All s/he cares about is > "can it do the job", "when can I get it", and "how much does it cost?" (And, > for smarter end users, "who supports it?") *I* certainly would charge more for future support of software that was constrained to fit on an 80*86. Not to mention initial development. > In conclusion, Mr. Spencer, in deriding the importance of backwards compat- > ibility, shows ignorance of fundamental market forces. Not recognizing the drawbacks of backwards compatibility shows ignorance of the horrendous problems that "backward compatibility with all previous mistakes" can cause your company. Ask IBM just how smart it was to let the upper bits of an address be used for other things, or ask DEC just how much fun they're having supporting ever-growing software products on machines with only 16-bit addresses. They'll tell you what backward compatibility can be like. > (Oh, I should be a > professor-- but could I retain any self-respect?) Gee, so should I. I'm a software developer and maintainer by profession, not an educator. > Addendum: Architectural purity is fun but you can't make money off it. "Good > enough is perfect." Losing your customers (or grad students) because you > waited for a better chip is inefficient, unless you have divine guidance. My impression was that Motorola's cleaner architecture is making them quite a bit of money, actually, and that Intel is losing the important high end of the market. ("Important" because that's where the whole market will be before too very long.) "Not good enough is really the pits." Increasing your next quarter's profits at the expense of next year's is not just inefficient, but potentially ruinous. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry