No subject

[Fred Tydeman]

Subject:  Trapping: Level or edge sensitive
 
I believe that the following notes and discussions between Fred Tydeman,
David Hough, and Jim Thomas are of interest to the general numeric group.
 
A discussion came up, in the IEEE subgroup, at the March 1990 NCEG as to
when is trapping down  in an IEEE environment.  The  basic question was:
Are traps taken because a sticky status  bit is (already) set when traps
are enabled (level sensitive) or when a  status bit gets set after traps
are  enabled  (edge sensitive).    The  Intel  80387 follows  the  level
sensitive model, whereas  the Motorola 68881 follows  the edge sensitive
model.
 
What should  happen on  a Floating-point unit  that conforms  to IEEE-754
when the following three operations are executed:
 
fp_disable_all_trapping();  /* Turn off all trapping in control word */
fp_set_sticky_status_flags( Invalid | Div_by_zero | Overflow | Underflow |
        Inexact );          /* Set all the flags in the status word */
fp_enable_all_trapping();   /* Turn on all trapping in control word:
                               How many traps are now taken?        */
 
I believe one of three actions will happen:
 
1) Five traps will be taken, one for each of the status flags set and the
   corresponding trap enabled.
2) One trap will be taken, and it is  up to the trap handler to take care
   of five status flags set and five traps enabled.
3) No trap will be taken.
 
For case two,  it is the responsibility  of the trap handler  to reset or
clear the sticky status flag and/or the trap enablement.  Otherwise, when
the trap handler returns, the same trap will be taken.
 
Cases one  and two  correspond to  the taking  of a  trap being  a level-
sensitive issue:  trap = control bit enabled AND status flag.
 
Case three corresponds to taking of a trap being an edge-triggered issue:
trap  = control  bit  enabled AND  status  flag  of current  instruction.
Therefore, enabling traps with the status flags set does not cause a trap
to be taken.   An instruction must cause a status flag to  be set (it may
already be set) for a trap to be taken.  Hence one needs three registers:
control, sticky status, and status of current instruction.
 
I believe that the Intel 80387 does  action 2 and that the Motorola 68881
does action 3.
 
Is IEEE-754  vague enough that  these different philosophies  all comply?
Or is there only one correct response, and which one is it?
 
Fred Tydeman, IBM, Palo Alto, Calif., (415) 855-4430
uucp: uunet!ibmsupt!tydeman    Internet: tydemanaibmpa.awdpa.ibm.com
=========================================================================
Date: Wed, 28 Mar 90 12:59:29 PST
Subject:  Trapping: Level or edge sensitive
 
What should  happen on  a Floating-point unit  that conforms  to IEEE-754
when the following operations are executed:
 
fp_disable_all_trapping();  /* Turn off all trapping in control word */
x = 1.0 / 0.0;              /* Set divide by zero via operation */
x = 0.0 / 0.0;              /* Set invalid via operation */
fp_set_sticky_status_flags( Invalid | Div_by_zero | Overflow | Underflow
        | Inexact );        /* Set all the flags in the status word */
fp_enable_all_trapping();   /* Turn on all trapping in control word:
                               How many traps are now taken?        */
 
Relevant sections of IEEE-754 and my comments upon them:
 
        7.  Exceptions:
 
        There are five types of exceptions that shall be signaled
        when detected.  The signal entails setting a status flag,
        taking a trap, or possible doing both.
 
        For  each  type  of exception  the  implementation  shall
        provide a status flag that shall be set on any occurrence
        of the corresponding exception when no corresponding trap
        occurs.
 
If the  user sets  the status  flag, is  that the  same as  an arithmetic
operation setting the flag?  Is a user setting a status flag an exception
that shall be signaled when detected?
 
        The only  exceptions that can  coincide are  inexact with
        overflow and inexact with underflow.
 
Does this mean that  a user setting all five status  flags does not cause
any exceptions?  A user can save and  restore all five at one time, so up
to five  may coincide.   This must mean a  user setting the  status flags
causes no exceptions.  What traps may coincide?
 
        7.3 Overflow.  Trapped overflows on all operations except
        conversions shall deliver to the  trap handler the result
        obtained  by dividing  the infinitely  precise result  by
        2**a and then rounding.
 
        7.4  Underflow.   Trapped  underflows  on all  operations
        except conversions shall deliver to  the trap handler the
        result  obtained by  multiplying  the infinitely  precise
        result by 2**a and then rounding.
 
Overflow and underflow have prescribed results that must  be delivered to
the trap  handler, but  for overflow  and underflow,  what result  can be
delivered if  this is  the result of  the user  setting the  status flags
causing a trap, rather than the result of an actual math operation?
 
        8.  Traps
 
        When an exception whose trap  is disabled is signaled, it
        shall be handled in the manner specified in Section 7.
 
        When an exception  whose trap is enabled  is signaled the
        execution of the program in  which the exception occurred
        shall be suspended, the trap handler previously specified
        by the user shall be activated, and a result if specified
        in Section 7, shall be delivered to it.
 
