NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/sys/ibm/pc/hardware/32984

Internet Message Format | 1992-12-13 | 5.2 KB

Xref: sparky comp.sys.ibm.pc.hardware:32984 comp.sys.intel:2673 comp.sys.mac.hardware:23950
Newsgroups: comp.sys.ibm.pc.hardware,comp.sys.intel,comp.sys.mac.hardware
Path: sparky!uunet!usc!cs.utexas.edu!asuvax!chnews!hfglobe!ptd!greason
From: [e-mail] (Jeff Greason ~)
Subject: RISC defined! Was Re: 486SLC chip.... what is it?
Message-ID: <[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Intel Corporation -- Aloha, Oregon
References: <[e-mail]> <[e-mail]>
Date: Fri, 11 Dec 1992 15:56:53 GMT
Lines: 83

In article <[e-mail]> [e-mail] (fred j mccall 575-3539) writes:
>>They're RISC 386's with a math co. and a cache.
>
>Huh?  Nonsensical statement, oh guru.  The phrase 'RISC 386' is a
>contradiction in terms.  If the chip accepts the 386 instruction set
>(and it does) it is BY DEFINITION not RISC.

I realize this was not your point, but...

Aha!  Somebody finally admitted it.  I've long suspected that the RISC advocate
definition of RISC is primarily negative.  Originally, RISC chips had simple
instruction sets, where "simple" was supposed to make it possible to use
advanced implementation techniques such as pipelining and caching because
of the reduced transistor budget.  When CISC chips used these, they claimed
that reduced implementation time was the advantage.  Now, it comes down to
just what you stated:
  "RISC (adj.): 1) A chip which does not accept the X86 instruction set.
   2) A chip which is not manufactured by Intel."

The first definition used most broadly -- the second definition invoked (if
not explicitly) whenever somebody brings up the i860 or i960 architectures.

It is my belief that the real issue isn't RISC v. CISC (by the definition of
your choice) -- the real issue is support of older CODE on new
IMPLEMENTATIONS.

When RISC started, this was their spirit -- throw out all the old code, and
start from a clean sheet of paper.  This allowed them to try certain new
implementation techniques.  However, at the rate of evolution today, most
of these techniques are running out of steam, and being implemented on
microprocessors compatible with old code.  Some new ideas had better come
out soon.  When they do, it is my guess that SPARC, MIPS, and various MORP's
(My Own Risc Processor), will face the same problem the X86 and 608X0 lines
do now.

When you try to implement a new processor compatible with old code, you face
a problem -- USENET notwithstanding, your objective is to MAKE MONEY!  This
is, after all, how your salary gets paid -- forget this too often and the
market will remind you by ceasing to pay your salary!

This means that no matter what new tricks you'd like to try, RULE 1 has got
to be at least a modest improvement in the execution speed of a significant
fraction of existing code!  You can speed up new code all you want -- unless
you gain an incredible amount (and the market has shown that 1.5X the speed
is not "significant" here), the guy who DOES speed up existing code will
clean your clock for you.

Imagine this scenario: Intel does what all the RISC advocates want -- it
throws X86 compatibility to the wind, and goes for the most advanced
processor it can dream up without any constraints.  To listen to this net,
you'd think everyone would beat a path to their door, right?  WRONG -- not
only does the history of the i860 tend to suggest otherwise, taking a look at
the sales volumes of RS/6000, SPARC, MIPS, 88K, ALPHA, PRECISION, etc.
COMBINED, vs. X86 compatible processors, should disabuse you of this notion.

So, new microprocessors can implement all the new features they want, but
if they don't achieve at least modest performance gains on existing code,
their chances for market sucess are dismal.  So far, the advantages to be
gained by ignoring backwards compatibility are also relatively modest.  The
penalties for trying to EMULATE X86 compatibility in software (which would
allow you to have a clean sheet of paper design and still be backwards
compatible) are quite severe, so that SUPER-RISC + EMULATOR is still a lot
slower than an agressive "CISC" design.

That's the bottom line -- how fast you execute the code the customers want
to run.  If advanced implementation techniques, pioneered by RISC designs,
do that -- you use them.  If, even when you use them, you're not RISC, then
it suggests NO backwards compatible part is RISC in spirit -- neither will
SPARC and MIPS chips be after a few more revs.  If being RISC means always
throwing away any concern for the execution speed of most of the existing
code base, then I suggest a third definition:
   "3) A chip which, by ignoring market reality, is doomed to very small
       volumes and consequent low profits"

Disclaimer:  All opinions expressed are my own, and do not reflect the
     position of Intel, Portland State University, or Zippy the Pinhead.
============================================================================
Jeff Greason                  "You lock the door ... And throw away the key.
  <[e-mail]>   There's someone in my head, but it's not me."
                                         -- Pink Floyd