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.