holmer@ernie.Berkeley.EDU (Bruce K. Holmer) (10/06/90)
* 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). I know about the tools for state assignment of finite state machines, but opcode assignment is a slightly different problem. The need to come up with an opcode assignment is a relatively rare occurrence (since it is done only once for each processor family), so I wouldn't think people would invest much time in writing a fancy tool for it. Our research group has designed a 32-bit RISC and I'm in the process of writing up a short report on how I did the opcode assignment. We had some unusual constraints on some of the opcodes, which made the problem less than straight forward. I used a simple form of simulated annealing that is very easy to code from scratch (it took two days from the initial idea to the final result--that includes time for writing the code and running it many times). The results were satisfactory--the number of minterms in the decode PLAs reduced on average about 20%. But perhaps the problem is even easier than I think, so I'd be curious what others have done (especial curious about the commercial processors--MIPS, SPARC, 29000, etc.). If you would like a copy of my report, send me email--but it will be a couple of weeks before I have something to mail. Thanks, Bruce Holmer holmer@ernie.berkeley.edu
kym@bingvaxu.cc.binghamton.edu (R. Kym Horsell) (10/06/90)
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
mash@mips.COM (John Mashey) (10/07/90)
Craig Hansen passes along the following:
From: craig@microunity.com (Craig Hansen)
Subject: article posting re: opcode assignment
Status: R
I have a reply to the question about how the R2000
opcodes were assigned, but our current usenet configuration
doesn't provide for posting articles. Could
you do me the favor of posting this to comp.arch?
(mash: yes, and here it is:)
I specified the opcodes for the R2000/R2010 by hand,
and the criteria were a combination of esthestic
and technical ones.
The SPECIAL opcode and SLL sub-opcode were selected
to be zero, so that a 32-bit zero would produce a NOP.
I would consider this to be of esthetic value only.
BLEZ and BGTZ are major op-codes, so that the rt
field could be filled with zero, which is used to
produce a zero at one input of the equality comparator
which is combined with the sign bit of the
rs operand to produce the condition. (This should
answer another question previously posed to comp.arch).
Holes were left in specific locations for future
extensions to the architecture. The decoding of
these reserved instruction holes was certainly
more complex than any of the other decoder terms,
but it was not a critical path.
SLT and SLTU differ in their encoding by only one bit
from SUB and SUBU because the ALU performs the
same function on the operands for the corresponding
instructions. In general, similar operations form
n-cubes to minimize the number of or-terms in the decoders.
There was no particular attempt to minimize the number
of and-terms using the reserved codes as don't cares -
this would have had little effect on the decode time.
Regards,
Craig Hansen
craig@microunity.com
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash
DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086