Vision_Architecture_Status_Feb83.pdf part of HP Vision Architecture Status Feb83 Vision_Architecture_Status_Feb83.pdf, HP vision Vision_Architecture_Status

Text preview for : Vision_Architecture_Status_Feb83.pdf part of HP Vision Architecture Status Feb83 HP vision Vision_Architecture_Status_Feb83.pdf

Back to : Vision_Architecture_Statu | Home

HElJLm PACKARD Basically, a switch lIlarker will be an external procedure
l1larker with STATUSB added; an interrupt l1larker is then a
COMPUTER SYSTEMS - 19447 Pruneridge Ave. CUpertino CA 95014 SlIJitch l1larker with XO-X15' and BO-B5 added.
An additional bit in the TCB, called RSYIP (return-switch
in progress) will keep the IEXIT logic straight.
----------------------------------------------------------------------- UpdatedACD pages are provided.
Frol1l: Bert Speelpenning X413~ Date: February 8, 1983 b) switch entry point
To: Dick Anderson Subject: VISION architecture A dedicated object in group zero (see under 11) will
Alan Christensen status (CPU) provide the'entry point for the switch software in
Shane Dickey native lIlode. The SlIJitch operation is no longer regarded
Bob Erickson as a trap. I t will have no paraJlleters.
Bob Frankenberg This will sav~ 'SOl1le execution time at the expense of
Bill Gimple SCll1le replicated code.
Larry Goldman (IND)
Rich HaJIIl1lons (TCG)
Carson Kan 2. Nil~:blect spec if i.cat ions
Leon Leong (I NO )
Jil1l Nissen The Nil' object is further defined (relative to the ACD"version 5)
Ed Olander to guarantee that all implelllentations ca~se consistent traps ,to
Elik Porat occur :,rhen atte!1lpting to access lIlel1lory through the nil pointer.
Howard S!1li th The full statel1lent is that operating syste!1l software shall set
Ken Spalding the OD of object zero in group zero to values that correspond to
an object type of data, access rUhts R31d3, a lower bound of 1
Cc: Alan Hewer and an upper bound of O.:Tht vi;.tual object nUl1lber of the nil
Jil1l Miller object shall also be fixed ~~z~lb.
Dave Salol1laki
3. SIT trap
An updated description of the HP3000 l1lode 'of the Vision architecture The SIT trap (DBSIT) will report the pointer to the next
has now been released, through the efforts of Terry Jackson. instruction as its paraJII~.ter rather than the previous instruction
For questions or cOl1ll1lents pleaSe refer to Terry.
j
address. The obvious ,hardware implel1lentation for SIT uses similar
logic -'lS for external. interrupts and it is unnecessarily expensive
The following issues have been resolved, cl~rified or addressed for hardwaret.o hang on to the previous instruction counter.
,sinu~ the pre'"ious Vision CPU architecture l1lel1lo. Ide don' texpect thiS. to create any diff,~'(;ulty for f<1oftware.

4, AcceSS rights checking
1. Mode SlIJitch
Both VCF60 and VCF50 teaJlls have requested reconsideration of
Ide have identified several ways to shave til'le frolll~the lIlode SlIJitch certain aspects of the access rights checking rules.
operations between Vision lIlode and HP300Q Plode. This is clearly
il1lportant for the perforl1lance of HPE. ' a) write access to iIIlply read access
a) switCh Aarker Hardware silllpll-tications accrue (and redesign can be
avoided) if write access to a data object always iIIlplies
SlIIitching lIIodes is not a truly asynchronO\lSevent like read access. The access right fields in an Object
an external interrupt;":' This allotas us to get by with Il(-lscriptor ,keep their original l1leaning; we plan to lIIerely
saving only a subset'df the register values" undQr software "add a state.lllent that operating systel1l softlJlare shall
qontrol. this l1leans that fewer pushes and pops are , "nat ~reateobjects that have write access without also
requHed to do the l1lode SlIJitch. ' In order to accol1lp'lish granti~ the\ll, read access.
this we need to distinguish between a SlIJitch l1larker and
a full blown interrupt l1larker. Ide also need to give lEXIT
the lIleans to distinguish between the two lIlarkers.

