Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Compiler quality [Was: GO TO "cobol"]

21 views
Skip to first unread message

prino

unread,
Apr 22, 2012, 12:56:51 PM4/22/12
to
On Apr 22, 12:58 pm, "HeyBub" <hey...@NOSPAMgmail.com> wrote:
> Nomen Nescio wrote:
>
> >> Then, as I said, write the damn thing in assembly language.
>
> > There isn't any need. We're fixing existing COBOL and it's easy to
> > fix. Just take stuff out of loops that doesn't belong there! It works
> > great..
>
> Is there still a compiler out there that doesn't change:
>
> PERFORM My-Many TIMES
>   MOVE 10 TO My-Constant
>   [do something else]
> END PERFORM.
>
> to
>
> MOVE 10 TO My-Constant
> PERFORM My-Many TIMES
>   [do something else]
> END-PERFORM.
>
> ???

Oh yes there is, that miracle of a compiler technology called
Enterprise PL/I V3R9...

70.0 19 1 do i = 1 to 10;
71.0 20 1 1 do j = 1 to 10;
72.0 21 1 2 t = 'Oops';
73.0 22 1 2 put skip list(substr(t, 1, 1));
74.0 23 1 2 end;
75.0 24 1 1 end;

0000B2 4100 0001 000070 | LA r0,1
0000B6 5000 D0CC 000070 | ST r0,I(,r13,204)
0000BA A70E 000A 000070 | CHI r0,H'10'
0000BE A724 0063 000070 | JH @1L8

0000C2 000070 | @1L2 DS 0H
0000C2 4100 0001 000071 | LA r0,1
0000C6 5000 D0D0 000071 | ST r0,J(,r13,208)
0000CA A70E 000A 000071 | CHI r0,H'10'
0000CE A724 0051 000071 | JH @1L10

0000D2 000071 | @1L5 DS 0H
0000D2 D203 D0D4 700C 000072 | MVC T(4,r13,212),'Oops'(r7,12)
<=== Oops...
0000D8 4110 D0D8 000072 | LA r1,T(,r13,216)
0000DC 5010 D180 000072 | ST r1,#STRTEMP1(,r13,384)
0000E0 9240 1000 000072 | MVI T(r1,0),64
0000E4 D219 1001 1000 000072 | MVC T(26,r1,1),T(r1,0)
0000EA 4100 D100 000073 | LA r0,_temp2(,r13,256)
0000EE 5000 D170 000073 | ST r0,_temp3(,r13,368)
0000F2 E544 D12C 4E48 000073 | MVHHI _temp2(r13,300),H'20040'
0000F8 5800 6004 000073 | L r0,SYSPRINT(,r6,4)
0000FC 5000 D16C 000073 | ST r0,_temp3(,r13,364)
000100 E54C D100 0001 000073 | MVHI _temp2(r13,256),H'1'
000106 4100 D168 000073 | LA r0,_temp3(,r13,360)
00010A 58F0 3008 000073 | L r15,=V(IBMQOFNT)(,r3,8)
00010E 4110 D098 000073 | LA r1,#MX_TEMP1(,r13,152)
000112 5000 D098 000073 | ST r0,#MX_TEMP1(,r13,152)
000116 0DEF 000073 | BASR r14,r15

000118 4100 6008 000073 | LA r0,_Dsc_000001(,r6,8)
00011C 5000 D11C 000073 | ST r0,_temp2(,r13,284)
000120 4100 7010 000073 | LA r0,'..'(,r7,16)
000124 5000 D118 000073 | ST r0,_temp2(,r13,280)
000128 4100 D0D4 000073 | LA r0,T(,r13,212)
00012C 5000 D114 000073 | ST r0,_temp2(,r13,276)
000130 9220 D12E 000073 | MVI _temp2(r13,302),32
000134 4100 D168 000073 | LA r0,_temp3(,r13,360)
000138 58F0 300C 000073 | L r15,=V(IBMQOFPT)(,r3,12)
00013C 4110 D098 000073 | LA r1,#MX_TEMP1(,r13,152)
000140 5000 D098 000073 | ST r0,#MX_TEMP1(,r13,152)
000144 0DEF 000073 | BASR r14,r15

