Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/13/84; site intelca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!pesnta!amd!intelca!kds
From: kds@intelca.UUCP (Ken Shoemaker)
Newsgroups: net.micro.68k,net.arch
Subject: Re: Re: Re: RISC
Message-ID: <12@intelca.UUCP>
Date: Mon, 1-Jul-85 18:59:27 EDT
Article-I.D.: intelca.12
Posted: Mon Jul  1 18:59:27 1985
Date-Received: Thu, 4-Jul-85 00:28:50 EDT
References: <639@vax2.fluke.UUCP> <2743@nsc.UUCP> <576@terak.UUCP> <5691@utzoo.UUCP>, <4@intelca.UUCP> <5722@utzoo.UUCP>
Organization: Intel, Santa Clara, Ca.
Lines: 21
Xref: watmath net.micro.68k:985 net.arch:1523

> Remember that the RISC is necessarily decoding its opcodes; not even on
> a machine that simple is a numeric opcode a direct encoding of the internal
> control signals.  The point is that the current instruction encoding was
> chosen for simplicity, not compactness, and one can do better *without*
> compromising the principles of the machine.

I didn't say that it didn't decode them...My understanding is that the
various bits of the instructions always come into the processor on the
same set of data lines, which eliminates the need for some other unit
out there to steer the bits from the appropriate data lines to the
correct decoding unit.
-- 
...and I'm sure it wouldn't interest anybody outside of a small circle
of friends...

Ken Shoemaker, Microprocessor Design for a large, Silicon Valley firm

{pur-ee,hplabs,amd,scgvaxd,dual,qantel}!intelca!kds
	
---the above views are personal.  They may not represent those of the
	employer of its submitter.