[Next] [Up/Previous]

# Register Packed Decimal

The first of these types, known as Register Packed, increases the efficiency of packed decimal arithmetic by performing packed decimal operations between fixed-length (preferably aligned) operands in memory and the arithmetic-index registers.

The same modified ten's complement notation is used for negative numbers as for conventional packed decimal operands:

```0 00
1 01
2 02
3 03
4 04
5 05
6 06
7 07
8 08
9 09
A 94 (negative) i.e. A000 0000 = 9 4000 0000 = -6000 0000
B 95 (negative)
C 96 (negative)
D 97 (negative)
E 98 (negative)
F 99 (negative) i.e. F999 9999 = 9 9999 9999 = -1
```

the first digit is, in effect, expanded to two digits according to the table above, and the result is taken to be in ten's complement notation.

Thus, a 32-bit register can contain eight-digit values which range from -60,000,000 to 99,999,999.

The instructions belonging to this group are:

```000600 101xxx  RPC    Register Packed Compare
000600 102xxx  RPME   Register Packed Multiply Extensibly
000600 103xxx  RPDE   Register Packed Divide Extensibly
000600 104xxx  RPA    Register Packed Add
000600 105xxx  RPS    Register Packed Subtract
000600 106xxx  RPM    Register Packed Multiply
000600 107xxx  RPD    Register Packed Divide

000600 111xxx  RPCL   Register Packed Compare Long
000600 112xxx  RPMEL  Register Packed Multiply Extensibly Long
000600 113xxx  RPDEL  Register Packed Divide Extensibly Long
000600 114xxx  RPAL   Register Packed Add Long
000600 115xxx  RPSL   Register Packed Subtract Long
000600 116xxx  RPML   Register Packed Multiply Long
000600 117xxx  RPDL   Register Packed Divide Long
```

Note that load, store, and swap instructions are not required, as the conventional binary integer instructions can be used to move data in and out of the arithmetic/index registers. Their opcodes are therefore used for the Multiply Extensibly and Divide Extensibly instructions, in order that only one column, rather than two, of opcode space is used by each type.

Also note that the effective address of an instruction of this type always refers to the byte of the packed decimal operand at the lowest address, irrespective of whether the computer is in its normal mode of operation or, through the setting of the "Most significant/leftmost in high address" bit in the Program Status Block, in little-endian mode; this is unlike the case of conventional packed decimal operands, handled by instructions related to the character string instructions.

Given that it should be considered a mistake that the IBM 7030 or STRETCH computer provided only floating-point arithmetic and bit-field arithmetic, as, despite a very efficient implementation of bit-field access, it still had enough overhead that integer operations were instead usually done using unnormalized floating-point instructions, it seemed to me that providing only packed decimal operations on fields that began and ended at arbitrary bytes could be another form, although much less severe, of the same error. A precedent for register-based packed decimal operation in a computer that supports both binary and packed decimal operation can be found in the Honeywell 800 computer, which preceded the System/360 in offering binary and decimal capabilities on the same machine. (However, although it had a 48-bit accumulator, when doing signed binary arithmetic, it used four bits of the accumulator for the sign, so that architecture was not without its own strange limitations.)

Note that while this prefix can be used in any mode of operation, there is only one arithmetic unit for BCD calculations, which is linked to the main arithmetic unit. This does not mean that long vector register packed instructions are not available: the architectures on which such instructions were first implemented only had a single pipelined arithmetic unit; and other types, such as 128-bit floating point, to which long vector instructions are more applicable, will likely have this same limitation even on large implementations of this architecture.

[Next] [Up/Previous]