Re: PL/I code

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


(snip)
>> 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.




(snip)


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


(snip)


> 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.


(snip)


>> 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]

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