\
b) read access to the current code object For this to really work, we need to extend the notion of overlap
to cover the case exel'lplified by MOVE8 [B5+X6], X6.
The ACD roakes a distinction bet~een read access to the If MOVE8 encounters a page fault at [B5+X6+1] , the value of X6
current code object and read access to the saroe object roay already have been l'Iodified to the value at [B5+X6].
~hen it does not happen to be the current code object. To avoid this, the definition of "overlap" l'Iust incorporate the
It does this by stating that read access to the current cOl'lponents of an address calculation for the source operands.
code object is al~ays granted regardless of the contents
of the Obj'ect Descriptor for the, code object.
7. Code object size
,Currently, this ca'n be iropleroe~ted on the VCF60 and the
, VCF50, only by, doing extra ~ork in CALLX and EXIT, ~hich A Vision mode code object is limited in size to 2~24 bytes.
',will slo~, these il'lpprtant instructions do~n. . This is not currently stated explicitly in the ACO but could be
l.Jetherefore feel that very strong reasons are needed asSUl'\ed froro the forroat of the external procedure l'Iarker.
to retain this exceptional treatl'lent of the current code We no~ l'Iake this assuroption explicit.
object in the Vision architecture. If you feel you have
such strong reasons, ~e would like to hear them by Feb 15.
On the HP3000, P-relative addressing of data is a basic 8. OST and CST descriptors
addressing roode and the only one available to offer
protection to third-party soft~are. On Vision, no l.Je will extend the MOVEfSP8 instruction to allow software to
perforl'lance benefits derive from keeping data in your get access to the current values of the CST and OST descriptors.
code segroent rather than in soroe data segroent, and third-
party software can be protected by separate privilege
level and by exploiting the group structure. 9; Bounds checking on variable length instructions
Some instructions such as MaVEC and CMPC involve a sequence of
5. Interruptible instructions byte operations over a length given in the instruction.
The way bounds checking is perforl'led optil'lally in such an
Questions have been raised regarding the expected behavior when instruction depends on the organization of the hardware. On the
an interruptible instruction is resul'led and finds that its data VCF60, bounds checking is performed in parallel with an actual
on the stack has been corrupted. In particular, ~hat should access. On the VCF50, bounds checking is done explicitly in
happen when the lIP bit is set but the word popped frol'l the stack microcode As a consequence, on the VCF60 it is fastest to start up
(which represents how roany til'les around the loop have already the loop of MOVEC or CMPC and trap out when the end of the object
been performed) is found to be negative? is reached before the loop counter is exhausted. In contrast, on
The expected behavior in this and siroilar cases is allowed to be the VCF50 it is fastest to check whether both first and last byte
il'lplementation dependent, as long as the "damage" does not extend are within bounds and not do any bounds checking for interl'lediate
to another task. For exarople, it is acceptable to iml'lediately bytes once the loop starts.
continue to the next instruction when this happensj it is not The issue then arises when and how a bounds violation roust be
acceptable to hang in an infinite microcode loop. reported and how much of the instruction should be preSU!1led to
have been cOl'lpleted when this occurs.
l.Je have decided that hardware should be left free to choose the
6. "Overlap" sequence that is optil'lal for it. The definition for MOVEC ~ill
no~ state that if MOVEC cannot be completed due to a bounds violation,
The notion of overlap between source and destination of an the effect of MOVEC is that a contiguous but unspecified nUl'lber of
instruction needs soroe revision to get' around,sol'le nasty bytes has been l'Ioved, all ~ithin the object's bounds.
roicrocode iroplications. An instruction such as A siroilar l'Iodification ~ill serve for CMPC.
MOVE8 source, destination
10. Pagecfault trap
is only guaranteed to obtain the expected result when the
destination does not "overlap" the source. This is to allo~ The pararoeters for the page fault trap are currently listed as
hardware to do the roove in either one 64-bit gulp or two, 32-bit including an 8-byte Virtual Page Nurober (left justified) and
gulp or (probably incase of misaligroents) insomenul'lber of odd- a 4-byte.;P~ge" Offset (right justified).
sized gulps, and yet be able to recover from a page fault in l.Je have collapsed these no~ to a single a-byte Virtual Address.
the l'Iiddle of the l'Iove. The exclusion of overlap roakes it
permissible to restart the instruction even if the destination
had been partially l'Iodified.
11. Architecturally fixed object numbers 14. "MENSAC" instructions
We have received a request fro~ HPE-I to dedicate certain objects We have decided in principle to adopt the ~e~ory diagnostic
in group zero for certain uses and to fix these objects capabilities proposed by Jim Yichelroan and Ji~ Chiochios.
architecturally. In the version 5 ACD, four objects are fixed by We are in the process of refining all the encodings to assist
their logical address (the NIL object, trap code object, channel the hardware in iropleroenting these.
interrupt code object and processor interrupt code object) and The latest iteration is reflected in a roemo by Brian Button
four are fixed by their virtual address (SYSCOM area, hasn table, dated Feb 1.
page directory and PME). We have been asked to extend this list
and also to J1Iove the logical object nu~bers for trap code object,
etc. downward so that SYSCOM area, etc. can be given a logical 15. STATUSC'and STATUSD
object number that is the same as its virtual object number.
The current definition of STATUSC and STATUSD is based on the
We believe that the only object nUJ1lbers (logical or virtual) that difference in behavior of changes in status in a shared-~eJ1lory
need to be fixed architecturally are those that ~ust be known to J1Iultiprocessor syste~. Ite~s in STATUSC, when changed, do not
both software and roicrocode. Any other object numbers can be fixed affect any other processor in the systeJ1l; whereas changes to
by software convention, not "architectural mandate. STATUSO must be propagated to all other processors in the shared-
We are willing to move the logical object,nuro~ers for trap code memory ulultiprocessor syste~.
object, etc. downward in order to make it possible for HPE-I to
implement the sche~e they proposed as a software convention. We are currently investigating whether the responsibility'for
The revised numbering is shown below. More object numbers will notifying other processors can be relegated to syste~ software;
be fixed only after it has been demonstrated that both software this would J1Iake the multiprocessor imple~entation potentially
and hardware (microcode) are affected. simpler, faster and more reliable.
Until this investigation is cOJ1lplete, we will hold off on other
logical address changes to STATUSC and STATUSD that have been proposed, such as
reJ1loving the J1Iode bit froJ1l STATUSC.
NIL object
trap object
group
group
0,
0,
object
object