Path: utzoo!attcan!uunet!portal!cup.portal.com!bcase
From: bcase@cup.portal.com (Brian bcase Case)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC
Message-ID: <10722@cup.portal.com>
Date: 31 Oct 88 21:53:09 GMT
References: <156@gloom.UUCP> <890@cps3xx.UUCP> <10194@cup.portal.com>
Organization: The Portal System (TM)
Lines: 34

I wrote:
>> The almighty Compiler can save us from our sins!

>This view is typical of hardware types.  By all means, lets pass the
>buck to the next guy.

If that makes the system better (cheaper, faster, more reliable), then
we shold pass the buck.

>And miracle of miracles, we learn that over 70% of computing costs
>are software.

The architecture has little if anything to do with this.  The compiler
is a comparatively-meager one-time investment, and getting a good one
is very important.  A good optimizing compiler is probably easier to
write for a simple machine (e.g. RISC) than for a complex machine.

>It seems like hardware types should be designing their end of the
>deal to reduce it at the other end.

This is the kind of thinking that got us machines like the VAX:  "Well,
I just *know* those ol' compiler guys are gonna love me 'cause I'm
giving them these bitchin' addressing modes and memory to memory
operations.  They won't mind that I'm squeezing out registers to save
code size and fit in the microcode.  Sure its hard work, but I don't
mind, besides my boss keeps telling me I'm supposed to be designing my
end of the deal to reduce their work."  Never mind that the hardware guy
is thwarting their efforts to write a good compiler:  the next version
of the machine has instruction timings that completely change the
trade-offs of code generation.  Compiler guy:  "What do you mean
that addressing mode is now twice as slow!?  I spent the better part
of six months making the compiler use it to save code space!  I
think I'm gonna go work on ol' Lazy Larry's machine, at least I know
each instruction's execution time, and he won't change it next year!"