NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/arch/9072

Text File | 1992-08-27 | 4.7 KB | 109 lines

Newsgroups: comp.arch
Path: sparky!uunet!sun-barr!cs.utexas.edu!torn!cunews!nrcnet0!bnrgate!bmerh85!bcars64a!bqneh3!schow
From: [e-mail] (Stanley T.H. Chow)
Subject: Re: trapping speculative ops
Message-ID: <[e-mail]>
Sender: [e-mail] (Usenet News)
Organization: Bell Northern Research Ltd, Ottawa
References: <[e-mail]> <[e-mail]>
Date: Thu, 27 Aug 1992 19:55:49 GMT
Lines: 97

><Stanley T.H. Chow>
>| Very nice model, but what to do about saving and restoring registers
>| across subroutine call, interupts, etc.?
>
><Cliff Click>
>Soft answer:
>The compiler knows that live and possibly dangerous results cannot be
>carried across a subroutine call.  Therefore it uses every possibly
>dangerous result before the subroutine call.  This means you cannot
>lift that divide-by-zero across the subroutine call.

Not very nice. Depending on the language and type of program, this
could pretty much stop hosting anything. In any case, there still
remain the problem of interrupts.

>Hard answer:
>The hardware allows these bits to be read and written using a special
>register.  The special register can be "slow" because it's assumed to be
>an infrequent operation.  The trap bits are saved and restored along with
>the registers.

So you are suggesting that all the "trap" bits are addressable as one
registers. Accesses to "normal" registers will check the relevant bit
in this register. In an interrupt handler, this trap-bits registers
will be saved and restored along with the normal registers.

I believe this is the same as option 3 suggested by Homayoon Akhiani in
his article (as you mentioned later, the only difference is when the
exception is actually raised).

Unforturnately, this does not allow you to reserve some registers for
use during interrupt since the trap-bits register must be saved/restored
as a single entity.

On second thought, this is not a problem, you can save/restore the
whole trap-bits register while only save/restore some of the normal
registers. (Hmm, touching an uninitialized register may cause a trap,
may be this is a feature!)

>Interrupts appear to require the "hard answer", but there is another way
>(albeit possible worse):
>
>Harder Soft answer:
>Only 1 interruptable condition can exist at a time.  The compiler forces the
>issue by using the possible dangerous register before it allows another
>operation which can cause a dangerous register.  External interrupts are
>disabled while a dangerous register exists.  The compiler ensures that no
>register is kept dangerous for longer than the desired interrupt latency.
>Since only 1 interrupt can occur at a time, no trap bits need to be saved
>or restored.
>Scheduling restrictions in this answer are probably worse than implementing
>the hardware solution.  I have no idea what you can implement cheaply in
>hardware.

Not to mention that external interrupts are now gated by register values
that could change every clock, could get tricky.
>
><Cliff Click>
>|| Pre-fetch for long-distance memory can be implemented with a simple LOAD.
>|| If a page fault is required for the LOAD the fault is delayed until the
>|| register is used.  If the pre-fetch is speculative, no page fault occurs.
>
><Stanley T.H. Chow>
>| Presumably, the prefetch will use a different opcode, or do you mean all
>| references should behave like this?
>
><Cliff Click>
>All references behave this way.  No seperate prefetch opcode required.

But if the prefetch was not speculative, it would be nice to have the load
go forward. For page fault, it doesn't make much difference, but a TLB
miss could well have been hidden. Conceivabily, one may want control over
the cache behaviour as well.

><Homayoon Akhiani>
>| I believe that there is a 3rd option:
>| Hardware has Trap Status and Control register
>|   Using the control resgister, Software will disable all traps.
>|   So when a exception rises, the hardware will not trap, it will update the
>|   "Status Register" and follows the normal execution path.
>
><Cliff Click>
>Upon re-reading your example, I see that you can test the trap results on a
>*per-register* basis.  Thus the only difference between your model and my
>model is that (1) traps are tested explicitly by the software, instead of
>implicitly (by reading the register) and (2) interrupts can be made precise
>by having the hardware trap as soon as they occur (software ENABLEs all traps).

also:
(3) software can choose to ignore traps for the whole program, just enable
traps at the end to see if anything happened.

--
Stanley Chow            InterNet: [e-mail]
Bell Northern Research  UUCP:     ..!uunet!bnrgate!bqneh3!schow
[phone]
Me? Represent other people? Don't make them laugh so hard.