Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucsfcca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!ucsfcgl!ucsfcca!dick
From: dick@ucsfcca.UUCP (Dick Karpinski)
Newsgroups: net.arch
Subject: Re: RISC question
Message-ID: <450@ucsfcca.UUCP>
Date: Tue, 11-Mar-86 20:25:25 EST
Article-I.D.: ucsfcca.450
Posted: Tue Mar 11 20:25:25 1986
Date-Received: Fri, 14-Mar-86 05:37:08 EST
References: <1181@ecsvax.UUCP> <411@ccivax.UUCP> <375@ektools.UUCP> <738@ihwpt.UUCP> <449@ccivax.UUCP>
Reply-To: dick@ucsfcca.UUCP (Dick Karpinski)
Distribution: net
Organization: UCSF Computer Center
Lines: 61
Summary: Putative insights into RISC vs CISC

In article <449@ccivax.UUCP> rb@ccivax.UUCP (What's in a name ?) writes:
>fact, some RISC machines have several LAYERS of CACHE, such as 2K
>internal, 2 meg external, then the bus, and even a cache to the disk.
>...
>the RISC becomes a SELF OPTIMISING CISC machine to the outer buss!! Cute eh?

RISC vs CISC -- where does it lead?

Premises: What I have learned, often contradictory.
  - CISC machines can be effective.
  - RISC machines make sense, should get to be faster.
  - Both camps are right...and both are wrong.
  - They cannot agree because they aren't arguing about 
    the right issues.
  - Sometimes we can resolve confusing issues by 
    increasing the resolution of our examination to see 
    finer detail.  But also, the real answer often 
    seems to pop out sideways, with a new conception 
    of what the proper issue is.
  - Late binding is expensive and effective, the issue
    is what to leave open to bind at run time.  The
    answer is more and more, but not that (yet).  Each
    argument against a feature merely values it lower
    than a competing feature.  If it gets cheaper in a
    later version of the base design, it may become a
    favored feature; they keep putting more on one chip.

Where I get to.
  - Chip layout strategy will resemble a go game rather
    than a chess game; this is effective in situations
    where the area is relevant, not any special feature.
  - The major blocks of current uPs will become the small
    features of future chips.  Whether you call them 
    register files or data caches or stacks, some one or
    more forms of fast word memory will be available to
    compilers and programmers.  And ALUs and Barrel 
    Shifters and FPUs and MMUs etc.
  - Active revisable wiring, ie switching circuits, will
    permit reconfiguration on sub-millisecond cycles to
    optimize operation of virtual larger components in
    compile/assemble phases and even at run time.  
  - Active optimizing algorithms (like caches and buffers
    and on-the-fly garbage collection) will be extended
    to choosing between multiple code generations for a
    given piece of source code and adjusting the I/O
    bandwidth vs processing power of the machine.
  - Multiple processors and awesome amounts of memory
    will be available in the single-user workstation.
  - Multiple strategies will be employed in every camp;
    we will look back on these days as the simplistic
    past.  Complexity will take on whole new meanings.

Perhaps I am just talking through my hat.

Dick
-- 

Dick Karpinski    Manager of Unix Services, UCSF Computer Center
UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick   (415) 476-4529 (12-7)
BITNET: dick@ucsfcca   Compuserve: 70215,1277  Telemail: RKarpinski
USPS: U-76 UCSF, San Francisco, CA 94143