Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!nbires!hao!hplabs!oliveb!intelca!mipos3!kds
From: kds@mipos3.UUCP
Newsgroups: net.arch
Subject: Re: What RISC is REALLY all about!
Message-ID: <136@mipos3.UUCP>
Date: Thu, 17-Jul-86 20:32:13 EDT
Article-I.D.: mipos3.136
Posted: Thu Jul 17 20:32:13 1986
Date-Received: Fri, 18-Jul-86 23:49:44 EDT
References: <475@elmgate.UUCP> <789@petsd.UUCP> <481@elmgate.UUCP> <193@cci632.UUCP> <43@rb-dc1.UUCP>
Reply-To: kds@mipos3.UUCP (Ken Shoemaker ~)
Organization: Intel, Santa Clara, CA
Lines: 26

Actually, from my perspective, one of the main objectives of a RISC is the
simplification of the hardware so that you can fit more other things on
the chip, i.e., caches or whatever, that could potentially have a greater
impact on the overall system performance than your fancy-dancy instructions.
Certainly, you don't want to do anything that makes it impossible to generate
code, but in terms of what you put in or what you take out, I'd say that
the hardware of the implementation is the highest consideration.  Maybe I'm
very mistaken, but you'd have to work long and hard to convince me that
the removal of inter-pipeline interlocks, the addition of the deferred
jump feature or fixed length instructions simplify code generation or 
assembly language programming.  They are only there because they simplify 
the hardware required to take out jump penalties or they were something
that a compiler could "work around" and therefore wasn't required in
the hardware.

And my last word, my firm belief is that any processor designed without
any (or a very small) consideration to either the software that the
thing is going to run, OR the hardware implementation that is required
to execute the instructions is doomed to failure.  And this includes
processors that are designed by compiler writers living in a vacuum.
-- 
The above views are personal.

I've seen the future, I can't afford it...

Ken Shoemaker, Microprocessor Design, Intel Corp., Santa Clara, California