Path: utzoo!utdoe!generic!pnet91!ericmcg
From: ericmcg@pnet91.cts.com (Eric Mcgillicuddy)
Newsgroups: comp.sys.apple2
Subject: Re: RISC systems
Message-ID: <801@generic.UUCP>
Date: 1 Jun 91 15:30:03 GMT
Sender: root@generic.UUCP
Organization: People-Net [pnet91], Etobicoke, ON
Lines: 27

>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
>
>Ed Watkeys III
>
>Internet: edwatkeys@pro-sol.cts.com  ProLine:  edwatkeys@pro-sol

The latest CISC machines are really RISC machines with certain subroutines
included on chip (the microcode and nanocode (in the 680x0)). There is no
fundamental difference between this and a library function doing the same
thing, except possibly where one gets the parameters. Instructions tend to
have parameters follow the instruction, subroutines tend to have them on the
stack, of course register passing is also used for both (MVP instruction
discussed earlier). And the Prodos MLI of course has parameters following the
call. SO ther is really not much difference between a RISC architecture and a
CISC these days, just a matter of what libraries the manufacturer has decided
to include and where. Really depends on what you need, I am willing to spend
the extra 20% in code size for the flexibility of tuning the libraries to a
specific task, but not if I were designing an embedded controller where memory
is the main constraint. 

Fit the components to the system, this is the only rational design criteria.

UUCP: bkj386!pnet91!ericmcg
INET: ericmcg@pnet91.cts.com