Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!labrea!agate!pasteur!ames!pacbell!att-ih!ihnp4!inuxc!iuvax!pur-ee!uiucdcs!uxc.cso.uiuc.edu!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: comp.arch
Subject: Re: Sticky overflow (was Shift and
Message-ID: <28200125@ccvaxa>
Date: 18 Mar 88 03:46:00 GMT
References: <8421@eleazar.Dartmouth.EDU>
Lines: 23
Nf-ID: #R:eleazar.Dartmouth.EDU:8421:ccvaxa:28200125:000:1068
Nf-From: ccvaxa.UUCP!aglew    Mar 17 21:46:00 1988


..> Sticky overflow bits in Honeywell machines

A class I am taking (High Performance Processor Design) is currently
discussing techniques for providing precise interrupts with out of
order instruction scheduling - checkpoint/restore, history buffers,
past register sets, etc.

This mention of sticky overflow bits causes me to wonder if it might
not be advantageous to let the DETECTION of an exception condition
(trap or pagefault, not an asynchronous event like an external interrupt)
be done by software checking sticky flags, and making the return to
checkpointed state under software control.


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
    aglew@gould.com     	- preferred, if you have MX records
    aglew@xenurus.gould.com     - if you don't
    ...!ihnp4!uiucuxc!ccvaxa!aglew  - paths may still be the only way
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.