Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!ima!cfisun!stardent!wright
From: wright@stardent.Stardent.COM (David Wright @stardent)
Newsgroups: comp.arch
Subject: Re: Opcode assignment for RISC processors
Message-ID: <1990Oct13.225140.4269@Stardent.COM>
Date: 13 Oct 90 22:51:40 GMT
Organization: Stardent Computer, Newton MA
Lines: 30

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