Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site umd5.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!seismo!umcp-cs!cvl!umd5!zben
From: zben@umd5.UUCP
Newsgroups: net.arch
Subject: Re: 386 Architectural Description
Message-ID: <776@umd5.UUCP>
Date: Tue, 5-Nov-85 02:08:52 EST
Article-I.D.: umd5.776
Posted: Tue Nov  5 02:08:52 1985
Date-Received: Fri, 8-Nov-85 05:52:40 EST
References: <130@intelca.UUCP> <181@opus.UUCP>
Reply-To: zben@umd5.UUCP (Ben Cranston)
Distribution: net
Organization: U of Md, CSC, College Park, Md
Lines: 54
Summary: Sometimes compilers can ignore complexity...

In article <181@opus.UUCP> rcd@opus.UUCP (Dick Dunn) writes:
>> (marks quotes from the original article -CBC)

>> 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.   

>                  ...  (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.)  ...

>> 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.

I think this only applies when horrid things are done to the basic machine
in order to support the fancy faz-baz features.  Anybody who has ever seen
the Huffman-coded opcode fields for the Intel 3000 should grok this...

But, the machine I mainly use has 128 registers (sort of, you can't use them
all for everything) which respond to low-core addresses too.  The toy
(subset-of-Algol) compiler I wrote taking classes used exactly two registers.
One was used for all arithmetic, the other for array subscripting.

So, like, put a zero in register R0 and pretend there is a no-index mode.
Write the compiler to use only simple register-to-memory operations and do
its subscript calculations with ADD and MUL like G*d meant them to be, and
ignore that POLY instruction...

Another way of looking at it is that the basic machine will probably have
been slowed down a bit to accomodate all that faz-baz, and that this is 
the ultimate cost.  Looking at it this way just drags us back to the old 
"to-RISC-or-not-to-RISC" dead horse.  I would be willing to bet that the
complaintant here is a closet "RISC" person...  :-)
-- 
Ben Cranston  ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben  zben@umd2.ARPA