Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3  Pyramid OSx-3.0 85/11/15; site pyramid.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!dan
From: dan@pyramid.UUCP (Danial Carl Sobotta)
Newsgroups: net.arch
Subject: RISC vs INTEL
Message-ID: <117@pyramid.UUCP>
Date: Thu, 27-Feb-86 12:19:08 EST
Article-I.D.: pyramid.117
Posted: Thu Feb 27 12:19:08 1986
Date-Received: Sat, 1-Mar-86 02:40:46 EST
Reply-To: dan@.UUCP (Dan Sobottka)
Distribution: net
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 84

clif@intelca.UUCP (Clif Purkiser) writes:

>The RISC machine I designed for my Computer Architecture course
>(taught by Mr. RISC Dave Patterson ) had 24 instructions and two addressing 
>modes it didn't even have a multiple.  While I was very happy at the time that
>I didn't have to try to right microcode for a lot of complex instructions!
>(The previous class had to implement the Z8000 with TTL SSI and MSI parts)
>My machine  sure took a long time to do useful work.  Needless to say my RISC 
>computer was a toy compared to real RISC machines.

I would be interested to see how much of your performance degradation was
due to *your* implementation as opposed to the nature of RISC in itself.

>J. Giles point is well taken that compiler writers have not yet figured out a way of taking advantage of the numerous addressing modes and 
>instructions offered by CISC machines such as 86, Z8K, 68K or 32K families.
>I would even concede that you can still have a RISC machine that takes more
>than one clock to complete an instruction.  This allows an important
>instruction such as multiple to be included in the instruction set.
                    ^^^^^^^^
Multiple what?? (block move, n-bit decimal add, ...).  Yes, there are
RISC machines that have some multiple cycle instructions.  In my experience,
though, something like a block move can usually be implemented with a loop
(especially using an efficient branch scheme) of simpler instructions with
*no loss of performance*.

>The Ascii Adjust
>instruction are used by COBOL (yes people still use it) compilers and 
>spreadsheet designers because COBOL uses BCD and these instruction speed 
>this process up.  Likewise, XLAT can be used for converting ASCII to EBCDIC
>in 5 clocks.  

It is indeed a shame that people still use COBOL, but nevertheless, most
of the convert type instructions can be done easily (and maybe faster!)
using a RISC architecture.  Converting ASCII to EBCDIC in 5 cycles?? Excuse
me if I'm ignorant, but wouldn't a simple table lookup do?? If this
conversion were somewhat popular, then it's likely that the RISC equivalent
routine AND the lookup-table would be in cache, where this operation could
be done in fewer than 5 cycles!

>One disagreement I have with the RISC proponents is the theory that
>everyone writes in a HLL.  It seems that despite years of trying to force
>everyone to write in HLL languages there will always be a few assembly 
>language programers.  Because no matter how much performance Semicoducter and 
>Computer companies give programmers they always want their programs to run 
>faster.  So these CISC instructions while not useful to compiler writers are 
>useful to assembly language jocks. 

There is such a thing as MACROS which allow assembly-language hacks to define
their OWN CISC 'instructions' (rather than have some arch designer tell them
what they can and can't have).

>This probably compiles into these RISC instructions assuming x, a, and i
>are in register R1,R2, and R3 respectively.
>ShiftL R4, R3, #2
>Add    R4, R4, R2
>Load   R1, [R4]
>This is a single 4 clock instruction on the 80386 vs 3 clocks for the RISC
>chip.  However, the RISC chip has had to fetch 3 instructions vs one for 
>the CISC processor.  So unless the RISC chip has a large on-chip cache it
>will be slower.    

Well, 3 cycles IS faster than 4!  Furthermore, the 3 RISC instructions
will most likely be together in cache, where they can be fetched as fast
as any microword could be.  YES, a RISC chip will have a much larger
cache (all else being equal) than a CISC chip. Plus, there should be
plenty of room left to add some performance features that the 80386
obviously doesn't have.

>I think that the good thing about the RISC philosphy is that it
>will reduce the tendency of designers to add new instructions or addressing
>modes just because they look whizzy or Brand X has them.  If a complex way of
>doing something is slower than a simple way don't put it in.

Hey! I won't argue with THAT.  How do ya think most of CISC got developed
anyway?
	

-- 


  'Out of the inkwell comes Bozo the Clown ...'
 
DISCLAIMER:  These opinions are neither mine nor my C-compiler's
       sun!pyramid!dan