000146 9201 D12E 000073 | MVI _temp2(r13,302),1
00014A 4100 D168 000073 | LA r0,_temp3(,r13,360)
00014E 58F0 300C 000073 | L r15,=V(IBMQOFPT)(,r3,12)
000152 4110 D098 000073 | LA r1,#MX_TEMP1(,r13,152)
000156 5000 D098 000073 | ST r0,#MX_TEMP1(,r13,152)
00015A 0DEF 000073 | BASR r14,r15

00015C 000074 | @1L6 DS 0H
00015C 000074 | @1L11 DS 0H
00015C 5800 D0D0 000074 | L r0,J(,r13,208)
000160 A70A 0001 000074 | AHI r0,H'1'
000164 5000 D0D0 000074 | ST r0,J(,r13,208)
000168 A70E 000A 000074 | CHI r0,H'10'
00016C A7D4 FFB3 000074 | JNH @1L5

000170 000074 | @1L7 DS 0H
000170 000074 | @1L10 DS 0H
000170 000075 | @1L3 DS 0H
000170 000075 | @1L9 DS 0H
000170 5800 D0CC 000075 | L r0,I(,r13,204)
000174 A70A 0001 000075 | AHI r0,H'1'
000178 5000 D0CC 000075 | ST r0,I(,r13,204)
00017C A70E 000A 000075 | CHI r0,H'10'
000180 A7D4 FFA1 000075 | JNH @1L2

000184 000075 | @1L4 DS 0H
000184 000075 | @1L8 DS 0H

And don't let me start about IBM's PL/I for Windoze product, which in
many cases generates code that is as "good" as the code generated by
Turbo Pascal in the mid 1980'ies... (Then again, nobody uses it, so
who cares)

And yes, IBM used to have a compiler that was capable of recognizing
this (to a certain extent), the venerable OS PL/I V2.3.0, predating
Enterprise PL/I by about a decade(?)...

You might also want to count the number of assembler statements in the
inner loop above and compare it with the number in the inner loop
below. (And then you may start to cry...)

17 1 0 DO I = 1 TO 10;
18 1 1 DO J = 1 TO 10;
19 1 2 T = 'Oops';
20 1 2 PUT SKIP LIST(SUBSTR(T, 1, 1));
21 1 2 END;
22 1 1 END;

* STATEMENT NUMBER 17
0000C6 58 50 3 060 L 5,96(0,3)
0000CA 50 50 D 0C4 ST 5,I
0000CE CL.4 EQU *

* STATEMENT NUMBER 18
0000CE 58 B0 3 05C L 11,92(0,3)
0000D2 58 A0 3 060 L 10,96(0,3)
0000D6 18 5A LR 5,10
0000D8 50 50 D 0C0 ST 5,J

* INITIALIZATION CODE FOR OPTIMIZED LOOP FOLLOWS

* CODE MOVED FROM STATEMENT NUMBER 19 <==== Yes we can^H^H^Hcould...
0000DC D2 03 D 0C8 3 08C MVC T(4),140(3)

* CONTINUATION OF STATEMENT NUMBER 18
0000E2 92 40 D 0CC MVI T+4,X'40'
0000E6 D2 19 D 0CD D 0CC MVC T+5(26),T+4
0000EC CL.6 EQU *

* STATEMENT NUMBER 19

