|Decades of compiler technology and what do we get? email@example.com (Robert AH Prins) (2012-04-22)|
|Re: PL/I nostalgia, was Decades of compiler technology and what do we firstname.lastname@example.org (glen herrmannsfeldt) (2012-04-23)|
|Re: PL/I nostalgia email@example.com (robin) (2012-04-25)|
|Re: PL/I nostalgia firstname.lastname@example.org (glen herrmannsfeldt) (2012-04-24)|
|Re: PL/I nostalgia email@example.com (robin) (2012-04-28)|
|Re: PL/I nostalgia firstname.lastname@example.org (glen herrmannsfeldt) (2012-04-28)|
|Re: PL/I nostalgia bobduff@shell01.TheWorld.com (Robert A Duff) (2012-04-29)|
|Re: PL/I code email@example.com (robin) (2012-05-05)|
|Re: PL/I code firstname.lastname@example.org (glen herrmannsfeldt) (2012-05-05)|
|Re: Fortran calls, was PL/I code email@example.com (glen herrmannsfeldt) (2012-05-06)|
|Re: Archaic hardware (was Fortran calls) firstname.lastname@example.org (robin) (2012-05-09)|
|Re: PL/I nostalgia email@example.com (robin) (2012-09-19)|
|[4 later articles]|
|From:||glen herrmannsfeldt <firstname.lastname@example.org>|
|Date:||Sat, 28 Apr 2012 16:11:07 +0000 (UTC)|
|Organization:||Aioe.org NNTP Server|
|References:||12-04-070 12-04-077 12-04-081 12-04-082 12-04-084|
|Posted-Date:||28 Apr 2012 14:11:31 EDT|
robin <email@example.com> wrote:
(big snip, then I wrote)
>> 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.
> All that's irrelevant.
There is, at least, more overhead in the procedure entry/exit
sequence for recursive routines. Now, since PL/I also has the
RECURSIVE attribute the compiler could generate different code
in the non-recursive case.
OK, to get an actual compiler question into the discussion,
are there any compilers that generate non-reentrant code for
a language that allows recursion when it isn't being used?
> Furthermore, the necessity in FORTRAN of having all storage
> as static meant that programs employing large arrays or lots of
> arrays used the processor inefficiently in that the
> executable programs tied up more memory than was necessary.
> Compared to PL/I, which provides dynamic arrays, considerably
> less run-time memory was required.
That is true. For a single task system, like many before OS/360 and
like OS/360 PCP on smaller system, though, if it fits there isn't much
cost to the wasted memory.
> [In case it is thought from the above that PL/I provides only
> dynamic arrays, may I point out that PL/I provides dynamic
> and static arrays, as well as controlled arrays.]
I probably lost the thread that the comment was supposed to apply to.
In a called procedure, it doesn't matter how the original array was
allocated, it is referenced through the dope-vector (call by
In the case of a local array, the compiler can make some optimizations
that it can't make for a procedure argument.
Fortran 90 added assumed shape arrays, where the called array gets the
shape, most likely through a descriptor similar to that from PL/I. In
traversing an array through a descriptor, it isn't so easy to convert
to a single loop.
Through Fortran 77, the array passing method now called assumed size
was usually used. A common way to use assumed size in Fortran was for
the called routine to declare the argument as rank one and do all the
index calculations internally.
Now, as Robin mentioned PL/I often made it easier to write correct
programs. Processing a matrix through a rank one array is more
difficult to get right.
>> 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
> That's relative, and in any case irrelevant.
> Machines were much faster in 1966 compared to 1956.
There is still much discussion on comp.lang.fortran on the speed
difference between array expressions and explicit DO loops.
>>> 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.
> You're wrong on both counts. The hardware was late. All the
> compilers were late. The code from IBM's PL/I was just as good as
> from IBM's Fortran compilers on the machine that we had. I still have
> the results somewhere of test runs in FORTRAN and PL/I. It was the
> link editor that took longer with PL/I than with FORTRAN.
Certainly the link editor was always slow. If one wrote the same
program in PL/I, the result might be close to that from Fortran.
If one started using many of the PL/I features, though, it was very
easy to get a much slower program. One might, for example, use FIXED
DECIMAL variables that require conversion to binary when used as array
subscripts. That is, at least, one problem that OS/360 Fortran
programmers never had.
> I should have been more explicit. Code generation from IBM's
> FORTRAN compilers on the machine that we had was reasonably
> efficient too.
> What is just as important is what happens when a program runs.
> FORTRAN programs often halted (division by zero, floating-point
> overflow) without any indication of where or why they halted.
OS/360 Fortran has a nice traceback feature. I don't know when it was
added, though. On the other hand, in the fairly common branch to a
non-existing address, both Fortran and PL/I left you lost.
> One published account (D. J. Kewley, "A Comparison between
> Pascal, FORTRAN, and PL/I", ACJ, Feb. 1981, pp 27-8)
> claimed that Pascal was faster than PL/I,
> and the author produced timing figures to "prove" it.
> The author failed to specify the PL/I option "REORDER" that would
> permit optimisation to take place. Furthermore, he compared
> one Pascal program performing complex arithmetic, with a PL/I
> program doing the same. Not supporting complex arithmetic,
> the Pascal program simulated those operations. When the PL/I
> version was rewritten using complex arithmetic,
> and with the REORDER option on the PROCEDURE statement,
> a 47% increase in speed was obtained. (see my refutation, ACJ,
> Aug. 1981, p. 107)
> FORTRAN programmers tended to mimic FORTRAN style in
> their PL/I code that was inappropriate in PL/I.
> That caused PL/I programs to run slower than they should have.
>> In some cases you can do that, but it isn't so easy in a subroutine,
>> when the array might not be contiguous.
> IIRC, in IBM's F-compiler, elements in arrays were contiguous,
> even in subroutines. [Even were that not so, a single loop suffices.]
PL/I allows array cross sections that can be non-contiguous.
I believe some Fortran compilers now generate a test for a contiguous
array and then different code to process the two cases. As far as I
know, no PL/I compilers do that. (Then again, I haven't looked that
>> 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.
> That's their choice.
That is true. Still, people seem to like doing it.
>> PL/I only supports call-by-descriptor for arrays and strings.
>> That is good, but has more overhead.
> Than what? Not having descriptors?
> Descriptors are necessary to deal with dynamic arrays.
> Without descriptors, it would be back to pre-Fortran 90,
> where only the address of the first element of an array was
> typically passed.
The generated code to process assumed size arrays is often faster than
assumed shape. In many cases it is a worthwhile tradeoff on today's
>>> [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.
> That those early dates slipped is irrelevant, as the S/360 wasn't
> even announced until 1964. In any case, a slippage by a few months
> was unimportant.
From that description, they had four months. With the earlier
deadline, they would have had to have most of it done in two months.
For a language as complicated as PL/I, that isn't much time at all.
> [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]
As long as you don't use too many fancy PL/I features, that should be
true. Of course you didn't have those features in Fortran IV. There is
a tendency to try out new features of a new language, though.
[I got some astonishingly awful code when I tried to use an array of
12 bit fields. As I recall, the code converted the fields to decimal
and back, for reasons I could not begin to guess. Also, looking at the
manuals in Bitsavers, they were still adding features and
optimizations to PL/I F at least as late as 1968. -John]
Return to the
Search the comp.compilers archives again.