Conversion of character data

[Peter Flass]

There's been an interesting discussion about data conversions on
alt.folklore.computers. Since some of this has relevance to PL/I, I
thought I'd re post a bit here. I had to go back to Google groups to
retrieve the posts...

It's interesting that Enterprise PL/I is still one instruction worse
than COBOL on the character to binary case at the end.

---quoted text---
Sadly I'm not sure I have access to a working COBOL compiler,
but I do have Enterprise PL/I.
Strangely:
DCL BIN_F FIXED BIN(31);
DCL CHAR_F CHAR(9) INIT ('123456789');
...
BIN_F = CHAR_F;
The assignment, statement "38" with OPT(3) generates:
000038 | LA r0,_Dsc_000002(,r4,16)
000038 | LA r5,BIN_F(,r13,208)
000038 | LA r14,CHAR_F(,r13,212)
000038 | L r15,=V(IBMQHCAA)(,r3,24)
000038 | LA r1,#MX_TEMP1(,r13,152)
000038 | ST r0,#MX_TEMP1(,r13,160)
000038 | LA r0,+CONSTANT_AREA(,r6,24)
000038 | ST r0,#MX_TEMP1(,r13,156)
000038 | LA r0,+CONSTANT_AREA(,r6,72)
000038 | ST r14,#MX_TEMP1(,r13,152)
000038 | ST r5,#MX_TEMP1(,r13,164)
000038 | ST r0,#MX_TEMP1(,r13,168)
000038 | BASR r14,r15
Not sure why this needs a subroutine call, perhaps there's
some error checking?
Packed decimal does better:
DCL DEC_F DEC FIXED(9,0) INIT(123456789);
...
BIN_F = DEC_F;
000040 | ZAP #pd755_1(8,r13,384),DEC_F(5,r13,224)
000040 | CVB r0,#pd755_1(,r13,384)
000040 | ST r0,BIN_F(,r13,208)

-- COBOL code for conversions---
CBL LIST,OPT
IDENTIFICATION DIVISION.
PROGRAM-ID. TEST1.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 BIN9 PIC S9(9) COMP.
01 DISP9 PIC S9(9).
01 PACKED9 PIC S9(9) COMP-3.
01 BIN18 PIC S9(18) COMP.
01 DISP18 PIC S9(18).
01 PACKED18 PIC S9(18) COMP-3.
PROCEDURE DIVISION.
MAINLINE.
MOVE DISP9 TO BIN9.
MOVE PACKED9 TO BIN9.
MOVE DISP18 TO BIN18.
MOVE PACKED18 TO BIN18.
STOP RUN.
000013 *MAINLINE
000014 MOVE
0001EA 5820 912C L 2,300(0,9)
0001EE F278 D098 2008 PACK 152(8,13),8(9,2)
0001F4 4F30 D098 CVB 3,152(0,13)
0001F8 5030 2000 ST 3,0(0,2)
000015 MOVE
0001FC F874 D098 2018 ZAP 152(8,13),24(5,2)
000202 4F30 D098 CVB 3,152(0,13)
000206 5030 2000 ST 3,0(0,2)
000016 MOVE
00020A F223 D098 2028 PACK 152(3,13),40(4,2)
000210 F27E D09A 202B PACK 154(8,13),43(15,2)
000216 D207 D0B0 A04E MVC 176(8,13),78(10)
00021C D207 D0B8 D0B0 MVC 184(8,13),176(13)
000222 D204 D0B3 D09D MVC 179(5,13),157(13)
000228 4F30 D0B0 CVB 3,176(0,13)
00022C F144 D0B3 D098 MVO 179(5,13),152(5,13)
000232 4F50 D0B0 CVB 5,176(0,13)
000236 5C40 C000 M 4,0(0,12)
00023A 1E53 ALR 5,3
00023C 47C0 B066 BC 12,102(0,11)
000240 5A40 C004 A 4,4(0,12)
000244 GN=7 EQU *
000244 1233 LTR 3,3
000246 47B0 B070 BC 11,112(0,11)
00024A 5B40 C004 S 4,4(0,12)
00024E GN=8 EQU *
00024E 9045 2020 STM 4,5,32(2)
000017 MOVE
000252 D209 D0A0 2040 MVC 160(10,13),64(2)
000258 D204 D0BB D0A5 MVC 187(5,13),165(13)
00025E 4F30 D0B8 CVB 3,184(0,13)
000262 F144 D0BB D0A0 MVO 187(5,13),160(5,13)
000268 4F50 D0B8 CVB 5,184(0,13)
00026C 5C40 C000 M 4,0(0,12)
000270 1E53 ALR 5,3
000272 47C0 B09C BC 12,156(0,11)
000276 5A40 C004 A 4,4(0,12)
00027A GN=9 EQU *
00027A 1233 LTR 3,3
00027C 47B0 B0A6 BC 11,166(0,11)
000280 5B40 C004 S 4,4(0,12)
000284 GN=10 EQU *
000284 9045 2020 STM 4,5,32(2)
000018 STOP

---"Correct" PL/I version---
Thanks, I had a suspicion I wasn't giving PL/I enough hints.
So:
DCL BIN_F FIXED BIN(31);
DCL CHAR_F PIC '999999999' INIT (123456789);
...
BIN_F = CHAR_F;
PUT SKIP EDIT('%M%: BIN_F: ',BIN_F,'.')(A,A,A);
000039 | PACK #pd591_1(5,r13,376),_shadow3<auto1:106>(9,r13,204)
000039 | MVC #pd592_1(5,r13,384),#pd591_1(r13,376)
000039 | MVN #pd592_1(1,r13,388),+CONSTANT_AREA(r5,313)
000039 | ZAP #pd593_1(8,r13,392),#pd592_1(5,r13,384)
000039 | CVB r0,#pd593_1(,r13,392)
000039 | ST r0,BIN_F(,r13,200)
Better, but, I think this is equivalent:
000039 | PACK #pd593_1(8,r13,392),_shadow3<auto1:106>(9,r13,204)
000039 | NI #pd592_1(r13,388),X'0F'
000039 | CVB r0,#pd593_1(,r13,392)
000039 | ST r0,BIN_F(,r13,200)
Pack directly to double word.
Set sign without extra storage reference.

--
Pete

[John W Kennedy]

No, it is not equivalent. Your NI instruction should be an OI, and the
first operand should be #pd593_1(1,r13,399). Even then, it is
equivalent if and only if the byte at +CONSTANT_AREA(r5,313) in the
first version, which you do not give, is X'xF'. It would not surprise
me if it were actually X'xC', instead.

In fact, the code is still less than optimal; it should contain only
the PACK, CVB, and ST instructions. The adjustment of the sign is an
ad-hoc fixup necessary only if the declaration does not truthfully
describe the data.

--
John W Kennedy
"The bright critics assembled in this volume will doubtless show, in
their sophisticated and ingenious new ways, that, just as /Pooh/ is
suffused with humanism, our humanism itself, at this late date, has
become full of /Pooh./"
-- Frederick Crews. "Postmodern Pooh", Preface

[Robin Vowels]

A string can contain leading and trailing blanks,
and upon conversion it is checked for illegal characters.
As well, SIZE and FIXEDOVERFLOW may be raised.

As a character field might contain a float or other such number.
a subroutine is perhaps best for dealing with the conversion.

In any case, this example is artificial, in that such code
wouldn't be written.

> Packed decimal does better:

You'd expect that, because the decimal value is already in
packed decimal format, which can be easily converted.