Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: Mainframe Architectures
Message-ID: <32319@apple.Apple.COM>
Date: 9 Jun 89 00:05:05 GMT
References: <125@ssp1.idca.tds.philips.nl> <20752@winchester.mips.COM> <26207@ames.arc.nasa.gov> <184@dg.dg.com> <19131@cup.portal.com> <26545@ames.arc.nasa.gov>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 27

[]
>In article <26545@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes:
>What isn't a clearly and completely defined ISA?
>
>1) ISA's which allow undefined or discovered instructions. An exception
>should be produced if an unused opcode or opcode+mode combination is executed.
>Do undefined opcodes or instruction 
>sequences matter if you can count on compilers not to produce them?  I can
>think of cases where they don't, but proving the reliability  and 
>security of the resulting systems is still necessary.  In order to do that,
>you need to define what the state of the processor *is* during one of these
>illegal-but-not-detected sequences, and prove that it isn't something it 
>shouldn't be.Anyone who puts stuff like that in an architecture has the burden
>of proof to demonstrate that it is OK, that you can build new implementations
>of the architecture which will produce the same results, that there are not
>any reliability or security problems, that an upward compatible extension of
>the architecture can be produced, etc.

The HP Precision architecture had lots of undefined (sub)opcodes, where the
architecture manual stated that what happened was undefined, implementation
dependent, but could not cause any security violations, i.e. you couldn't
access any registers or memory that could couldn't access with 'legal'
instructions.

--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum