Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!snorkelwacker!paperboy!meissner From: meissner@osf.org (Michael Meissner) Newsgroups: comp.arch Subject: Re: Opcode assignment for RISC processors Message-ID: Date: 8 Oct 90 02:41:50 GMT References: <39029@ucbvax.BERKELEY.EDU> <4153@bingvaxu.cc.binghamton.edu> <41963@mips.mips.COM> <-S86F-8@xds13.ferranti.com> Sender: news@OSF.ORG Organization: Open Software Foundation Lines: 28 In-reply-to: peter@ficc.ferranti.com's message of 7 Oct 90 01:46:30 GMT 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?