John, I wrote some PL/1 sometime ago on OS/VS2 ...long long time ago in a galaxy far away. Working at a manufacturing facility in the 80s, we ran VM/SP and VM/HPO with VSE and had an application written in PL/1 , lets say it wasnt performing very well. But we also ran a DL/1 with CICS..
Scott On Sun, Dec 25, 2016 at 10:08 PM, Robert Prins <[email protected]> wrote: > -------- Forwarded Message -------- > Subject: Re: A not very Christmassy PL/I tale > Date: Sun, 25 Dec 2016 18:13:55 -0500 > From: Charles Mills <[email protected]> > Reply-To: PL1 (language) discussions <[email protected]> > To: [email protected] > > > > > the speed of the machine seems to obviate the need to write a good > compiler. > > Au contraire. Moore's law is over. Machines are not getting faster and > have not been for several generations. The need for good machine code has > never been more critical. > > > /Charles/ > Sent from a mobile; please excuse the brevity. > > -------- Original message -------- > From: Tom Linden <[email protected]> > Date: 12/25/16 4:54 PM (GMT-05:00) > To: [email protected] > Subject: Re: A not very Christmassy PL/I tale > > Is the PL/I code gen shared with other front-ends? I fear one point you > made is true, viz., the speed of the machine seems to obviate the need to > write a good compiler. This looks pretty amateurish. When machines were > slow, like 40 years ago, we did software engineering, > > On Sun, Dec 25, 2016 at 1:34 PM, Bernd Oppolzer < > [email protected]> > wrote: > > > Cross-posted to the PL/1 list > > > > > > > > Hi Robert, > > > > IMO this is a valid and remarkable observation, but I don't believe that > > anybody in the companies that use PL/1 heavily will take much care of it. > > > > Because: > > > > a) there is no time to analyze the outcome of the compiler in such depth, > > that it could lead to recommendations or requests to IBM for changes > > (I wish, I would get the time to do that) > > > > b) the new machines are so fast that they tolerate this additional load > > which comes from "suboptimal" compilers > > > > c) if comparisons of performance are done, then between subsequent > > releases, but not with compilers that old; most companies will not be > > able to run those comparisons > > > > d) there would be some pressure to act for IBM, if there was some sort > > of competition; but regarding PL/1, there is no competition > > > > Most companies running PL/1 and their IT departments are loaded with > > other requirements and simply have no time to care about performance > > issues; > > > > if they do, they try to repair things locally or improve the logic of > > the application > > or the DB2 side or some other problem areas (there could be many); but > IMO > > no one will look at the outcome of the compiler, under normal > > circumstances. > > > > Another look at the scene: > > > > regarding the competition between PL/1 / mainframe and (for example) > > Java / other platforms, the mainframe normally looks good regarding > > performance, availability and other indicators, in spite of possible > > problems > > of the PL/1 code generator. The mainframe should win this competition, > > but it will probably lose anyway, because of > > > > a) skill problems (specialists are too old, no young people available) > > > > b) IT managers are not aware of or don't like the mainframe platform > > > > That's just my private opinion > > > > Kind regards, > > have a good christmas time > > > > Bernd > > > > > > > > Am 25.12.2016 um 20:40 schrieb Robert Prins: > > > >> Hi all, > >> > >> Apologies for this rant on Christmas day... > >> > >> Let's assume you gate-crash an IBM GSE meeting, way back in 2010 and > >> talk to an IBM developer about optimizing code, and he tells you that > >> IBM is well ahead (by "at least" five years) of the Open Source > >> community! > >> > >> So on this Christmas day you decide, having nothing better to do than > >> to listen to your relatives blabbering away in Lithuanian, the > >> language of your wife of fifteen years, but a language that you still > >> do not speak, to look at some more code emitted by, admittedly not the > >> latest and greatest of IBM's Enterprise PL/I compilers (V4.3.0), and > >> compare that to the code of the long out-of-support V2.3.0 OS compiler. > >> > >> Now, you've already had, more than once, discussions with one of its > >> lead-developers about the quality of code emitted by the EPLI backend > >> after earlier remarks that it looks pretty bad, but with said > >> developer having access to the latest technology, there's little you > >> can put up against his arguments, although a claim that a loop to > >> initialize a PL/I array is faster than using MVC or overlapping MVC on > >> the latest z13 systems still makes you wonder. > >> > >> So in stead, lets look at some very simple PL/I code, a very > >> frequently called routine that calculates average times based on two > >> inputs, seconds and a divisor, which should result in some pretty > >> simple assembler code. > >> > >> Here is the output of the compiler, and lets start with the code > >> generated by the old OS compiler, and for what it's worth, w_hh and > >> w_mm are defined externally as "fixed dec (3)" > >> > >> 3829 AVERAGE_TIME: PROC(SECONDS, N); > >> 3830 DCL SECONDS FIXED DEC (15,6); > >> 3831 DCL N FIXED DEC (5); > >> 3833 DCL D FIXED DEC (9); > >> 3834 DCL S FIXED DEC (15,6) INIT (SECONDS); > >> > >> 3841 W_HH = TRUNC(SECONDS / (N * 3600)); > >> 3842 SECONDS = SECONDS - W_HH * (N * 3600); > >> 3843 W_MM = TRUNC(SECONDS / (N * 60)); > >> 3844 SECONDS = SECONDS - W_MM * (N * 60); > >> > >> And I've added this code, to help the compiler eliminate common > >> sub-expressions, as the V2.3.0 compiler wasn't all that optimizing, > >> especially for large programs, as indicated by these two messages: > >> > >> IEL0919I W 2105 VARIABLES IN PROGRAM. GLOBAL OPTIMIZATION PERFORMED > >> FOR 255 VARIABLES. LOCAL OPTIMIZATION PERFORMED ON REMAINDER. > >> IEL0917I W 1 BLOCK CONTAINS 424 FLOW UNITS. GLOBAL OPTIMIZATION > >> PERFORMED ONLY IN 'DO' GROUPS. > >> > >> 3847 D = N * 3600; > >> 3848 W_HH = TRUNC(S / D); > >> 3849 S = S - W_HH * D; > >> 3850 D = N * 60; > >> 3851 W_MM = TRUNC(S / D); > >> 3852 S = S - W_MM * D; > >> > >> And what comes out, slightly edited (removal of spaces and flowing > >> code on single lines) to show statement and generated code next to > >> each other: > >> > >> 3841 W_HH = TRUNC(SECONDS / (N * 3600)); > >> * STATEMENT NUMBER 3841 > >> 01D7E0 58 40 D 0D4 L 4,212(0,13) > >> 01D7E4 F8 52 D 098 4 000 ZAP WKSP.78+32(6),N(3) > >> 01D7EA FC 52 D 098 8 BDD MP WKSP.78+32(6),3037(3,8) > >> 01D7F0 D2 05 D 128 D 098 MVC 296(6,13),WKSP.78+32 > >> 01D7F6 58 90 D 0D0 L 9,208(0,13) > >> 01D7FA F8 D7 D 098 9 000 ZAP WKSP.78+32(14),SECONDS(8) > >> 01D800 FD D5 D 098 D 128 DP WKSP.78+32(14),296(6,13) > >> 01D806 D2 07 D 12E D 098 MVC 302(8,13),WKSP.78+32 > >> 01D80C 58 70 6 0CC L 7,204(0,6) > >> 01D810 D2 01 7 57C D 131 MVC LIFT_WORK.WT_AVG.W_HH(2),305(13) > >> 01D816 D1 00 7 57D D 135 MVN LIFT_WORK.WT_AVG.W_HH+1(1),309(13) > >> > >> 3842 SECONDS = SECONDS - W_HH * (N * 3600); > >> * STATEMENT NUMBER 3842 > >> 01D81C F8 52 D 098 4 000 ZAP WKSP.78+32(6),N(3) > >> 01D822 FC 52 D 098 8 BDD MP WKSP.78+32(6),3037(3,8) > >> 01D828 D2 05 D 128 D 098 MVC 296(6,13),WKSP.78+32 > >> 01D82E F8 71 D 098 7 57C ZAP WKSP.78+32(8),LIFT_WORK.WT_AVG.W_HH(2) > >> 01D834 FC 75 D 098 D 128 MP WKSP.78+32(8),296(6,13) > >> 01D83A D2 07 D 12E D 098 MVC 302(8,13),WKSP.78+32 > >> 01D840 D2 07 D 098 D 12E MVC WKSP.78+32(8),302(13) > >> 01D846 94 F0 D 09F NI WKSP.78+39,X'F0' > >> 01D84A D7 02 D 0A0 D 0A0 XC WKSP.78+40(3),WKSP.78+40 > >> 01D850 D1 00 D 0A2 D 135 MVN WKSP.78+42(1),309(13) > >> 01D856 FB A7 D 098 9 000 SP WKSP.78+32(11),SECONDS(8) > >> 01D85C F8 7A D 09B D 098 ZAP WKSP.78+35(8),WKSP.78+32(11) > >> 01D862 97 01 D 0A2 XI WKSP.78+42,X'01' > >> 01D866 D2 07 9 000 D 09B MVC SECONDS(8),WKSP.78+35 > >> > >> 3843 W_MM = TRUNC(SECONDS / (N * 60)); > >> * STATEMENT NUMBER 3843 > >> 01D86C F8 42 D 098 4 000 ZAP WKSP.78+32(5),N(3) > >> 01D872 FC 41 D 098 8 91B MP WKSP.78+32(5),2331(2,8) > >> 01D878 D2 04 D 128 D 098 MVC 296(5,13),WKSP.78+32 > >> 01D87E F8 C7 D 098 9 000 ZAP WKSP.78+32(13),SECONDS(8) > >> 01D884 FD C4 D 098 D 128 DP WKSP.78+32(13),296(5,13) > >> 01D88A D2 07 D 12D D 098 MVC 301(8,13),WKSP.78+32 > >> 01D890 D2 01 7 57F D 130 MVC LIFT_WORK.WT_AVG.W_MM(2),304(13) > >> 01D896 D1 00 7 580 D 134 MVN LIFT_WORK.WT_AVG.W_MM+1(1),308(13) > >> > >> 3844 SECONDS = SECONDS - W_MM * (N * 60); > >> * STATEMENT NUMBER 3844 > >> 01D89C F8 42 D 098 4 000 ZAP WKSP.78+32(5),N(3) > >> 01D8A2 FC 41 D 098 8 91B MP WKSP.78+32(5),2331(2,8) > >> 01D8A8 D2 04 D 128 D 098 MVC 296(5,13),WKSP.78+32 > >> 01D8AE F8 61 D 098 7 57F ZAP WKSP.78+32(7),LIFT_WORK.WT_AVG.W_MM(2) > >> 01D8B4 FC 64 D 098 D 128 MP WKSP.78+32(7),296(5,13) > >> 01D8BA D2 06 D 12D D 098 MVC 301(7,13),WKSP.78+32 > >> 01D8C0 D2 06 D 098 D 12D MVC WKSP.78+32(7),301(13) > >> 01D8C6 94 F0 D 09E NI WKSP.78+38,X'F0' > >> 01D8CA D7 02 D 09F D 09F XC WKSP.78+39(3),WKSP.78+39 > >> 01D8D0 D1 00 D 0A1 D 133 MVN WKSP.78+41(1),307(13) > >> 01D8D6 FB 97 D 098 9 000 SP WKSP.78+32(10),SECONDS(8) > >> 01D8DC F8 79 D 09A D 098 ZAP WKSP.78+34(8),WKSP.78+32(10) > >> 01D8E2 97 01 D 0A1 XI WKSP.78+41,X'01' > >> 01D8E6 D2 07 9 000 D 09A MVC SECONDS(8),WKSP.78+34 > >> > >> 3847 D = N * 3600; > >> * STATEMENT NUMBER 3847 > >> 01D976 F8 52 D 098 4 000 ZAP WKSP.78+32(6),N(3) > >> 01D97C FC 52 D 098 8 BDD MP WKSP.78+32(6),3037(3,8) > >> 01D982 D2 04 D 0C0 D 099 MVC D(5),WKSP.78+33 > >> > >> 3848 W_HH = TRUNC(S / D); > >> * STATEMENT NUMBER 3848 > >> 01D988 F8 C7 D 098 D 0B8 ZAP WKSP.78+32(13),S(8) > >> 01D98E FD C4 D 098 D 0C0 DP WKSP.78+32(13),D(5) > >> 01D994 D2 07 D 128 D 098 MVC 296(8,13),WKSP.78+32 > >> 01D99A D2 01 7 57C D 12B MVC LIFT_WORK.WT_AVG.W_HH(2),299(13) > >> 01D9A0 D1 00 7 57D D 12F MVN LIFT_WORK.WT_AVG.W_HH+1(1),303(13) > >> > >> 3849 S = S - W_HH * D; > >> * STATEMENT NUMBER 3849 > >> 01D9A6 F8 61 D 128 7 57C ZAP 296(7,13),LIFT_WORK.WT_AVG.W_HH(2) > >> 01D9AC FC 64 D 128 D 0C0 MP 296(7,13),D(5) > >> 01D9B2 D7 0A D 098 D 098 XC WKSP.78+32(11),WKSP.78+32 > >> 01D9B8 D2 06 D 099 D 128 MVC WKSP.78+33(7),296(13) > >> 01D9BE 94 F0 D 09F NI WKSP.78+39,X'F0' > >> 01D9C2 D1 00 D 0A2 D 12E MVN WKSP.78+42(1),302(13) > >> 01D9C8 FB A7 D 098 D 0B8 SP WKSP.78+32(11),S(8) > >> 01D9CE F8 7A D 09B D 098 ZAP WKSP.78+35(8),WKSP.78+32(11) > >> 01D9D4 97 01 D 0A2 XI WKSP.78+42,X'01' > >> 01D9D8 D2 07 D 0B8 D 09B MVC S(8),WKSP.78+35 > >> > >> 3850 D = N * 60; > >> * STATEMENT NUMBER 3850 > >> 01D9DE F8 42 D 0C0 4 000 ZAP D(5),N(3) > >> 01D9E4 FC 41 D 0C0 8 91B MP D(5),2331(2,8) > >> > >> 3851 W_MM = TRUNC(S / D); > >> * STATEMENT NUMBER 3851 > >> 01D9EA F8 C7 D 098 D 0B8 ZAP WKSP.78+32(13),S(8) > >> 01D9F0 FD C4 D 098 D 0C0 DP WKSP.78+32(13),D(5) > >> 01D9F6 D2 07 D 128 D 098 MVC 296(8,13),WKSP.78+32 > >> 01D9FC D2 01 7 57F D 12B MVC LIFT_WORK.WT_AVG.W_MM(2),299(13) > >> 01DA02 D1 00 7 580 D 12F MVN LIFT_WORK.WT_AVG.W_MM+1(1),303(13) > >> > >> 3852 S = S - W_MM * D; > >> * STATEMENT NUMBER 3852 > >> 01DA08 F8 61 D 128 7 57F ZAP 296(7,13),LIFT_WORK.WT_AVG.W_MM(2) > >> 01DA0E FC 64 D 128 D 0C0 MP 296(7,13),D(5) > >> 01DA14 D7 0A D 098 D 098 XC WKSP.78+32(11),WKSP.78+32 > >> 01DA1A D2 06 D 099 D 128 MVC WKSP.78+33(7),296(13) > >> 01DA20 94 F0 D 09F NI WKSP.78+39,X'F0' > >> 01DA24 D1 00 D 0A2 D 12E MVN WKSP.78+42(1),302(13) > >> 01DA2A FB A7 D 098 D 0B8 SP WKSP.78+32(11),S(8) > >> 01DA30 F8 7A D 09B D 098 ZAP WKSP.78+35(8),WKSP.78+32(11) > >> 01DA36 97 01 D 0A2 XI WKSP.78+42,X'01' > >> 01DA3A D2 07 D 0B8 D 09B MVC S(8),WKSP.78+35 > >> > >> L : 3 > >> ZAP : 18 > >> MP : 10 > >> MVC : 23 > >> DP : 4 > >> MVN : 8 > >> NI : 4 > >> XC : 4 > >> XI : 4 > >> SP : 4 > >> --- > >> 82 instructions, 470 bytes of code > >> > >> And obviously common-subexpression elimination didn't make it, or, as > >> the above messages indicated, the source was simply too complex, this > >> is a procedure in a 13+K lines PL/I program. > >> > >> Jump forward two (or even more) decades to 2014-03-10, the version of > >> Enterprise PL/I V4.3.0 on the system where this test was done, and weep? > >> > >> 11200.0 average_time: proc(seconds, n); > >> 11201.0 dcl seconds fixed (15,6); > >> 11202.0 dcl n fixed (5); > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
