An IEEE Question

[Fred Tydeman]

From:     Fred Tydeman, IBM's X3J11.1 (NCEG) representative
          IBM, Zip 9541
          11400 Burnet Road
          Austin, Texas  78758-3493
          Internet: tydemanaibmpa.awdpa.ibm.com
          UUCP: uunet!ibmsupt!tydeman
          (512) 838-3322;  tie-678-3322
 
Subject:  Request For Interpretation and comments.
 
In the ANSI/IEEE  Std 754-1985 (IEEE Standard  for Binary Floating-point
Arithmetic),  and  the   ANSI/IEEE  Std  854-1987  (IEEE   Standard  for
Radix-Independent  Floating-Point Arithmetic),  is signaling  a trap  an
"edge-triggered" or  a "level-sensitive"  event?  Does  it matter  if an
exception is signaled by an arithmetic operation versus a user setting a
status flag?
 
Consider the following four code fragments:
 
Case one:
  fp_enable_all_trapping();   /* Enable all trapping in control word */
  x = 0.0 / 0.0;              /* Signal invalid via operation */
  x = 1.0 / 0.0;              /* Signal divide by zero via operation */
  x = 1.0e300 * 1.0e300;      /* Signal overflow via operation */
  x = 1.0e-300 * 1.0e-300;    /* Signal underflow via operation */
  x = 1.0 / 3.0;              /* Signal inexact via operation */
 
Case two:
  fp_enable_all_trapping();   /* Enable all trapping in control word */
  fp_set_sticky_status_flags( Invalid );    /* Set sticky invalid flag */
  fp_set_sticky_status_flags( Div_by_zero );/* Set sticky divide by zero */
  fp_set_sticky_status_flags( Overflow );   /* Set sticky overflow flag */
  fp_set_sticky_status_flags( Underflow );  /* Set sticky underflow flag */
  fp_set_sticky_status_flags( Inexact );    /* Set sticky inexact flag */
 
Case three:
  fp_disable_all_trapping();  /* Disable all trapping in control word */
  x = 0.0 / 0.0;              /* Signal invalid via operation */
  x = 1.0 / 0.0;              /* Signal divide by zero via operation */
  x = 1.0e300 * 1.0e300;      /* Signal overflow via operation */
  x = 1.0e-300 * 1.0e-300;    /* Signal underflow via operation */
  x = 1.0 / 3.0;              /* Signal inexact via operation */
  fp_enable_all_trapping();   /* Enable all trapping in control word:
                                 How many traps are now taken?  */
 
Case four:
  fp_disable_all_trapping();  /* Disable all trapping in control word */
  fp_set_sticky_status_flags( Invalid );    /* Set sticky invalid flag */
  fp_set_sticky_status_flags( Div_by_zero );/* Set sticky divide by zero */
  fp_set_sticky_status_flags( Overflow );   /* Set sticky overflow flag */
  fp_set_sticky_status_flags( Underflow );  /* Set sticky underflow flag */
  fp_set_sticky_status_flags( Inexact );    /* Set sticky inexact flag */
  fp_enable_all_trapping();   /* Enable all trapping in control word:
                                 How many traps are now taken?        */
 
It is  clear from the  standard, that for case  one, five traps  will be
taken; one by one, in turn, for each exceptional operation.
 
It is  not clear  from the standard  what should happen  in each  of the
other three code fragments.
 
In case  two, the status  flags are set  explicitly by the  user, rather
than by an arithmetic operation as in case one.
 
In cases three and four, the trap handlers are disabled, some operations
are done  to signal traps,  and the trap handlers  are enabled.   In the
third case,  the operations  are arithmetic.   In  the fourth  case, the
operations are user ones to alter the status flags individually.
 
Another  way of  asking the  interpretation question  is:   If all  five
exceptions are  raised and then  traps are  enabled, how many  traps are
taken:  None, one, or five?  And, does it matter how the exceptions were
raised?
 
If no traps are taken in cases two, three, and four, that would say that
traps are "edge-triggered".  If one or  five traps are taken, that would
say that traps are "level-sensitive".
 
A  third way  to  ask the  question is:    Is one  set  of status  flags
sufficient to  comply with  IEEE-754, or  are two  sets of  status flags
required  to  comply?    If  one  set  is  sufficient,  then  traps  are
"level-sensitive".  In this case, a trap is taken when (status flag set)
AND (trap enabled)  is true.  If  two sets are required,  then traps are
"edge-triggered".  One set of status flags  would be used for the sticky
status and  have no influence  on traps.  A  second set of  status flags
would used  for trapping:   (trap  status flag  set) AND  (trap enabled)
being true would cause a trap.   To be "edge-triggered", the trap status
flags  would need  to be  cleared at  the start  of each  floating-point
operation and examined after each floating-point operation.
 
Note:  The Intel  80x87 family uses a single set of  status flags and it
is "level-sensitive".  The Motorola 6888x family uses two sets of status
flags and it is "edge-triggered".
 
Relevant sections of IEEE-754 (IEEE-854 is similar) and my comments upon
them:
 
        2.  Definitions
 
        status flag.   A variable that  may take two  states, set
        and clear.  A user may clear  a flag, copy it, or restore
        it to  a previous  state.   When set,  a status  flag may
        contain additional system-dependent information, possibly
        inaccessible  to some  users.    The operations  of  this
        standard may as  a side effect set some  of the following
        flags:   inexact result,  underflow, overflow,  divide by
        zero, and invalid operation.
 
        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 possibly 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.   It shall be reset  only at the  user's request.
        The user  shall be able to  test and to alter  the status
        flags individually, and should futher be able to save and
        restore all five at one time.
 
Does 'alter the status' mean that a user  may set a status flag?  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  flags 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).
 
 
Comments on IEEE-754:
 
1) Page 17, copysign.  Change 'even it' to 'even if'.
 
2) Are there  plans to change nextafter(x,y)  to return the result  y if
x=y?
 
3) Are there plans to  change the definition  of logb(x) in  IEEE-754 to
match the definition in IEEE-854?
 
 
Comments on IEEE-854:
 
1) Page 11, section 5.6, right hand column.  The last three lines are
the same as the first three lines.  They should be removed.
 
2) Are there  plans to change nextafter(x,y)  to return the result  y if
x=y?