Download Processing Packed Decimal Data: Format, Instructions, and Conversions - Prof. Edward Boswo and more Study notes Programming Languages in PDF only on Docsity!
Processing Packed Decimal Data
The IBM System/360 is the outgrowth of two earlier product lines: the 704/709/ series and the 702/705/7080 series. The IBM 704/709/7090 series was a line of computers designed to support scientific research. This line supported binary arithmetic. ** The IBM 702/705/7080 series was designed to support commercial data processing. This line supported packed decimal arithmetic. The System/360 line was designed to bring these two lines together and implement a single architecture. For this reason, it had to support both decimal and binary arithmetic. ** NOTE: The IBM 704 series had a 36–bit instruction word in the following format. 3 bits 15 bits 3 bits 15 bits Prefix Decrement Tag Address LISP was developed on a 704 in 1958. Think of the following: CAR C ontents of the A ddress Part of the R egister CDR C ontents of the D ecrement Part of the R egister
Packed Decimal Format
Arithmetic is done on data in one of two formats: packed decimal or binary. Here, we discuss the packed decimal format, beginning with packed decimal constants. A packed decimal constant is a signed integer, with between 1 and 31 digits (inclusive). The number of digits is always odd, with a 0 being prefixed to a constant of even length. A sign “half byte” or hexadecimal digit is appended to the representation. The common sign–representing hexadecimal digits are as follows: C non–negative D negative F non–negative, seen in the results of a PACK instruction. If a DC (Define Constant) declarative is used to initialize storage with a packed decimal value, one may use the length attribute. Possibly the only good use for this would be to produce a right–adjusted value with a number of leading zeroes. For example DC PL6’1234’ becomes 00 00 00 01 23 4C Remember that each of these bytes holds two hexadecimal digits, not the value indicated in decimal, so 23 is stored as 0010 0011 and 4C as 0100 1100.
More Examples
The packed decimal format is normally considered as a fixed point format, with a specified number of digits to the right of the decimal point. It is important to note that decimal points are ignored when declaring a packed value. When such are found in a constant, they are treated by the assembler as comments. Consider the following examples and the assembly of each. Note that spaces have been inserted between the bytes for readability only. They do not occur in the object code. Statement Object Code Comments P1 DC P‘1234’ 01 23 4C Standard expansion to 5 digits P2 DC P‘12.34’ 01 23 4C The decimal is ignored. P3 DC PL4‘-12.34’ 00 01 23 4D Negative and lengthened to 4 bytes. Leading zeroes added. P4 DC PL5’12.34’ 00 00 01 23 4C Five bytes in length. This gives 2 bytes of leading zeroes. P5 DC 3PL2‘0’ 00 0C 00 0C 00 0C Three values, each 2 bytes.
Packed Decimal: Moving Data
There are two instructions that might be used to move packed decimal data from one memory location to another. MVC S1,S2 Copy characters from location S2 to location S ZAP S1,S2 Copy the numeric value from location S2 to location S1. Each of the two instructions can lead to truncation if the length of the receiving area, S1, is less than the source memory area, S2. If the lengths of the receiving field and the sending field are equal, either instruction can be used and produce correct results. The real reason for preferring the ZAP instruction for moving packed decimal data comes when the length of the receiving field is larger than that of the sending field. The ZAP instruction copies the contents of the sending field right to left and then pads the receiving field with zeroes, producing a correct result. The MVC instruction will copy extra bytes if the receiving field is longer than the sending field. Whatever is copied is likely not to be what is desired. Bottom line: Use the ZAP instruction to move packed decimal data, and be sure to avoid truncation.
Packed Decimal Data: Additional Considerations
For all three instructions, the second operand must be a valid packed field terminated with a valid sign. The usual values are ‘ C ’, ‘ D ’, and occasionally ‘ F ’. For AP and SP, the first operand must be a valid packed field terminated with a valid sign. For ZAP, the only consideration is that the destination field be large enough. If either the sending field or the destination field (AP and SP) have just been created by a PACK instruction, the sign half–byte may be represented by 0xF. This is changed by the processing to 0xC or 0xD as necessary. Some textbook hint that using ZAP to transfer a packed decimal number with 0xF as the sign half–byte will convert that to 0xC. Any packed decimal value with a sign half–byte of D (for negative) is considered to sort less than any packed decimal value with a sign half–byte of C or F (positive).
Example of Packed Decimal Instructions
The form is OP D1(L1,B1),D2(L2,B2). The object code format is as follows: Type Bytes Form 1 2 3 4 5 6 SS(2) 6 D1(L1,B1),D2(L2,B2) OP L 1 L 2 B 1 D 1 D 1 D 1 B 2 D 2 D 2 D 2 Consider the assembly language statement below, which adds AMOUNT to TOTAL. AP TOTAL,AMOUNT Assume: 1. TOTAL is 4 bytes long, so it can hold at most 7 digits.
- AMOUNT is 3 bytes long, so it can hold at most 5 digits.
- The label TOTAL is at an address specified by a displacement of X‘50A’ from the value in register R3 , used as a base register.
- The label AMOUNT is at an address specified by a displacement of X‘52C’ from the value in register R3 , used as a base register. The object code looks like this: FA 32 35 0A 35 2C
Condition Codes
Each of the ZAP, AP, and SP instructions will set the condition codes. As a result, one may execute conditional branches based on these operations. The branches are: BZ Branch Zero BNZ Branch Not Zero BM Branch if negative BNM Branch if not negative BP Brach if positive BNP Branch if not positive BO Branch on overflow BNO Branch if overflow has not occurred. An overflow will occur if the receiving field is not large enough to accept the result. My guess is that leading zeroes are not considered in this; so that the seven digit packed decimal number 0000123 can be moved to a field accepting four digit packed numbers.
Comparing Packed Decimal Values
The CP (Compare Packed) instruction is used to compare packed decimal values. This sets the condition codes that can be used in a conditional branch instruction, as just discussed. Is there any reason to compare and not then have a conditional branch? In some sense, the CLC (Compare Character) instruction is similar and may be used to compare packed decimal data. However, this use is dangerous, as the CLC does not allow for many of the standards of standard algebra. Consider the two values 123C (representing +123) and 123D (representing –123). CP will correctly state that 123D < 123C; indeed –123 is less than +123. CLC will state that 123D > 123C, as 12 = 12, but 3D > 3C. Remember that these are being compared as sequences of characters without numeric values. Consider the two values 123C (representing +123) and 123F (also representing +123). CP will correctly state that 123C = 123F; as 123 = 123. CLC will state that 123F > 123C, as 12 = 12, but 3F > 3C. Consider the two values 125C (representing +123) and 12345C (representing +12345). CP will work correctly, noting that 12345 > 00125. CLC will compare character by character. As ‘5’ > ‘3’, it will conclude that 125 > 12345.
Packing Blanks
A serious problem can arise if the field to be packed contains all blanks (EBCDIC code 0x40). Consider the five character input “ ” or EBCDIC 40 40 40 40 40. This will pack to the string “000004” , which lacks a valid sign. This invalid packed input cannot be processed by any packed decimal instruction. Some authors suggest checking all input fields and replacing those that are blank with all zeroes. This suggests a very common meaning of blanks as equivalent to 0. Here is the code, directly from Abel’s textbook. The input field, RATEIN , is supposed to contain one to five digits, but no more than five. CLC RATEIN,=CL5‘ ’ Is this a field of five blanks BNE D50 No, it is not all blanks MVC RATEIN,=CL5‘00000’ Replace 5 blanks with 5 zeroes D50 PACK RATEPK,RATEIN Store packed value in RATEPK
More on Input of Packed Data
Recall that the input of packed data is a two–step procedure.
- Input the digits as a string of EBCDIC characters.
- Convert the digits to packed format. The format of the input is dictated by the appropriate data declarations. In this example, we consider the following declaration of the form of the input, which is best viewed as an 80–column card.
RECORDIN DS 0CL80 80 CHARACTER CARD IMAGE
DIGITS DS CL5 FIRST FIVE COLUMNS ARE INPUT
FILLER DS CL75 THE OTHER 75 ARE IGNORED
Here is a properly formatted input sequence. 1 Four blanks before the “1”. 3 13 Three blanks before the “13”.
One Error: Assuming Free–Formatted Input
Here is some input from the same program. It did not work.
Here is the way that the input was interpreted.
To me this looks like 10000 + 30000 + 13000 + 17000.
The Output for the Erroneous Input
I had expected the above input to give a sum of 70000. It did not.
Here is the actual output. All we get is the print echo of the first line input.
***PROGRAM FOUR CSU SPRING 2009 ***********
Here is the code loop for the processing routine.
B10DOIT MVC DATAPR,RECORDIN FILL THE PRINT AREA
PUT PRINTER,PRINT START THE PRINT
PACK PACKIN,DIGITSIN CONVERT INPUT TO DECIMAL
AP PACKSUM,PACKIN ADD IT UP
BR R8 RETURN FROM SUBROUTINE
What is the problem. Each of the first two lines worked.
It is either the PACK or the AP instruction that fails.
The Diagnosis
Look again at the input.
The first line, as EBCDIC characters is read as follows.
F1 40 40 40 40
The PACK command processes right to left. It will process any kind of data,
even data that do not make sense as digits.
The above will pack to something like X‘10004’ , an invalid packed format.
With no valid sign indicator, the AP instruction will fail.
Printing Packed Data
In order to print packed decimal data, it must be converted back to a string
of EBCDIC characters.
The unpack command, UNPK, appears to convert data in Packed Decimal
format to EBCDIC format, actually converts to Zoned Decimal format.
UNPK almost converts to EBCDIC. It has an unfortunate side effect, due to the
simplicity of its implementation, which is a direct conversion to Zoned format.
The problem occurs when handling the sign code, “ C ” or “ D ” in the Packed
Decimal format. This occurs in the rightmost byte of a packed decimal value.
Consider the decimal number 47, represented in binary in register R4.
CVD R4,PACKOUT produces the packed decimal 047C. This is correct.
When this is unpacked it should become F0 F4 F
Unpack just swaps the sign half byte: F0 F4 C.
This prints as 04G , because 0x C7 is the EBCDIC code for the letter ‘G’.
We have to correct the zone part of the last byte.
