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.