Re: PL/I code

glen herrmannsfeldt <>
Sat, 5 May 2012 05:20:56 +0000 (UTC)

          From comp.compilers

Related articles
Decades of compiler technology and what do we get? (Robert AH Prins) (2012-04-22)
Re: PL/I nostalgia, was Decades of compiler technology and what do we (glen herrmannsfeldt) (2012-04-23)
Re: PL/I nostalgia (robin) (2012-04-25)
Re: PL/I nostalgia (glen herrmannsfeldt) (2012-04-24)
Re: PL/I nostalgia (robin) (2012-04-28)
Re: PL/I nostalgia (glen herrmannsfeldt) (2012-04-28)
Re: PL/I code (robin) (2012-05-05)
Re: PL/I code (glen herrmannsfeldt) (2012-05-05)
Re: Fortran calls, was PL/I code (glen herrmannsfeldt) (2012-05-06)
Re: Archaic hardware (was Fortran calls) (robin) (2012-05-09)
| List of all articles for this month |

From: glen herrmannsfeldt <>
Newsgroups: comp.compilers
Date: Sat, 5 May 2012 05:20:56 +0000 (UTC)
Organization: NNTP Server
References: 12-04-070 12-04-077 12-04-081 12-04-082 12-04-084 12-04-085 12-05-004
Keywords: PL/I, history, code, comment
Posted-Date: 05 May 2012 23:43:02 EDT

robin <> wrote:

>> There is, at least, more overhead in the procedure entry/exit
>> sequence for recursive routines.

> More overhead, maybe, but how much more? Registers usually have to be
> saved, a return address has to be preserved somewhere. When the
> machine has a stack, those things can go on the stack. There appears
> to be no extra overhead. When the machine does not have a hardware
> stack, one must be simulated, or, space must be made available for
> saving those things, at each recursive call. In that case, a request
> from the OS may need to be made for the storage. The request will add
> to overhead. But again, how much extra?

For the PDP-10/TOPS-10 Fortran, return addresses went on the stack,
but local variables were still static, as usual for Fortran IV.

OS/360 Fortran compilers use static storage for local variables and
save areas (including the return address). No overhead for allocation.


>> In the case of a local array, the compiler can make some optimizations
>> that it can't make for a procedure argument.


> In Fortran (90 or later), the descriptor holds, or can hold,
> the stride value. Thus, a called procedure can access
> non-contiguous elements in a single loop.


>> PL/I allows array cross sections that can be non-contiguous.

> The elements in a cross-section are contiguous for rows,
> but not for columns (in a matrix). However, the elements are
> separated from each other by a constant amount, so a single loop
> suffices (as you would expect, because only one subscript varies).

I suppose for a 2D array the elements will have a constant stride,
but not for a higher D array.

-- glen
[That must be the new PDP-10 compiler. The old compiler, which looked
a whole lot like OS/360 Fortran G, used JSA/JRA for subroutine calls,
which saved the return address register in the first word of the
subroutine. -John]

Post a followup to this message

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