Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!linus!philabs!cmcl2!seismo!rochester!ritcv!ccice5!ccivax!rb
From: rb@ccivax.UUCP (rex ballard)
Newsgroups: net.arch
Subject: Re: RISC question
Message-ID: <449@ccivax.UUCP>
Date: Wed, 5-Mar-86 22:39:49 EST
Article-I.D.: ccivax.449
Posted: Wed Mar  5 22:39:49 1986
Date-Received: Sat, 8-Mar-86 22:03:39 EST
References: <1181@ecsvax.UUCP> <411@ccivax.UUCP> <375@ektools.UUCP> <738@ihwpt.UUCP>
Reply-To: rb@ccivax.UUCP (What's in a name ?)
Distribution: net
Organization: CCI Telephony Systems Group,  Rochester NY
Lines: 20

In article <738@ihwpt.UUCP> knudsen@ihwpt.UUCP (mike knudsen) writes:
>> In article <411@ccivax.UUCP> rb@ccivax.UUCP (What's in a name ?) writes:
>> >A RISC chip also makes
>> >bus sharing ... more practical as well.
>>  the RISC
>> processor will eat up MORE bus cycles, leaving fewer for displays, DMA
>> , and co-processors.
>RISC machines essentially run "nano code" out of YOUR main
>RAM over YOUR bus.  So yes, you seem right to me.
>	mike k
>Or are we both missing something?

Yup!  If you ran ALL instructions directly from main memory, this would
be correct, but RISC chips usually have either internal or tightly
coupled CACHE which reduces the number of fetches from main RAM.  In
fact, some RISC machines have several LAYERS of CACHE, such as 2K
internal, 2 meg external, then the bus, and even a cache to the disk.
The CACHE can be updated via fifo, burst, or interleaved DMA.  The
result, given any demand "paging" at all, in a "Threaded Interpreter",
the RISC becomes a SELF OPTIMISING CISC machine to the outer buss!! Cute eh?