preserving context-independence

[Jonathan S. Shapiro]

Having decided to observe the KeyKOS design on the red segment issue,
I'm still troubled by the fact that the description of the behavior
relies on the slot's expected size.  I believe that it should rely
only on the capability.

I want to propose an alternative *description* of the address tree
walk that relies only on the key.  It differs slightly from the
behavior of the KeyKOS mechanism in the case of the domain root slot,
but it is a difference that will not matter in practice.

First, the domain root difference:

In KeyKOS, as I undestand matters from Norm, the "expected size" of
the segment is defined by the architected address space size.  In my
discription this is no longer true.

My observation is that this condition will never be violated by a
hardware-generated address, because the hardware itself is guaranteed
not to generate an address beyond the defined address range of the
hardware.

Since the check can never be violated at the domain root, we can
safely omit it in the formal specification without any change of
behavior.

Proposed description:

The interpretation of an address against a segment key proceeds in two 
phases: context update and then address interpretation.

Context update:

First, we determine if the key defines a new exception and/or
interpretation context.  This is true only if the key is a red segment
key.  In this phase, we may possibly update:

	the responsible keeper
	the active background segment

Strictly speaking, the update of the active background segment should
not occur until we are examining the slots of the red segment node,
but we know that the current key is not a background window by virtue
of the fact that we know it is a red segment key.  It therefore does
not cause any errors to update the background window key at this
point.


Address interpretation:

We now proceed with the interpretation of the address according to the 
LSS value for the key, which in this case is the LSS value encoded in
the red segment node.


As far as I can see, the net effect of this change is that if a red
segment of LSS=X is sitting in a slot whose expected LSS=Y, and X < Y, 
the fault will now be directed to the red segment keeper as in KeyKOS.

The advantage is that it is now possible to speak about interpreting
an address against a segmode key without knowing what slot the segmode 
key was in.


shap