Re: PL/I nostalgia

robin <robin51@dodo.com.au> wrote:
> From: "glen herrmannsfeldt" <gah@ugcs.caltech.edu>
> Sent: Wednesday, 19 September 2012 1:56 PM


>> robin <robin51@dodo.com.au> wrote:
>>>> [The code fron PL/I F was comparablw to Fortran G, but much worse than
>>>> Fortran H. The PL/I optimizing compiler's code was better, but still
>>>> not as good as Fortran H and its descendants. -John]


>> Well, the dynamically allocated variables and save areas for PL/I are
>> naturally slower than static allocated Fortran IV.


> But not where it counts. By the time some procedure (such as INVERT)
> is called, the array(s) has(have) been allocated. Allocation is a
> once-off task, probably not measurable in terms of time.


That comment was before the matrix inversion discussion,
and is meant more generally.


Yes, if you are careful with your allocations, and minimize
subroutine calls, then it isn't so bad.


Current coding practices encourage more and smaller procedures
than were usual in the early PL/I days.


> And the FORTRAN IV code was, essentially, rigid, and required
> re-compilation for larger arrays.


For single task systems, most often the memory wouldn't be used
for anything else, but, yes, it is convenient to dynamically
allocate to the appropriate size. It is especially useful
for multitasking systems.


>> Also, many PL/I features naturally don't optimize as well as Fortran.


> That may be so, but to have to re-compile the FORTRAN code to deal
> with larger-sized arrays counted strongly against it. As well, PL/I
> offered full roll-out of fixed-size array operations Not all arrays
> needed to be dynamic. As well as that, PL/I offered such things as
> double precision complex, string-handling, and error recovery.


IBM Fortran has had COMPLEX*16 about as far back as PL/I, but most
others didn't. (Though the most common use for COMPLEX, the FFT,
is most often written using REAL arrays.)


Compilers I know of have the overhead needed for RECURSIVE, even
when the attribute isn't used. But again, minimize the number
of procedure calls and it isn't so bad.


> Error recovery more than compensated for any difference in speed that
> may have existed between FORTRAN and PL/I. Having to re-run FORTRAN
> code because of some error to find out what went wrong outweighed any
> speed advantage that FORTRAN might have had, because in PL/I, the
> error information was already there (including values of variables),
> and without necessarily a program termination. Hence, a re-run of the
> PL/I code was avoided.


Pretty program dependent, but, yes, PL/I can make it easier.


On the other hand, keeping track of ON units through procedure
calls is another increase in the time needed for a call.


> That was important, not only in terms of
> machine time, but also in terms of turn-around time, because
> turn-around time in those days was as much as a week.


>> Finally I have to hand Tucker's "Programming Languages".


>> I have one of those. Not my favorite, but not bad.
>> "History of Programming Languages" is better.


>>> Case study 2, matrix inversion with 20 x 20 data:


>> What page is that on?


> Look in the index.


Might have gone away for the 2nd edition.


(snip)


> 20 W 20 is more than large enough.
> It's the size of a typical matrix in a typical job.


Pretty small for many problems, but then most bigger than
that should be done in ways other than inversion, such
as LU decomposition.


-- glen
[Even in single task systems, dynamic allocation is useful
since it means that variables only take up space when a
routine is active. The Fortran version of that was overlays,
which were a lot klunkier. -John]

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