On Tue, 2013-11-26 at 23:59 -0600, Bill Long wrote:
> On 11/26/13 2:35 PM, FX wrote:
> >> I would expect it to halt, but the standard says "Halting is not
> precise and may occur any time after the exception has occurred." so I
> don't think this can be guaranteed.
> >
> > Yes, I know because of this sentence, halting is not guaranteed. But
> you’re saying it could happen.
> >
> >> In section 14.3 of the standard are the words "Each exception has a
> flag whose value is either quiet or signaling. The value can be
> determined by the subroutine IEEE_GET_FLAG. Its initial value is quiet
> and it signals when the associated exception occurs. Its status can
> also be changed by the subroutine IEEE_SET_FLAG or the subroutine
> IEEE_SET_STATUS."
> >>
> >> The intention is to allow the programmer to provoke the same effect
> as when the hardware signals the condition. Mind you, the usual way to
> use IEEE_SET_FLAG is to set the flag quiet - I think all the examples
> in the standard are like this.
> >
> > My reading was that “[the flag] signals when the associated
> exception occurs” is an one-sided implication: “exception occurs ==>
> flag signals”, but nothing specifies that “flags signals ==> exception
> occurs” (and halting is linked to exceptions occuring, not flags being
> raised). Thus, halting is not allowed to happen. (Both the Intel and
> Sun compilers do not halt, as a matter of fact.)
> >
> > I can’t speak for the intent, though… but if that was the intent,
> maybe this should be clarified. Does it seem interp-worthy to you? If
> so, how should I proceed?
> >
> 
> I tried the test with compilers from multiple vendors, all targeting the 
> same hardware (x86_64),  and got a mix of results - some trapped and 
> others did not.  Perhaps more interesting, I tried compilers from the 
> same vendor targeting two different hardware architectures and had one 
> trap and the other not. In the case that trapped, the compiler  had 
> inlined the module procedures and the set flag operation was reduced to 
> a trivial sequence of instructions that moved the contents of the 
> control register to an arithmetic register, OR'ed in the correct bit, 
> and then moved the result back to the control register.  Setting the 
> control register caused the trap by the hardware since traps for that 
> exception had been enabled. That result suggests the "processor 
> dependent" answer might be the best we could do.

Since one processor was able to caused a trap, and another was able to
avoid it, both on the same platform that is supposedly IEEE compliant,
it seems the standard could be more precise than "processor dependent."

We should decide what we want to happen, perhaps by consulting the IEEE
standard or the P754 committee, and say so.  Since the next standard is
presumably almost done, maybe that's a better place to do it than with
the interp mechanism.  Add an item to the "new stuff" list in the
introduction that says "this used to be ambiguous and now it's not."

The processor that caused the trap did so by setting the flag in the
control register.  Presumably the one that avoided the trap set the flag
in a cached copy, or maybe had halting turned off.  This suggests that
if the processor actually sets the flag, not a cached copy of it, a trap
ought to occur if halting is turned on.  Does IEEE_SET_FLAG mean "set
the flag" or "set a cached copy of the flag and return that if anybody
asks?"

IEEE_SET_HALTING with a HALTING argument true ought to turn on halting
for the specified flag, if halting for the corresponding exception is
supported.

John wrote "The intention is to allow the programmer to provoke the same
effect as when the hardware signals the condition."  That suggests that
if IEEE_SET_HALTING has turned halting on, and the platform supports
halting, setting a flag that corresponds to an exception that would
cause a halt ought to cause a halt.

Whether halting is initially on can and perhaps should be explicitly
processor dependent.

Van

> 
> Cheers,
> Bill
> 
> 
> > Thanks,
> > FX
> >
>