One of the arguments for making PL/X available to customers who are willing to pay for it is that doing so would give IBM an economic incentive to fix some of its deficiencies.
Some of these deficiencies of course reflect its history. PL/S had a notoriously fertile generate facility that permitted assembly language to be dropped into source programs. This facility was 'abused' by some IBM and contractor programmers to write routines that were, in effect, assembly-language cakes with some PL/X powdered sugar sprinkled on them. The cross-platform emphasis in PL/X discourages and was intended to discourage this sort of thing; but optimizing machinery, less important in PL/S because resort to assemb ly language was possible, does not appear to be much used by PL/X. (Even such obvious things as moving common subexpressions out of loops and suppressing redundant subscript arithmetic don't seem to happen.) IBM knows and has always known how to fix this problem; what has been|is lacking is the will to do it. --jg On 1/17/12, Paul Gilmartin <[email protected]> wrote: > On Jan 17, 2012, at 10:07, Edward Jaffe wrote: >> >> The PL/X compiler also generates 'poor' code. (It's one reason it's been >> difficult to convince the 'powers that be' to establish a new >> Architectural >> Level Set for z/OS.) >> > The balance between cost of development and cost of execution may > be biased when the vendor pays for one and the customer for the other. > >> IBM has hinted that they plan to address these compiler deficiencies--when >> is >> anybody's guess. But, at least they admit there's a problem. That's the >> first >> step... > > > On Jan 17, 2012, at 10:11, John Gilmore wrote: >> >> The IBM optimizing machinery for C/C++ and PL/I is now shared, the >> same for both compilers; and the effects of this sharing have been >> mixed, mostly good and some few of them very bad. > > Sounds like an opportunity for PL/X to join the party. > > How's Metal/C? > > -- gil > -- John Gilmore, Ashland, MA 01721 - USA