* STATEMENT NUMBER 20
0000EC 41 70 D 110 LA 7,272(0,13)
0000F0 50 70 3 07C ST 7,124(0,3)
0000F4 18 17 LR 1,7
0000F6 50 10 D 108 ST 1,264(0,13)
0000FA 92 40 D 121 MVI 289(13),X'40'
0000FE 41 10 3 078 LA 1,120(0,3)
000102 58 F0 3 02C L 15,A..IBMBSIOE
000106 05 EF BALR 14,15
000108 D2 07 D 138 3 048 MVC 312(8,13),72(3)
00010E 41 40 D 0C8 LA 4,T
000112 50 40 D 138 ST 4,312(0,13)
000116 41 E0 D 138 LA 14,312(0,13)
00011A 41 F0 3 040 LA 15,DED..T
00011E 58 10 D 108 L 1,264(0,13)
000122 90 EF 1 000 STM 14,15,0(1)
000126 58 F0 3 034 L 15,A..IBMBSLOA
00012A 05 EF BALR 14,15
00012C 58 10 D 108 L 1,264(0,13)
000130 58 F0 3 030 L 15,A..IBMBSIOT
000134 05 EF BALR 14,15

* STATEMENT NUMBER 21
000136 87 5A 2 02A BXLE 5,10,CL.6
00013A 50 50 D 0C0 ST 5,J

* CODE MOVED FROM STATEMENT NUMBER 18

* STATEMENT NUMBER 22
00013E 58 50 D 0C4 L 5,I
000142 5A 50 3 060 A 5,96(0,3)
000146 50 50 D 0C4 ST 5,I
00014A 49 50 3 042 CH 5,66(0,3)
00014E 47 C0 2 00C BNH CL.4

* CODE MOVED FROM STATEMENT NUMBER 17

* STATEMENT NUMBER 23

Sigh...

Robert
--
Robert AH Prins
robert(a)prino(d)org

Peter Flass

unread,
Apr 22, 2012, 3:15:32 PM4/22/12
to
Are you requesting optimization?
--
Pete

prino

unread,
Apr 22, 2012, 3:56:29 PM4/22/12
to
On Apr 22, 7:15 pm, Peter Flass <Peter_Fl...@Yahoo.com> wrote:
> Are you requesting optimization?

I am, but turns out our test compiles add an OPT(0) after all
programmer supplied options "because that takes less CPU..." My
comment that this means that production programs are never the same as
the ones that have been tested was dismissed with a "We have done this
for years without anyone ever having a problem with it."

