Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!rochester!kodak!ektools!john
From: john@ektools.UUCP
Newsgroups: net.arch
Subject: RISC question
Message-ID: <375@ektools.UUCP>
Date: Wed, 19-Feb-86 08:00:28 EST
Article-I.D.: ektools.375
Posted: Wed Feb 19 08:00:28 1986
Date-Received: Fri, 21-Feb-86 07:26:46 EST
References: <1181@ecsvax.UUCP> <411@ccivax.UUCP>
Reply-To: john@ektools.UUCP (John H. Hall)
Followup-To: net.arch
Distribution: net
Organization: Eastman Kodak, Dept. 47
Lines: 35

In article <411@ccivax.UUCP> rb@ccivax.UUCP (What's in a name ?) writes:
>A RISC chip also makes
>bus sharing with very high resolution displays or very high speed DMA
>peripherals and co-processors more practical as well.

This doesn't seem right.  Does 'practical' in this sentence mean less
bus contention?

Since a RISC machine doesn't have the fancy microcoded instructions of
a CISC machine, it takes more instructions to do the same job.  Even
though a RISC instruction typically requires fewer bits than a CISC
instruction, a program for a RISC machine is generally said to be
larger than the equivalent program for a CISC machine.  With today's
low memory prices, this is not a terrible thing.

I was always taught that 80%-95% of the bus usage of a processor was
for instruction fetches.  Therefore if a RISC machine takes more bytes
of instructions to run a program than a CISC machine would, the RISC
processor will eat up MORE bus cycles, leaving fewer for displays, DMA
, and co-processors.

Now, I'm not a professional computer designer, so there's a good chance
I missed something in the original argument.  Elucidation is welcome.
Flames to /dev/null.

-- 
-------------------------------------------------------------------------
John Hall
Supervisor, Software Tools Laboratory
Product Software Engineering

USPS:   EASTMAN KODAK COMPANY, 901 Elmgrove Rd., Rochester, NY 14650
VOICE:  716 726-9345
UUCP:   {allegra, seismo}!rochester!kodak!ektools!john
ARPA:   kodak!ektools!john@rochester.ARPA