Xref: utzoo comp.arch:18440 comp.lsi.cad:670 Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch,comp.lsi.cad Subject: Re: Opcode assignment for RISC processors Message-ID: <41963@mips.mips.COM> Date: 6 Oct 90 19:31:10 GMT References: <39029@ucbvax.BERKELEY.EDU> <4153@bingvaxu.cc.binghamton.edu> Sender: news@mips.COM Reply-To: mash@mips.com (John Mashey) Followup-To: comp.arch Organization: MIPS Computer Systems, Inc. Lines: 50 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: 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