Heading:qjk40(635)
Mesa Floating Point Instructionsy756qjk40
Page Numbers: Yes  X: 527  Y: 10.5"qjk40
DRAFT - DRAFT - DRAFT - DRAFTz18592l4445y748c\f5b
DRAFT - DRAFT - DRAFT - DRAFTz18592l4445y14c\f5b
Inter-Office Memorandumz18592l4445y762\f5b
To	Mesa Floating Point Committee	Date	July 9, 1980z18592l4445d2998e21(0,65535)(1,4445)(5,11684)(6,14146)\f1 2f0t2 1t0 29t6 1f1t0 4f0t7 1t0
z18592l4445
From	L. Stewart	Location	Palo Altoz18592l4445d2998y716e25\f1 4f0t2 1t0 10t6 1f1t0 8f0t7 1t0
Subject	Mesa Floating Point	Organization	PARC/CSLz18592l4445d2998e25\f1 7f0t2 1t0 19t6 1f1t0 12f0t7 1t0
Instructionsz18592l4445
XEROX       z18592l508y644e14(2116)\f2 5f0
Filed on: [Maxc]<LStewart>MesaFP3.bravoe30
e10
Introductione12jk40\b12B
This memo presents a proposal for a floating point instruction set for Mesa.e12jk40
Architectural principles:e12jk40
Full IEEE Standard Floating Point (KCS proposal - see January 1980 Computer).  Single and double precision.l4269e12jk40\67i8I
Exception enable flags and sticky flags on a per-process basis.l4269e12jk40
Arguments passed on Mesa evaluation stack (expanded to 14 words by the time double precision comes along).l4269e12jk40
The results of an instruction should be predictible (static modes - see below).l4269e12jk40
Static modes and enablese12jk40\b24B
It has been recommended (SDD Architecture Board), that the modes of a floating point operation (rounding, normalization, infinity) and the enable flags (fixOverflow, inexactResult, invalidOperation, divisionByZero, overflow, underflow) which determine whether exceptional conditions cause a SIGNAL, be part of the instruction.  The modes determine the 'preliminary result' of an operation.  If exceptional conditions arise during the operation or if the preliminary result will not fit into the destination, then the enable flags determine whether a SIGNAL is generated.  If a SIGNAL is raised, generally the client gets control (or the compilation fails), if not, then the standard specifies the result, generally as a special bit pattern Not-A-Number[reason].e12jk40\59i5I75i12I140f1 6f0 253f1 6f0 21f1 6f0 170i6I
Whether or not exceptional conditions cause a SIGNAL (based on the enable flags), the conditions set the 'sticky' flags, so that the client can later tell if any exceptions occurred.  (Apparently the standards committee feels that not only should there be a flag bit, but a reference to some information about the first offending operation -- but this is not written down anywhere.)  The sticky flags are global state information and might be changed by the actions of a procedure call that, unknown to the client, used floating point.e12jk40\46f1 6f0 262i5I
In order to conform completely to the standard, some mechanism for dynamically set modes and enable flags must be provided.e12jk40
Static modes seem to have two great advantages: compile time optimizations, and predictible program behavior.  In the absence of knowledge of how to form the preliminary result (modes), the compiler cannot evaluate expressions (or indeed, perform any floating point operations except conversion to LONG REAL).  In addition, the results of a procedure would not be changed as a result of a caller changing the modes.e12jk40\298f1 9f0
Including the enable flags in the instruction does not seem to have nearly as high utility as including the mode; while a compile time operation producing an exception would not have to form the Real.Extended record associated with a Real.FloatingPointException, the compiler would still have to generate code to set the sticky flags at the appropriate moment at runtime.  In any case, the compiler is free to evaluate any expression which does not produce exceptions.e12jk40\445i3I
If evaluation of an expression at compile time produces conditions like fixOverflow, divideByZero, invalidOperation, or overflow, probably the most reasonable response is to produce a compilation error.  It is almost as reasonable that underflow produce a compilation error.  The most difficult case is inexactResult, which indicates that rounding has taken place.e12jk40
Proposale12jk40\b
This proposal for floating point instructions provides two opcodes per operation.  The default instruction set, described by the interface Real, uses the modes round-to-nearest, warning-normalization, and projective-infinity.  The exception enable flags are also fixed, ase12jk40\139i4I
Real.UsualExceptions: ExceptionFlags = [overflow: TRUE, invalidOperation: TRUE, divideByZero: TRUE, fixOverflow: TRUE];l3705d2999e12jk40\f7
The disabled traps are inexactResult and underflow.e12jk40
The second, more general instructions take their modes and enable flags off the stack.  The interface RealOps describes these operations.e12jk40\102i7I
For static modes and trap enables, the compiler can generate load immediate instructions to set up the mode, for clients wishing to use dynamic modes, an instruction will be provided that pushes the dynamic mode (kept in the process state) onto the stack.e12jk40
Use of static modes and dynamic enables is not so easy, but could be done by loading the mode from a variable.  Finally, to handle the case of a compile time operation which produces exceptions which are not enabled, an instruction will be provided that sets the sticky flags from a word on the stack.e12jk40
Double precision is not fixed yet, but the general outline should be similar.  Double cannot be implemented until the mesa stack size is increased.e12jk40
Compiler and languagee12jk40\b21B
Normally, the compiler uses the default modes and attempts to evaluate constant expressions.  If any exceptions other than inexact-result occur, compilation errors are produced.  Inexact-result is not reported, but the runtime system sets up the initial state of the sticky flags so that the inexact-result flag is turned on.e12jk40
Some (as yet unspecified) language construct attached to a block allows the programmer to specify either constant modes and enable flags or use of the values in the process state.  In the latter case, the compiler would not evaluate any constant expressions.  Possibly a way could be found of associating a variable of type RealOps.Mode (a one-word record containing the modes and enables) with a particular block.e12jk40
In the case of non-default but constant modes, the compiler can evaluate expressions.  Expressions which produce no exceptions are, of course, fine.  Expressions which produce enabled exceptions should cause compilation errors.  Expressions which produce exceptions which are not enabled should evaluate and also generate an instruction to set the sticky flags.  (Of course the compiler could defer the evaluation of such expressions until runtime.)e12jk40
Conversion of decimal constants presents some interesting problems, as the conversion can produce exceptions.  In the case of known constant modes, the conversion should be done using those modes as for any other operation.  In the case of dynamic modes, the decimal value should be not be converted until runtime.e12jk40
Runtimee12jk40\b7B
Because conversion from decimal to floating point may take place at compile time or at run time, the runtime conversion procedure must behave the same way as the compiler procedure.  To allow this, the conversion procedure will have an extra parameter specifying the modes.  Explicit calls to the conversion procedure inside a block with constant non-default modes will have to explicitly pass those modes.e12jk40
The same problem (and solution) applies to other operations such as RoundLI, RoundI and RoundC implemented by procedures rather than instructions.e12jk40
Referencese12jk40\b10B
Definitions files:e12jk40
[Ivy]<CedarLib>Real>Real.mesal4269e6jk40
[Ivy]<CedarLib>Real>RealOps.mesal4269e6jk40
e12jk40
e12j