Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: RISC Machines
Message-ID: <14007@smoke.BRL.MIL>
Date: 3 Oct 90 21:50:42 GMT
References: <0093D934263990A0.00000110@dcs.simpact.com> <1990Oct2.155706.16241@mintaka.lcs.mit.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 58

In article <1990Oct2.155706.16241@mintaka.lcs.mit.edu> dcw@lcs.mit.edu (David C. Whitney) writes:
>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.

For code generation, availability of fancy instructions is not nearly as
important as regularity of the instruction set architecture.  It is quite
difficult to cope with addressing modes that can be used with only a
subset of the general data-manipulation operations, for example.  This is
the worst aspect of the 6502's compact opcode design, from the point of
view of a compiler writer.

>Here's an Example!! This code is the C compiler output on a Sun SPARC.
>	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

>on the 6502, it would be:
>	ldx #$00
>loop	inx
>	cpx #$64
>	blt loop
>	rts

And on a MIPS it's:
 #   5	  for (i=0;i<100;i++);
	sw	$0, 4($sp)
$32:
	lw	$14, 4($sp)
	addu	$15, $14, 1
	sw	$15, 4($sp)
	blt	$15, 100, $32

However, you are "comparing apples and oranges".  In fact, C compilers
for the 6502 are not going to generate the sequence that you exhibit.
Your 6502 code is not functionally equivalent to the others, because it
does not maintain the value of a memory-based variable `i' like the
others.  Having recently disassembled a fair amount of 6502 code output
by ORCA/C, I can attest the the rather horrible convolutions that were
found to be generally necessary to correctly implement the full C
semantics.  The RISC version is much simpler.  Note that (for MIPS at
least), every elementary instruction implements directly a necessary
step in the logical decomposition of the C source code semantics.  This
is a highly desirable property when you're designing a code generator.