Overflow and underflow have prescribed results that must  be delivered to
the trap  handler, but  for overflow  and underflow,  what result  can be
delivered if  this is  the result of  the user  setting the  status flags
causing a trap, rather than the result of an actual math operation?
 
        8.1 Trap Handler.
 
        ...  the flag(s)  corresponding to  the exceptions  being
        signaled  with  their  associated traps  enabled  may  be
        undefined unless set or reset by the trap handler.
 
This may mean that the trap handler  had better turn off the status flags
to prevent causing the same trap to be taken again.
 
        A  trap  handler  should  have   the  capabilities  of  a
        subroutine that can return a value  to be used in lieu of
        the  exceptional  operation's  result;   this  result  is
        undefined unless delivered by the trap handler.
 
        When a system  traps, the trap handler should  be able to
        determine
        (1) Which exception(s) occurred on this operation
        (2) The kind of operation that was being performed
        (3) The destination's format
        (4) In  overflow, underflow, and inexact  exceptions, the
        correctly  rounded  result,  including  information  that
        might not fit in the destination's format
        (5) In invalid  operation and divide by  zero exceptions,
        the operand values.
 
If setting the sticky bits later causes up to five traps, what is the
operation that caused the exception?  What are the operands?
What value should be returned?  Since these cannot be done in a
meaningful manner, it must mean that user setting sticky flags does
not cause a trap.
 
        8.3 Precedence
 
        If  enabled,  the  overflow   and  underflow  traps  take
        precedence over a separate inexact trap.
 
This implies  to me that  at most two traps  may coincide, and  hence the
sticky status flags  do not determine what  traps are taken (since  up to
five flags may be set).
 
I originally thought  that the Intel i80387 with  traps enabled conformed
to the IEEE-754 standard.  Upon  more careful reading, and arguments from
David Hough of Sun  and Jim Thomas of Apple, it appears  that it does not
conform.
 
Fred Tydeman, IBM, Palo Alto, Calif., (415) 855-4430
uucp: uunet!ibmsupt!tydeman    Internet: tydemanaibmpa.awdpa.ibm.com
=========================================================================
Date: Wed, 4 Apr 90 14:47:07 PDT
From: ibmsupt!uunet!Sun.COM!dghaibmpa.tcspa.ibm.com (David Hough)
To: ibmsupt!tydeman, apple!jimt
Subject: what happens when
 
> Subject:  Trapping: Level or edge sensitive
>
> What should  happen on  a Floating-point unit  that conforms  to IEEE-754
> when the following operations are executed:
>
> fp_disable_all_trapping();  /* Turn off all trapping in control word */
> x = 1.0 / 0.0;              /* Set divide by zero via operation */
> x = 0.0 / 0.0;              /* Set invalid via operation */
> fp_set_sticky_status_flags( Invalid | Div_by_zero | Overflow | Underflow
>         | Inexact );        /* Set all the flags in the status word */
> fp_enable_all_trapping();   /* Turn on all trapping in control word:
>                                How many traps are now taken?        */
>
 
All implementations that I know about (mainly MC68881 and SPARC) do not
cause a trap to occur simply by enabling trapping, regardless of the
state of the accrued exception field.
 
Fred points out many places in the standard that support the conclusion
that such implementations are correct.
 
> I originally thought  that the Intel i80387 with  traps enabled conformed
> to the IEEE-754 standard.  Upon  more careful reading, and arguments from
> David Hough of Sun  and Jim Thomas of Apple, it appears  that it does not
> conform.
 
I think the correct conclusion is that the 80387 provides some additional
operations that weren't contemplated in IEEE 754.  The obvious one of
writing accrued exception bits without causing a trap, that was
contemplated by IEEE 754, would appear to require implementation in
software rather than by a single instruction.
=========================================================================
Date: Tue, 22 Jan 91 10:00:00 PST
Subject:  Trapping: Level or edge sensitive
 
So it appears that there are two  sets of status information that must
be kept, in hardware or software:
 
   The sticky  (accrued) status  bits that  are set  if traps  are not
   taken.  They may also be set if a trap is taken.  These bits may be
   examined and altered  (set or reset) by  the user.  These  bits, in
   any state, do not cause traps to be taken.
 
   The status  of current instruction.   These bits being set  and the
   corresponding trap being  enabled cause a trap to be  taken.  These
   bits are cleared before each floating-point instruction.
 
Fred Tydeman, IBM, Palo Alto, Calif., (415) 855-4430
uucp: uunet!ibmsupt!tydeman    Internet: tydemanaibmpa.awdpa.ibm.com