Decades of compiler technology and what do we get?

On Apr 22, 12:58 pm, "HeyBub" <hey...@NOSPAMgmail.com> wrote in
bit.listserv.ibm-main:


  > > 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.
  > >
  > > ???


To which yours truly replied:


  > 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... (wrapped)
  > 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...


Maybe the experts in this group would like to give their thoughts about
the why of this apparently/seemingly/obviously ridiculous(?) regression?


Robert
--
Robert AH Prins
robert(a)prino(d)org
[The conventional wisdom is that COBOL programs are all I/O bound, so
the speed of the object code is not a big deal. There are plenty of
other compilers that can optimize this kind of stuff. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.