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 94086peter@ficc.ferranti.com (Peter da Silva) (10/07/90)
In article <41963@mips.mips.COM> mash@mips.com (John Mashey) writes: > 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. As a long-time embedded systems hacker, I'd recommend that on any machine 00000000 and FFFFFFFF both be illegal instructions, or otherwise cause a trap. This makes software crash quickly instead of slowly when it goes out in the weeds. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
mash@mips.COM (John Mashey) (10/08/90)
In article <-S86F-8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <41963@mips.mips.COM> mash@mips.com (John Mashey) writes: >> 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. > >As a long-time embedded systems hacker, I'd recommend that on any >machine 00000000 and FFFFFFFF both be illegal instructions, or >otherwise cause a trap. This makes software crash quickly instead >of slowly when it goes out in the weeds. Yes, a number of folks have felt this way. At least zero is not actively harmful as a nop, even if it does nothing to help you find bugs. I recall the opposite on an old 7090, where at least one very common constant turned out to be an instruction that jumped somewhere while modifying an index register, so that branching caused chaos, having trashed lots of things, leaving no clue as to how you got where you were going. -- -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
meissner@osf.org (Michael Meissner) (10/08/90)
In article <-S86F-8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: | In article <41963@mips.mips.COM> mash@mips.com (John Mashey) writes: | > 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. | | As a long-time embedded systems hacker, I'd recommend that on any | machine 00000000 and FFFFFFFF both be illegal instructions, or | otherwise cause a trap. This makes software crash quickly instead | of slowly when it goes out in the weeds. Data General Nova's, Eclipse's, and MV/Eclipse's were particularly bad in this respect. A full 16-bit 0 was a jump to location 0 (in the current ring/segment on MV/Eclipse). In user code, location 0 usually contained 0, which of course did a tight loop. In the original Nova, location 0 contained the address to jump to after processing the current interrupt, so jump 0 was actually a meaningful operation. I finally put a kernel instruction (PATU) at location 0 to trap this type of code in the C initializer. Then came somebody that took a stripped down library and ran it standalone, in which case it was a normal instruction.... You sometimes can't win. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
sb380@cs.city.ac.uk (Andy Holt) (10/08/90)
In article <41963@mips.mips.COM> Craig Hansen passes along the following: > .... >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. > > .... There seem to be two popular choices for the effect of an all-zero opcode. Craig's choice of NOP has aesthetic appeal, and has been used by many systems. But IMO a much better choice is to make it some form of trap or illegal opcode (cf HLT on PDP11) thus improving considerably on the chances of catching overwriting problems. (OK, OK, modern systems normally have write protected code segments, but ...) Andy
peter@ficc.ferranti.com (Peter da Silva) (10/08/90)
In article <MEISSNER.90Oct7224150@osf.osf.org> meissner@osf.org (Michael Meissner) writes: > Data General Nova's, Eclipse's, and MV/Eclipse's were particularly bad > in this respect. A full 16-bit 0 was a jump to location 0 (in the > current ring/segment on MV/Eclipse). ... #define URBAN_LEGEND maybe: In one of the TI minis, 0 tuned out to be "store immediate 0". Executing 0 would fill memory with 0 as fast as the PC could increment. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
ted@nmsu.edu (Ted Dunning) (10/09/90)
In article <41964@mips.mips.COM> mash@mips.COM (John Mashey) writes: In article <-S86F-8@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >As a long-time embedded systems hacker, I'd recommend that on any >machine 00000000 and FFFFFFFF both be illegal instructions, or ... I recall the opposite on an old 7090, the worst i have seen was on an old IMSAI-8080 where FF was the trap 7 instruction, and was also what unused memory locations effectively contained. the service routine for this instruction was hardwired into the non-existent high end of memory. the result was that trap 7 pushed a return address, and jumped to a service routine where it found another trap 7 instruction, pushed another return address (which happened to consist of two trap 7 instructions), and did the operation again. if a program hit one of these instructions, the first indication of trouble was the high order address bit blinking about once a second as the system filled all of memory with ones over and over again. if i had to work on that machine again, i would build a special one word read only memory containing a halt instruction to avoid exactly that problem. -- ted@nmsu.edu +---------+ | In this | | style | |__10/6___|
shankar@hpclscu.HP.COM (Shankar Unni) (10/10/90)
> / hpclscu:comp.arch / peter@ficc.ferranti.com (Peter da Silva) / 6:46 pm Oct 6, 1990 / > In article <41963@mips.mips.COM> mash@mips.com (John Mashey) writes: > > 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. > > As a long-time embedded systems hacker, I'd recommend that on any > machine 00000000 and FFFFFFFF both be illegal instructions, or > otherwise cause a trap. This makes software crash quickly instead > of slowly when it goes out in the weeds. Absolutely. In HP's Precision Architecture (sorry, PA-RISC ..), 0 decodes to "BREAK 0,0", which raises a break trap. --- Shankar Unni.
prs@io.UUCP (Paul Schmidt) (10/10/90)
In article <TED.90Oct8171904@kythera.nmsu.edu> ted@nmsu.edu (Ted Dunning) writes: > ... >the worst i have seen was on an old IMSAI-8080 where FF was the trap 7 >instruction, and was also what unused memory locations effectively >contained. the service routine for this instruction was hardwired >into the non-existent high end of memory. > ... All of the trap (Int?) instructions called an address at (trap*4) - Trap 0 called location 0, and the trap 7 instruction on the 8080 called location 28 decimal. Since most systems had memory there, it was easy enough to put some sort of appropriate OS handler at location 28, effectively trapping execution of non-existent programs. In your system, I suspect that the instructions located at 28 decimal were effectively garbage.
colwell@omews35.intel.com (Robert Colwell) (10/10/90)
In article <TED.90Oct8171904@kythera.nmsu.edu> ted@nmsu.edu (Ted Dunning) writes: >the worst i have seen was on an old IMSAI-8080 where FF was the trap 7 >instruction, and was also what unused memory locations effectively >contained. the service routine for this instruction was hardwired >into the non-existent high end of memory. the result was that trap 7 >pushed a return address, and jumped to a service routine where it >found another trap 7 instruction, pushed another return address (which >happened to consist of two trap 7 instructions... This reminds me of two memorable hacks that Paul Rodman and I did while finishing a Master's project at CMU back in 1978. We were using a PDP-11/45 as a host for a digital music synthesizer of our own design, and the PDP-11 was getting a tad flaky for want of decent maintenance. One manifestation of this latent senility was that it would occasionally fail its boot diagnostics for memory, putting the failing address up on the front panel lights, and taking a trap to a non-existent trap handler, at which point it would hang. Were one to toggle data into the supposedly bad memory location, it would be remembered just fine. So we began to routinely toggle in a "return-from-interrupt" at the "trap-handler" location just after powering up and before trying to boot, and the machine would boot just fine. (No one else figured out how to do this, so the PDP-11 became our machine after this.) The other hack had to do with the DEC removable disk drives. There are batteries in those things, presumably to provide the wherewithal to retract the head from the disk in the event of a power fail. But we discovered that if those batteries were to fail, one couldn't use the drive at all. So we taped some flashlight batteries together with electrical tape, wired that in place of the internal batteries, and hung the whole thing out of the drive chassis. It looked pretty weird. Almost as bad as the time we had to take a Radio Shack 12.6V transformer and remove some secondary windings because the nominal output was a bit too high for our three-terminal regulator, causing it to shut down completely. But that's another story. Bob Colwell mipon2!colwell@intel.com 503-696-4550 Intel Corp. JF1-19 5200 NE Elam Young Parkway Hillsboro, Oregon 97124
wright@stardent.Stardent.COM (David Wright @stardent) (10/14/90)
In article <41964@mips.mips.COM>, mash@mips.COM (John Mashey) writes: >In article <-S86F-8@xds13.ferranti.com> peter@ficc.ferranti.com >(Peter da Silva) writes: >>In article <41963@mips.mips.COM> mash@mips.com (John Mashey) writes: >>> 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. > >>As a long-time embedded systems hacker, I'd recommend that on any >>machine 00000000 and FFFFFFFF both be illegal instructions, or >>otherwise cause a trap. This makes software crash quickly instead >>of slowly when it goes out in the weeds. >Yes, a number of folks have felt this way. At least zero is not actively >harmful as a nop, even if it does nothing to help you find bugs. But it isn't very useful, either. One thing I liked about the old GE/Honeywell 600/6000/DPS systems was that in addition to zero being an illegal opcode, an ASCII space in the "address tag" field would cause a "fault tag fault", so jumping into ASCII text would usually bomb out very quickly. (Remember, this was a base/bounds addressing machine, so paging arguments do not apply.) Trapping out attempts to execute data is a very worthwhile effort. -- David Wright, not officially representing Stardent Computer Inc wright@stardent.com or uunet!stardent!wright I'd explain it to you, but your head would explode. -- Steven Wright