lamaster@ames.arc.nasa.gov (Hugh LaMaster) (06/07/89)
In article <19131@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes: >Hugh (and anyone else), could you post a short summary of architectures >that don't have the above? I don't have sufficient information to post a complete list, and I don't want to seem biased, so perhaps some folks from some companies out there can tell us what they wish they had done better (and *will*, next time :-) >E.g., what is (and isn't) a clearly- and completely-defined ISA? 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. 2) ISA's which allow undefined or discovered instruction sequences. The ISA should define what happens when the processor is executing delayed branches, compound instructions, or interruptable/continuable instructions, and page faults, external interrupts, or exceptions (e.g arithmetic exceptions from previously issued instructions) occur. The results of "special" instruction sequences should be defined. Illegal sequences should result in exceptions. For example, if an instruction in the delay slot of a branch cannot be a branch target, then the result of doing so should be an exception. Likewise, branches in the delay slots of branches, etc. 3) ISA's for which the entire documentation is an assembly manual. What is a clearly and completely defined ISA? 1) An ISA for which any conforming implementation produces exactly the same result (process state, visible processor state) from the same input, regardless of conditions external to the process such as external interrupts invisible to the process. If the process is dependent on timing, then the result *can* be different. 2) An ISA for which documentation exists, such that a software simulator can be written based on the documentation resulting in a conforming implementation. 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. At least, if you care about using your processor for general purpose computing. Please don't say things like: "Well, the probability of a page fault occurring precisely when a floating divide exception occurred two clock cycles previously is 10**-12, so it will only happen once every three months..." :-) I am not saying that companies which have produced such systems are immoral, or that I won't use them, or whatever. But, as I have stated previously, I think a little attention to detail in this area would have a big payoff for some of us users out here. Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
baum@Apple.COM (Allen J. Baum) (06/09/89)
[] >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