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.