Re: PL/I nostalgia

robin <robin51@dodo.com.au> wrote:


(snip, I wrote)
>>It has always seemed to me that PL/I would have been more successful
>>if the early compilers generated faster code (and ran faster, too).


(previous snip on I/O bound COBOL, and not worrying about CPU time.)


>>It might have been that too much of the above was adopted, along with
>>other COBOL features, by PL/I. There are many things that other
>>languages, such as Fortran, traditionally didn't let you do, because
>>they might run too slow, but that PL/I allowed.


> FORTRAN was developed by 1956.
> PL/I was developed by 1966.
> In the decade after 1956, many deficiencies had been identified
> in FORTRAN; some of its statements were pretty crude.


This is true, but not so important for this question.


Fortran didn't allow for recursion until 1990, and even then you had
to have the RECURSIVE attribute. Compilers could still generate
non-recursive code without the attribute.


There is overhead to the calling sequence to allow for recursion, at
least on most systems. It was usual for Fortran compilers to use
static allocation through Fortran 77. (Some rules were written
specifically to allow for it.) On machines without a call stack, there
is also overhead for that, in addition to local variable allocation.


Even more for PL/I, the ability to do multi-tasking adds more
complications that have more overhead.


> Similar comments may be made about COBOL.


As noted, this was in response to a suggestion that COBOL programs
were I/O bound, and so there was less need for CPU time optimization.


On the other hand, I/O optimizations such as locate mode I/O would
have been more important for COBOL.


> While some features of both FORTRAN and COBOL were adopted
> in PL/I, many new features were added, including (but not
> limited to) recursive procedures and dynamic allocation
> (already in Algol).


> Of those features adapted from the older languages, arbitrary
> restrictions were removed, making it much easier to write programs.


And much easier to write slow programs. Simple PL/I expressions can
require temporary arrays. (Usually with a warning message.)


That didn't happen to Fortran until 1990, when machines were much
faster.


> One other point is that the size of machines had increased
> significantly in that early decade, permitting more language
> features to be incorporated in PL/I.


But the window was fairly small. IBM had originally expected to
replace Fortran (and maybe COBOL) with PL/I. The compiler arrived
late, ran slow, and generated much slower code.


> PL/I can be considered to be the first general-purpose language.


> As to code generation of the early PL/I compilers, that code
> was reasonably efficient.


For many scientific problems, reasonably isn't enough.


> I would agree, however, there were certain situations where much
> faster code could have been generated, but that opportunity was
> not taken.


> I refer to operations involving whole arrays or array sections.
> For instance, where an operation involved a whole array,
> IBM's first compiler, PL/I-F, could have optimised a matrix statement
> (trivial example, A=B; where all elements of A and B are accessed)
> to a single loop, instead of the two equivalent loops that were actually used:
> do i = 1 to m;
> do j = 1 to n;
> A(i,j) = B(i,j);
> end;
> end;


In some cases you can do that, but it isn't so easy in a subroutine,
when the array might not be contiguous.


Also, since array operations were added to Fortran, they are one of
the biggest causes for complaints about slow programs.


One reason is that people sometimes write array expressions that
require much more computation than they would written as loops.


PL/I only supports call-by-descriptor for arrays and strings. That is
good, but has more overhead. For today's machines, that isn't so bad,
but on slower machines in the early days, it may have been too much.


> Four years later, IBM produced their Optimising Compiler and
> Checkout Compiler (c. 1970).


>>(Many of those have now been added to Fortran.)


> Some have, but others have not.
> For example, recent discussion in comp.lang.fortran evolved
> around a suitable Fortran procedure to convert an integer to a string.


> In PL/I, it requires a simple statement, s = i;


It is one of the fun features of PL/I, but not so often needed in
production programs.


I do remember in high-school writing a PL/I DO loop with CHAR
variables for the DO variable, and the start, end, and increment value.
(It is slightly interesting, as a string compare is used in
the loop test.)


> [Considering what a rush job PL/I was, it's a remarkably good
> language. -John]


I didn't know about that until recently when I bought "History
of Programming Languages", edited by Richard L. Wexelblat, which
covers the timeline for the PL/I language specification. (Writing
the actual compiler was a separate timeline.)


As well as I can tell, it was October 1963 that the decision to
design a new language, instead of going to Fortran VI, was final,
and the group formed to write the specification. They were told
that it needed to be done by December 1963. In December, it was
extended to January 1964, and then slipped to February.


Then there is the comment:


    "While this can never be proven, it is clear that much of the
      long and demanding work in PL/I language development would have
      been made much easier ahd the designing committee been given
      six months or a year at the beginning to lay down a carefully
      defined language base."


I wonder how much time has now been spent by committees working
on the Fortran standard.


-- glen

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