Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!winchester!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: Opcode assignment for RISC processors
Message-ID: <41964@mips.mips.COM>
Date: 8 Oct 90 00:35:03 GMT
References: <39029@ucbvax.BERKELEY.EDU> <4153@bingvaxu.cc.binghamton.edu> <41963@mips.mips.COM> <-S86F-8@xds13.ferranti.com>
Sender: news@mips.COM
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 24

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