Path: utzoo!attcan!uunet!snorkelwacker!mintaka!dcw
From: dcw@lcs.mit.edu (David C. Whitney)
Newsgroups: comp.sys.apple2
Subject: Re: RISC Machines
Message-ID: <1990Oct2.155706.16241@mintaka.lcs.mit.edu>
Date: 2 Oct 90 15:57:06 GMT
References: <0093D934263990A0.00000110@dcs.simpact.com>
Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius)
Organization: MIT Spoken Language Systems Group
Lines: 90

In article <0093D934263990A0.00000110@dcs.simpact.com> scottg@gnh-starport.cts.com (Scott Gentry) writes:
>The 65x series is not RISC by long shot. By definition, RISC computers, apart
>from having a load/store architecture, execute most if not all instructions in
>one machine cycle.  

That's not really true. The throughput is roughly 1 instruction/cycle,
but the latency is still 5-6 cycles/instruction. It's called
pipelining, and the processor can be working on 5-6 instructions at
the same time. While it's fetching the instruction of number 6, it's
decoding number 5, fetching data on #4, executing #3, storing the
result of #2, and incrementing the PC. This gets to be awfully hairy
in jumping/branching, as the instruction queue has to be flushed.
Also, compares have to be done before it seems logically correct to do
them.

For those who said RISC are designed for compilers and CISC are not,
you've got it wrong. CISC are great for assembly level programming and
for compilers, as they have neat instructions like MULT and ARRAYREF
and crud. RISC processors do not, and because of the pipelining issue,
one could go insane trying to write assembly-level code for it.
Compilers MUST be written for RISC machines, and they're HARD to
write. Once written correctly, though, the thing is mighty efficient,
and the code runs super-duper.

So, in one sense, the 6502 is RISC because its instruction set is so
simple. On the other hand, it is CISC, as it is not pipelined to the
extent that it's impossible to program at the assembly level.

Here's an Example!! This code is the C compiler output on a Sun SPARC.
A SPARC is a RISC processor. Here's the C code:

main()
{
  int i;
  
  for (i=0;i<100;i++);
}

Here's the SPARC code:

LL0:
	.seg	"data"
	.seg	"text"
	.proc 04
	.global	_main
_main:
	!#PROLOGUE# 0                ; this is all C procedure stack management
	sethi	%hi(LF12),%g1
	add	%g1,%lo(LF12),%g1
	save	%sp,%g1,%sp
	!#PROLOGUE# 1
	st	%g0,[%fp+-0x4]       ; store 0 in i
L16:
	ld	[%fp+-0x4],%o0       ; load i into a reg
	cmp	%o0,0x64             ; compare to 0
	bge	L15                  ; if >=, goto L15
	nop                          ; wait
L14:
	ld	[%fp+-0x4],%o1       ; load i into another reg
	add	%o1,0x1,%o1          ; add 1 to the reg
	st	%o1,[%fp+-0x4]       ; store the reg back in i
	b	L16                  ; goto L16
	nop                          ; wait (this is here so it doesn't
L15:                                 ; grab the next instruction)
LE12:
	ret                          ; return
	restore
       LF12 = -72
	LP12 = 64
	LST12 = 64
	LT12 = 64
	.seg	"data"

on the 6502, it would be:

	ldx #$00
loop	inx
	cpx #$64
	blt loop
	rts

Much easier to read and to program because the pipeline isn't an issue.

Now, back to your regularly scheduled Apple //-talking...

--
Dave Whitney			| I wrote Z-Link and BinSCII. Send me bug
Computer Science MIT 1990	| reports. I need a job. Send me an offer.
dcw@goldilocks.lcs.mit.edu	| My opinions, you hear? MINE!
dcw@athena.mit.edu		| "...we came in?"