Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site terak.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!hao!noao!terak!doug
From: doug@terak.UUCP (Doug Pardee)
Newsgroups: net.micro.68k,net.arch
Subject: Re: FLAME!!! Re: EA orthogonality
Message-ID: <590@terak.UUCP>
Date: Mon, 3-Jun-85 15:27:53 EDT
Article-I.D.: terak.590
Posted: Mon Jun  3 15:27:53 1985
Date-Received: Thu, 6-Jun-85 02:36:42 EDT
References: <419@oakhill.UUCP> <6415@boring.UUCP> <557@terak.UUCP> <6417@boring.UUCP> <572@terak.UUCP> <135@watmum.UUCP>
Organization: Terak Corporation, Scottsdale, AZ, USA
Lines: 56
Xref: watmath net.micro.68k:861 net.arch:1312

Wait a second!  It looks like I should have used one of my "patented"
200-line postings, because an awful lot of people have misinterpreted
my comments.

The original posting to which I had responded did *not* say that EA
orthogonality would result in better compiled code.  It said that EA
orthogonality would allow that compiler writer to save himself the
trouble of swapping operands on a compare instruction and logically
inverting the branch condition.

This does *NOT* improve the performance of the compiled code.  In fact,
on the NS320xx cpus (the only ones around with 2-address architecture),
a "backwards" compare instruction takes an extra 2 clock cycles of
execution time.

I have no objection to compiler writers who wish to make a case that EA
orthogonality will result in better compiled object code.  But I object
strenuously to the notion that regardless of whether it would benefit
or hurt the users, the cpu architecture should be changed to please lazy
compiler writers.

EA orthogonality should be argued on the basis of the efficiency of the
resulting object code, not on the ease with which the handful of
compiler writers can do their job.

Some of the notes have indicated that these concerns are one and the
same.  Sometimes, but not always.  Here's a choice counter-example:
Some RISC machines have a "branch *after* next instruction" operation.
This allows the pipeline to be used more efficiently.  It results in
more efficient object code than conventional branch instructions, but
it is a booger-bear to write an effective compiler for.

A lot of folks have also suggested that compilers which were easily
written (I call them "hastily knocked out" :-) are more bug-free than
ones that took some time to implement.  I maintain that the quantity of
bugs is related to the quantity and quality of design and debugging.
Now how much design and debugging do you expect to get from a compiler
writer who thinks that putting the operands of a "compare" instruction
in the proper order is "too much work"?

It is also said that good compilers take longer to produce than crummy
ones.  True.  Are we all so impatient that we'd rather have a crummy
compiler now than to wait six months for a good one?

And it has been said that good compilers cost more than crummy ones.
I'm not exactly surprised.  Isn't there an old saw about "only getting
what you pay for"?

I suggest that part of the problem here is that a lot of folks who are
reading this hope to write The Great American Compiler.  They weren't
planning on spending the time and money to write a good compiler.  And
they don't much care for hearing suggestions that users don't want to
buy crummy compilers.  (Have at it, my mailbox is asbestos-lined now).
-- 
Doug Pardee -- Terak Corp. -- !{ihnp4,seismo,decvax}!noao!terak!doug
               ^^^^^--- soon to be CalComp