Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #613
| From | Robert AH Prins <robert@prino.org> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Decades of compiler technology and what do we get? |
| Date | 2012-04-22 18:57 +0000 |
| Organization | Compilers Central |
| Message-ID | <12-04-070@comp.compilers> (permalink) |
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]
Back to comp.compilers | Previous | Next — Next in thread | Find similar
Decades of compiler technology and what do we get? Robert AH Prins <robert@prino.org> - 2012-04-22 18:57 +0000
Re: Decades of compiler technology and what do we get? Robert AH Prins <robert@prino.org> - 2012-04-22 22:14 +0000
Re: PL/I nostalgia, was Decades of compiler technology and what do we get? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-23 00:03 +0000
Re: PL/I nostalgia "robin" <robin51@dodo.com.au> - 2012-04-25 09:07 +1000
Re: PL/I nostalgia glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-24 23:52 +0000
Re: PL/I nostalgia "robin" <robin51@dodo.com.au> - 2012-04-28 21:30 +1000
Re: PL/I nostalgia glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-04-28 16:11 +0000
Re: PL/I nostalgia Robert A Duff <bobduff@shell01.TheWorld.com> - 2012-04-29 10:16 -0400
Re: PL/I code "robin" <robin51@dodo.com.au> - 2012-05-05 00:45 +1000
Re: PL/I code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-05-05 05:20 +0000
Re: Fortran calls, was PL/I code glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-05-06 05:13 +0000
Re: Archaic hardware (was Fortran calls) "robin" <robin51@dodo.com.au> - 2012-05-09 10:46 +1000
Re: PL/I nostalgia "robin" <robin51@dodo.com.au> - 2012-09-19 11:04 +1000
Re: PL/I nostalgia glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-09-19 03:56 +0000
Re: PL/I nostalgia "robin" <robin51@dodo.com.au> - 2012-09-21 13:53 +1000
Re: PL/I nostalgia glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-09-21 07:00 +0000
Re: PL/I nostalgia "robin" <robin51@dodo.com.au> - 2012-09-30 10:45 +1000
csiph-web