🚀 go-pugleaf

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