Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!ames!ucsd!nosc!crash!pnet01!pro-sol.cts.com!edwatkeys
From: edwatkeys@pro-sol.cts.com (Ed Watkeys)
Newsgroups: comp.sys.apple2
Subject: Re: RISC systems
Message-ID: <1991May30.051608.22524@crash.cts.com>
Date: 30 May 91 05:16:08 GMT
Sender: root@crash.cts.com
Organization: Crash TimeSharing, El Cajon, CA
Lines: 26

In-Reply-To: message from ericmcg@pnet91.cts.com

I would say you're right about RISC aembly being "faster" than CISC, but on
RISC machines, we must remember what gets us that speed: expanded code
size.  This requires larger caches, more main memory and more disk space
because of the nature of the code.  By virtue of it's simplicity, RISC code
also tends to make programming a chore.  On a 6502, for instance, which I
would consider a halfbreed, writing assembly code is not fun compared to C
(not that there are any decent C compilers out there for the II...).

I don't want to start the assembly vs. high level language thing again, but
to put it bluntly, writing in assembly these days is plain stupid if you
ever plan to keep the product alive for any length of time, and as you
stated before, CISC compilers are an even match for RISC compilers in most
cases, which takes away any non-assembly advantage that RISCs had going for
them.

What this all means, in my opinion, is that RISCs and CISCs aren't a
religious decision; they are simply design decisions.  Let me qualify that:
CISC vs. RISC should be no more religious than Motorolla vs. Intel.

Ed Watkeys III

Internet: edwatkeys@pro-sol.cts.com  ProLine:  edwatkeys@pro-sol
UUCP:     crash!pro-sol!edwatkeys    ARPA:     crash!pro-sol!edwatkeys@nosc.mil
BitNET:   edwatkeys%pro-sol.cts.com@nosc.mil