|Decades of compiler technology and what do we get? firstname.lastname@example.org (Robert AH Prins) (2012-04-22)|
|Re: PL/I nostalgia, was Decades of compiler technology and what do we email@example.com (glen herrmannsfeldt) (2012-04-23)|
|Re: PL/I nostalgia firstname.lastname@example.org (robin) (2012-04-25)|
|Re: PL/I nostalgia email@example.com (glen herrmannsfeldt) (2012-04-24)|
|Re: PL/I nostalgia firstname.lastname@example.org (robin) (2012-04-28)|
|Re: PL/I nostalgia email@example.com (glen herrmannsfeldt) (2012-04-28)|
|Re: PL/I code firstname.lastname@example.org (robin) (2012-05-05)|
|Re: PL/I code email@example.com (glen herrmannsfeldt) (2012-05-05)|
|Re: Fortran calls, was PL/I code firstname.lastname@example.org (glen herrmannsfeldt) (2012-05-06)|
|Re: Archaic hardware (was Fortran calls) email@example.com (robin) (2012-05-09)|
|From:||glen herrmannsfeldt <firstname.lastname@example.org>|
|Date:||Sat, 5 May 2012 05:20:56 +0000 (UTC)|
|Organization:||Aioe.org 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 <email@example.com> 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.
[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
Return to the
Search the comp.compilers archives again.