Xref: utzoo comp.arch:18428 comp.lsi.cad:668
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!rpi!leah!bingvaxu!kym
From: kym@bingvaxu.cc.binghamton.edu (R. Kym Horsell)
Newsgroups: comp.arch,comp.lsi.cad
Subject: Re: Opcode assignment for RISC processors
Message-ID: <4153@bingvaxu.cc.binghamton.edu>
Date: 5 Oct 90 23:16:32 GMT
References: <39029@ucbvax.BERKELEY.EDU>
Reply-To: kym@bingvaxu.cc.binghamton.edu.cc.binghamton.edu (R. Kym Horsell)
Organization: SUNY Binghamton, NY
Lines: 23

In article <39029@ucbvax.BERKELEY.EDU> holmer@ernie.Berkeley.EDU (Bruce K. Holmer) writes:
>I'm curious how the architects for new RISC processors come up with
>the opcode assignments (i.e. which bit pattern goes with which
>instruction).
[mentions PLA optimizing algorithm]

Well I sure don't have experience with designing _commercial_ RISCs,
but I have been involved with a RISC project here at SUNY-B which
uses something far simpler (and faster) than a PLA. Since RISC
instruction sets are pretty small, even considering address mode
(if supported) decoding, and an "opcode" field of 8 bits can
be spared, we assigned pairs of bit positions to signify each
"opcode" (e.g. mux control, etc.) -- a handful of gates is all that's 
required to decode operations in each pipe stage.

Apropos of RISCs (maybe) falling over when given random data as
instructions one other consideration is handling opcode fields where
more than 2 bits are set (i.e. invalid opcodes)-- this is also pretty cheaply 
done. Situations that have fewer than 2 bits set will decode as NOPs. 

A waste of resources? Maybe, but it's cheap.

-Kym Horsell