Consider what happens when you have an interest in the setting of the OVFLO flag. This flag will be raised if a floating-point overflow occurs and the OVFLO trap (a mode) is disabled.
Say you have
Program A
computes some, and with OVFLO disabled,
raises OVFLO by doing some naughty arithmetic (*)
A Calls program B
B Calls program C
This program enables OVFLO trap,
sets up its own trap handler that on OVFLO
prints ``you overflowed'', clears the OVFLO flag
and returns to B
B returns to A
In A, now, the program asks ``is OVFLO flag set?''
WHAT IS THE ANSWER? See (*) above
It is necessary to store a fp status ``shadow'' in memory (or perhaps some other neutral territory) so that programs can query flags, maintain their own notion of sticky flags, through thick and thin, regardless of interventions that include:
intermediate user programs using the flags: setting, clearing
intermediate actions of the operating system (which may very well be forced to clear sticky flags just to get out of the default interrupt handler).
How to maintain flags?
read and save old flag
OldOVFLO=FPFLAG(OVFLO,newval)
is not likely to write into OVFLO machine status bit, since it can only clear it, not raise it. The machine status word is too ephemeral for use directly, because the wrong programs may clear it.
FPFLAG must maintain a shadow value for the OVFLO flag which may need to be recalculated by looking at the machine register (typically ORing a machine bit into the shadow bit); this shadow value can be (nay, must be) maintained through software entry and exit protocols if sticky flags are to be useful to software. Making sure that exit protocols and executed is difficult.
If a software shadow flag is already set, we can take advantage of that knowledge. If it is not set, it may be costly to find out if it is REALLY not set because the hardware register must be consulted.
Nevertheless, querying flags after a major section of code may be a valuable alternative to trapping and writing trap handlers. (Scheduled for Saturday)