Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site uicsl
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!houxm!ihnp4!inuxc!pur-ee!uiucdcs!uicsl!cheong
From: cheong@uicsl.UUCP
Newsgroups: net.arch
Subject: Re: RISC and MIPS
Message-ID: <2300001@uicsl>
Date: Thu, 15-Aug-85 16:25:00 EDT
Article-I.D.: uicsl.2300001
Posted: Thu Aug 15 16:25:00 1985
Date-Received: Sun, 18-Aug-85 04:15:27 EDT
References: <419@kontron.UUCP>
Lines: 42
Nf-ID: #R:kontron.UUCP:-41900:uicsl:2300001:000:2057
Nf-From: uicsl.UUCP!cheong    Aug 15 15:25:00 1985


/* Written  6:33 am  Aug  2, 1985 by hammond@petrus.UUCP in uicsl:net.arch */
> In article <419@kontron.UUCP>, steve@kontron.UUCP (Steve McIntosh) writes:
> > Take, for example, the following 68000 instruction:
> > 
> > 	MOVE.W D7,(A3)+
> >
This takes 2 16 bit memory cycles (instruction fetch, operand store)
> > 
> 	On the Berkeley RISC, the equivalent istruction sequence is:
> 
> 	MOVE R7,(R4)
> 	ADD #2,R4,R4
>
This takes 3  32 bit memory cycles: (i.e. 3 instruction cycles)
(instruction fetch, operand store, instruction fetch)

The RISC I takes 3 clock cycles per instruction cycle.(See Computer Spet. 82)
The Berkeley RISC takes 2 instruction cycles per load/store (see CACM Jan '85).

The point was that for the above operation, the more compact encoding of
the 68000 requires less memory cycles and hence is faster.  The number of
clock cycles per memory cycle, assuming a reasonable architecture, is
irrelevant, since the RISC can do at most 1 instruction/memory cycle
since it has to fetch an instruction.  Note that the 68020 in fact
uses only 3 clock cycles per memory cycle (like the RISC I).

What does all this have to do with RISC vs CISC.  Is the auto-increment mode
common in compiler generated code?  How about other operations?  In other
words, I can accept that certain operations will be slower if the overall
performance improves, so picking on an individual sequence only helps if
we know its relative frequency in real code.

A side note:  The Berkeley RISC's have no absolute addressing mode, they
fake it by using R0 (always 0) plus an offset.  BUT, the offset can only
be 13 bits, hence they can only absolutely address the first 2**13 locations
in memory.  Large programs, eg the UNIX kernel (particularly from Berkeley)
use much more than 2**13 (like 2**19) for instructions, hence the problem
is how well would a RISC do when it takes 2 instructions to form an
absolute address and probably requires a register?  I'll accept RISCs when
I see one runnning 4.3 BSD faster than an 11/780.
/* End of text from uicsl:net.arch */