This section deals with the instructions that perform register-to-register arithmetic.

This diagram shows the standard floating-point types provided in this architecture:

They include the types specified in the IEEE 754 standard, and a 128-bit Extended type without a hidden first bit.

As well, in addition to the standard 32-bit single precision and 64-bit double precision types, some additional types have been added.

A 48-bit type has been added to provide a precision that closely matches that which had been found adequate for a large class of scientific problems. The size of the exponent field was chosen so as to include the exponent range provided by typical electronic scientific calculators - both pocket calculators, and calculators like the Wang 500, the Monroe 1655, and the Hewlett-Packard 9100A which preceded them. As well, this format provides about eleven decimal digits of precision.

Also, a 40-bit type has been added as an alternative to the 32-bit single precision type which may have just enough additional precision to be useful for a significant range of problems; this is in reaction to the fact that single precision arithmetic was considered to be more useful for scientific computation on older 36-bit machines than it was after the newer 32-bit machines arrived.

The nine-bit opcode for the standard register-to-register arithmetic instructions is sufficient to provide a wide range of operations.

The original floating-point format of the System/360 is handled, so as to permit simulation programs to run more efficiently. However, the floating-point registers will normally be set up to contain numbers in the IEEE 754 Extended format, with conversion taking place when they are loaded with Single, Long Single, Medium, or Double floating-point numbers. So any other format of number must instead be held in the integer registers.

This is the primary reason why there are Double Long memory reference instructions, to handle the form of extended precision introduced on the System/360 Model 85.

As well, the integer registers may also used for packed decimal numbers.

The Decimal Floating-Point standard included in later revisions of the IEEE 754 standard is also supported; in order to be able to use the floating-point registers for this type, while converting floating-point numbers to an internal representation suitable for more efficient calculation, type information is associated with the floating-point registers. How this was dealt with was noted previously, but will be repeated here:

Associated with each floating-point register, but not directly accessible to the programmer, are
status bits which indicate the type of data currently contained in the register. Conversions between
types are *not* automatically performed, and an attempt to perform an operation involving a
floating-point type incompatible with that of the current contents of the register will result in that
register being set to a zero of the new type before the operation is performed.

Compatibility between types is as indicated by the following chart:

FP CFP DFP CDFP MCDFP Floating-Point * 0 0 0 0 Compatible Floating-Point 0 * 0 0 0 Decimal Floating-Point 0 0 * X X Compatible Decimal Floating-Point 0 0 X * X Modified Compatible Decimal Floating-Point 0 0 X X * * : types match, operation performed without issue X : types are compatible, conversion takes place 0 : types are incompatible, register contents are zeroed before operation

For the various decimal floating-point types, the internal register contents are the same, a mantissa composed of packed decimal digits, and a binary power-of-ten exponent.

For the two binary floating-point types, the internal register contents differ, with the exponent being a power of two and the mantissa being normalized so that the first binary digit is a one for IEEE 754 types, but the exponent being a power of 16, and the mantissa being normalized so that the first hexadecimal digit is nonzero for the compatible floating-point type.

However, the floating-point registers also have **Load Multiple** and **Store
Multiple** instructions available which operate on them.

A **Store Multiple** instruction will function as a generic store instruction: the
contents of the register will be converted to their external representation in memory as appropriate for
their current type, and that will be stored.

A **Load Multiple** instruction will load the data from memory into the floating-point
registers without conversion, flagging the contents of the registers as untyped. When a floating-point
register has untyped content, then the conversion from memory representation to the appropriate internal
representation is deferred until a floating-point operation on that register takes place: while floating-point
operations do not convert *between* types, they **do** automatically convert from untyped
memory-image data.

In this way, programs which only use one basic format of floating-point data may operate transparently without concern for the fact that the internal format of floating-point data in floating-point registers is not the same as that used in memory.

The intent of this conversion is to make floating-point computation more efficient; one specific benefit is that denormals are processed as quickly as ordinary floating-point numbers.

In order to ensure that program interrupts are completely transparent to the user, that they introduce no security flaws, and that they do not compromise efficiency, an alternate form of load multiple and store multiple instructions for the floating-point registers must be provided at least for the use of interrupt service routines. These instructions will store the internal contents of each register in a 160-bit region in memory. |

Decimal digits are represented using the 10-bit coding that belongs to IBM's Densely Packed Decimal scheme:

BCD digits Densely Packed Decimal encoding 0abc 0pqr 0uvw abcpqr0uvw 0abc 0pqr 100W abcpqr100W 0abc 100R 0uvw abcuvR101w 100C 0pqr 0uvw uvCpqr110w 0abc 100R 100W abc10R111W 100C 0pqr 100W pqC01r111W 100C 100R 0uvw uvC00R111w 100C 100R 100W 00C11R111W

The overall format of a Decimal Floating-Point number is illustrated below:

A DFP number is composed of four fields, with lengths as given in the table below:

Overall Sign CF BXCF CCF Length 32 1 5 6 20 64 1 5 8 50 128 1 5 12 110

The first part of the number is the sign, which is one bit long.

The second part of the number is the Combination Field (CF), which is always five bits long.

The combination field contributes one decimal digit, and two binary bits, to the significand and the exponent of the number respectively.

Its format is as is shown in this table:

bbaaa Number begins with 0 to 7 11bbA Number begins with 8 or 9 11110 Infinity 11111 NaN First digit of number: aaa: A: 0 000 8 0 1 001 9 1 2 010 3 011 4 100 5 101 6 110 7 111

The exponent is binary, and its first two bits may only be 00, 01, or 10, never 11.

The third field is the rest of the exponent, called the Binary eXponent Continuation Field (BXCF). The exponent bias is as given in the table below:

Length of Exponent number Bias 32 101 64 398 128 6,176

Thus, a 32-bit number has an eight bit exponent, two bits from the combination field plus six bits from the BXCF, that varies from 000000 to 101111, and it is an excess-101 exponent.

The fourth and final field is the Coefficient Continuation Field (CCF), and consists of 2, 5, or 11 groups of three decimal digits represented by ten binary bits in Densely Packed Decimal encoding. These are the digits which follow the first digit of the number that was given by the Combination Field.

Note that the coding of the Combination Field allows the first digit to be zero. Therefore, unnormalized numbers can be expressed in this format. This is intentional. The description of the format includes rules for determining the "ideal exponent" of an arithmetic operation. Essentially, those rules are based on the principle of treating all inputs to the arithmetic operation as exact, and producing a result which has no additional padding of zeroes after the least significant digit.

In addition to the IEEE 754 Decimal Floating Point format, particularly useful for spreadsheet calculations, a simpler decimal floating-point format, once used with Wang VS mainframes, is also supported. In this format, the mantissa is simply composed of packed decimal digits without any compression; the exponent remains represented in binary form, and the overall format has the same general layout as that of floating-point numbers in the Compatible format.

The additional types also supported are illustrated here: