Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!ariel.unm.edu!nmsu!opus!ted
From: ted@nmsu.edu (Ted Dunning)
Newsgroups: comp.arch
Subject: Re: Opcode assignment for RISC processors
Message-ID: <TED.90Oct8171904@kythera.nmsu.edu>
Date: 8 Oct 90 23:19:04 GMT
References: <39029@ucbvax.BERKELEY.EDU> <4153@bingvaxu.cc.binghamton.edu> <41963@mips.mips.COM> <-S86F-8@xds13.ferranti.com> <41964@mips.mips.COM>
Sender: news@NMSU.Edu
Organization: NMSU Computer Science
Lines: 33
In-reply-to: mash@mips.COM's message of 8 Oct 90 00:35:03 GMT


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___|