Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.7 9/23/84; site daisy.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!nsc!daisy!david From: david@daisy.UUCP (David Schachter) Newsgroups: net.micro Subject: Re: ANOTHER 32-BIT MACHINE??? (L O N G) Message-ID: <103@daisy.UUCP> Date: Sun, 21-Apr-85 03:08:34 EST Article-I.D.: daisy.103 Posted: Sun Apr 21 03:08:34 1985 Date-Received: Tue, 23-Apr-85 06:19:22 EST References: <9254@brl-tgr.ARPA> <1549@watcgl.UUCP> <5355@utzoo.UUCP> <5371@utzoo.UUCP> Reply-To: david@daisy.UUCP (David Schachter) Organization: Daisy Systems Corp., Mountain View, Ca Lines: 113 Henry Spencer of U. of Toronto Zoology makes several points with which I disagree. My information is obtained from two Intel seminars on the 80386 I have attended and it is not covered by any confidentiality agreement. 1) Mr. Spencer claims the 80386 must use 8086 addressing constructs. This is not correct. The 80386 can run programs in 8086 mode (just like the 80286) or in 'native' mode. In 'native' mode, programs can consist of mixed segments of '286 and '386 code. '286 code segments follow the '286 address model: a 16 bit selector selects one of 16,384 segments and a 16 bit offset selects a byte out of 64 kB. '386 code segments follow the '386 address model: a 16 bit selector selects one of 16,384 segments and a 32 bit offset selects a byte out of 4 GB. The mapping of selectors to segments is done by two tables: the Global Descriptor Table and the Local Descriptor Table, either of which may be changed at any time. Typically, the GDT doesn't change much and the LDT is changed as part of each context switch. Thus each task has an address space of 2^16 * 2^32 = 2^48 bytes. The physical address space is 16 MB which should be sufficient until 1988. By then, one hopes Intel will have a "386B" or some- thing. Note that 8086 code can usually be run even in native mode. Only certain types of address arithmetic (which the 8086 supports but you warned not to use) won't work. 2) 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 from Intel. We have found Intel to be a most reliable and cooperative vendor. Delivery by Intel of production quantities of various VLSI chips has always occurred, for us, in a timely fashion after delivery of sample chips. And sample chips are delivered on the date promised. There was an early glitch with delivery of '286s, in December of 1983. Intel warned us about it some months ahead of time and we were able to compensate. (Not only did Intel warn us, they also told us why the glitch occurred and what they were doing to insure against a re-occurrence.) 3) 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. My company chose Intel because, at the time, only Intel had development machines, a good compiler, debugger, and other software, strong support, and the ability to deliver chips. 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! I don't know about you but Daisy's customers want deliveries, not promises. 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. Intel created a part with an ugly architecture that runs fast and delivered it when the market needed it. (Intel, according to a survey by one of the professional research companies, has about 70 percent of the high-end market. Moto and National share most of the remaining 30 percent.) 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. Writing software for the 80*86 is no more difficult than for other systems, not to any practical extent. Porting 80*86 software to other systems is easy. Porting software from other systems to the 80*86 is often difficult, unless you have a good compiler. (Even then, for top performance, you will have to tweak the code.) 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. 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. 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?") In conclusion, Mr. Spencer, in deriding the importance of backwards compat- ibility, shows ignorance of fundamental market forces. (Oh, I should be a professor-- but could I retain any self-respect?) IBM has succeeded because it supported its products to the hilt (like Intel) and, in particular, because it maintained backwards compatibility. Apple has succeeeded because newer versions of the Apple ][ maintain compatibility with older versions. (Mac is still only a small share of Apple revenue, according to published reports.) And Intel has succeeded because its microprocessors are always backwards compatible, to some extent. (Usually in architecture if not in software.) Much early 8086 software was terrible-- it was merely translated 8080 software. (Written in PL/M and re-compiled with PL/M-86 or written in ASM and converted with CONV-86.) But at least it was available! Motorola and National had no similar capability and it has cost them dearly. Who will win? If I knew that, I would be a lot richer. But Intel has done quite well with the 8088, the 8086, and the 80286. The improved architecture of the 80386, while still not as good as the National architecture, is sure to be a winner-- because it is COMPATIBLE with the 8086 and the 80286-- just as VAX compatibility with the PDP-11 was an important factor in the early success of the VAX and gave DEC time to solidify its market position. -- David Schachter [The expressions expressed herein are my own and are not the responsibility of Daisy Systems Corporation. I have no financial interest in Intel Corporation, its affiliates, competitors, or stockholders.] 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.