Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/17/84; site opus.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!hao!nbires!opus!rcd From: rcd@opus.UUCP (Dick Dunn) Newsgroups: net.arch Subject: Re: 386 Architectural Description Message-ID: <181@opus.UUCP> Date: Wed, 30-Oct-85 03:53:21 EST Article-I.D.: opus.181 Posted: Wed Oct 30 03:53:21 1985 Date-Received: Fri, 1-Nov-85 03:12:03 EST References: <130@intelca.UUCP> Distribution: net Organization: NBI,Inc, Boulder CO Lines: 81 I have mixed reactions to the parent 386 "product brief". I'm not about to flame about commercial information--it's nice to get some word about what's coming up. However, there was an awful lot of pitch to wade through to find the real information. Doing a breakout of words from the article and frequency-counting them showed the two most common, after discarding articles and prepositions, to be "high" and "performance". Maybe it's the marketing style of writing that made it seem so non-technical. > ...The 80386 brings to > these application an unprecedented performance of 3-4 million > instructions per second,... I would be quite happy if we NEVER saw any such non-measures again in this newsgroup. Instructions per second, with no other qualification, says almost nothing useful. (A 10 MHz 68010 can run 2.5 mips--if they're the right instructions.) Anyway, what's "unprecedented" about this rate? >...o Object-code compatible with all iAPX 86 family processors I wish folks would learn what the word "compatible" means. I shouldn't be picking on Intel here, but if you say that you've got compatibility, it means that you can not only run 8086 code on a 386 but you can run 386 code on an 86. "Upward compatible" is a rather different, much more restrictive term. > For the convenience of compiler writers, the 80386 provides multiple > addressing modes, a capability which ensures that high-level languages > can be implemented in the most efficient manner possible. Scaling by > data type is supported for direct indexing of arrays without the need > to perform math explicitly on an effective address. This is the sort of paragraph that gives me the mixed reaction. The first sentence is very nearly content-free. (As a compiler writer, I know that only a very few addressing modes are useful; beyond that they just complicate the compiler. And as far as some of the odd ways I've seen for encoding addressing information--if I never have to produce another segment override byte in my life it will be a spot of joy.) On the other hand, the information about scaling (presumably meaning the same idea that already exists in the NS 320xx and the 68020) is good news--though I'm hoping that "performing math on an effective address" really means "shifting an index". (Could it actually be multiplication? That would be a lot to hope for. I'd prefer something accurate to "math".) > The 80386 instruction set is marked by both power and flexibility. It > offers the compiler writer and assembly language programmer a broad > range of choices in which operations and data can be specified. Again speaking as a compiler writer, if there's one thing that's a pain in the... ...code generator, it's "a broad range of choices..." The fewer ways there are to do things: - the fewer choices the compiler has to make - the fewer chances it gets to make the wrong choice - the less time it has to spend making choices - the less time the compiler-writer has to spend teaching the compiler to make these choices I understand the architectural attitude that has given ever-richer instruction sets and addressing structures--but by and large these have not only NOT been helpful to compiler writers; they've led to compilers which are larger, slower, less reliable, and yet use an ever-decreasing subset of the hardware's capability. Save the "broad range of choices" for assembly language folks; give the compiler people simple, FAST machines. Some of the good-news items, as I see it: - Segments are finally large enough that they can be ignored. - It looks like Intel is buying into the IBM VM-style of handling existing programs running under existing systems. It can be clunky, but at the same time it can be effective and it's a good marketing tool. The article mentioned something to the effect of "generalized register" structure. Does this really mean anything new? I know there are more segment registers; apparently there are no more "data" registers. (Why is this?) Are the segment registers of greater capability than in the past? Specifically, can any of them (say, other than SS and CS:-) be used as general 32-bit operands? -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...At last it's the real thing...or close enough to pretend.