Submitting from SDSF with altered JCL does produce rather better code,
so I stand corrected (again, I'm loosing it, rapidly...)

000056 A50E 0010 000002 | LLILH r0,H'16'
00005A 5000 D0A0 000002 | ST r0,_Sfi(,r13,160)
00005E E54C D0A4 0000 000002 | MVHI _Sfi(r13,164),H'0'
000064 C00F 0018 0180 000002 | LLILF r0,F'1573248'
00006A 5000 D0A8 000002 | ST r0,_Sfi(,r13,168)
00006E E54C D0B4 0000 000002 | MVHI _Sfi(r13,180),H'0'
000074 A50E 0B00 000002 | LLILH r0,H'2816'
000078 5000 D0B8 000002 | ST r0,_Sfi(,r13,184)
00007C E3E0 3000 0014 000002 | LGF r14,=A(***TEST2)(,r3,0)
000082 A729 0001 000070 | LGHI r2,H'1'
000086 4140 D140 000000 | LA r4,_temp2(,r13,320)
00008A 4150 D130 000000 | LA r5,_temp3(,r13,304)
00008E 4160 D110 000000 | LA r6,T(,r13,272)
000092 C071 D696 97A2 000000 | LGFI r7,F'-694773854'
000098 50E0 E018 000002 | ST
r14,<s18:d24:l4>(,r14,24)
00009C 9231 D0B9 000059 | MVI _Sfi(r13,185),49
0000A0 50D0 D10C 000059 | ST
r13,<a1:d268:l4>(,r13,268)
0000A4 E300 3004 0014 000059 | LGF r0,=A(_ON_Begin_60_Blk_2)
(,r3,4)
0000AA 4180 E008 000000 | LA r8,_Dsc_000001(,r14,8)
0000AE 5000 D108 000059 | ST
r0,<a1:d264:l4>(,r13,264)
0000B2 E300 D108 0004 000059 | LG r0,_temp1(,r13,264)
0000B8 E300 D0BC 0024 000059 | STG r0,_Sfi(,r13,188)
0000BE C010 0000 00D1 000000 | LARL r1,F'209'
0000C4 E390 E004 0014 000000 | LGF r9,SYSPRINT(,r14,4)
0000CA 41A0 1010 000000 | LA r10,'..'(,r1,16)

0000CE 000070 | @1L2 DS 0H
0000CE A7B9 0001 000071 | LGHI r11,H'1'

0000D2 000071 | @1L5 DS 0H
0000D2 5070 D110 000072 | ST
r7,<a1:d272:l4>(,r13,272)
0000D6 E3F0 3008 0014 000073 | LGF r15,=V(IBMQOFNT)(,r3,8)
0000DC 5040 D138 000073 | ST
r4,<a1:d312:l4>(,r13,312)
0000E0 5090 D134 000073 | ST
r9,<a1:d308:l4>(,r13,308)
0000E4 5050 D098 000073 | ST r5,#MX_TEMP1(,r13,152)
0000E8 4110 D098 000073 | LA r1,#MX_TEMP1(,r13,152)
0000EC 9240 D114 000072 | MVI <a1:d276:l1>(r13,276),64
0000F0 D219 D115 D114 000072 | MVC T(26,r13,277),T(r13,276)
0000F6 E544 D16C 4E48 000073 | MVHHI
<a1:d364:l2>(r13,364),H'20040'
0000FC E54C D140 0001 000073 | MVHI
<a1:d320:l4>(r13,320),H'1'
000102 0DEF 000073 | BASR r14,r15

000104 E3F0 300C 0014 000073 | LGF r15,=V(IBMQOFPT)(,r3,12)
00010A 4110 D098 000073 | LA r1,#MX_TEMP1(,r13,152)
00010E 5080 D15C 000073 | ST
r8,<a1:d348:l4>(,r13,348)
000112 50A0 D158 000073 | ST
r10,<a1:d344:l4>(,r13,344)
000116 5060 D154 000073 | ST
r6,<a1:d340:l4>(,r13,340)
00011A 5050 D098 000073 | ST r5,#MX_TEMP1(,r13,152)
00011E 9220 D16E 000073 | MVI <a1:d366:l1>(r13,366),32
000122 0DEF 000073 | BASR r14,r15

000124 9201 D16E 000073 | MVI <a1:d366:l1>(r13,366),1
000128 5050 D098 000073 | ST r5,#MX_TEMP1(,r13,152)
00012C E3F0 300C 0014 000073 | LGF r15,=V(IBMQOFPT)(,r3,12)
000132 4110 D098 000073 | LA r1,#MX_TEMP1(,r13,152)
000136 0DEF 000073 | BASR r14,r15
000138 A7BA 0001 000074 | AHI r11,H'1'
00013C ECBC FFCB 0A7E 000074 | CIJNH r11,H'10',@1L5

000142 A72A 0001 000075 | AHI r2,H'1'
000146 EC2C FFC4 0A7E 000075 | CIJNH r2,H'10',@1L2

Apologies to all, I'm going to take a long break from here.

Robert
--
Robert AH Prins
robert(a)prino(d)org

>

Peter Flass

unread,
Apr 23, 2012, 7:56:50 AM4/23/12
to
On 4/22/2012 3:56 PM, prino wrote:
> On Apr 22, 7:15 pm, Peter Flass<Peter_Fl...@Yahoo.com> wrote:
>> Are you requesting optimization?
>
> I am, but turns out our test compiles add an OPT(0) after all
> programmer supplied options "because that takes less CPU..." My
> comment that this means that production programs are never the same as
> the ones that have been tested was dismissed with a "We have done this
> for years without anyone ever having a problem with it."
>
> Submitting from SDSF with altered JCL does produce rather better code,
> so I stand corrected (again, I'm loosing it, rapidly...)

Good. I'd expect that with OPT(0) the compiler would generate the most
straightforward code possible, even if it's fairly dumb code.

--
Pete
0 new messages