Re: Direction of Stack Growth - Embedded

This is a discussion on Re: Direction of Stack Growth - Embedded ; On Oct 23, 3:05 am, glen herrmannsfeldt wrote: > Nick Maclaren wrote: > > (snip) > > > Witness that System/360 stacks were normally upwards growing in the > > 1960s and 1970s, and changed as the new generation of ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Direction of Stack Growth

  1. Re: Direction of Stack Growth

    On Oct 23, 3:05 am, glen herrmannsfeldt wrote:
    > Nick Maclaren wrote:
    >
    > (snip)
    >
    > > Witness that System/360 stacks were normally upwards growing in the
    > > 1960s and 1970s, and changed as the new generation of people with a
    > > DEC background moved in during the 1980s.

    >
    > The S/360 that I used, running OS/360 and descendants, used
    > linked lists for subroutine calling, register saving, and
    > argument lists.


    I am eager to understand more about this.
    Linked lists for subroutine calling.
    Is it a good method or a bad method of design ?
    Where can i get more information about this ?

    >
    > I haven't looked at what Linux/390 does, though.
    >


    What does linux follow/390 do ?
    Where can i get more information about this ?

    Thx in advans,
    Karthik Balaguru


  2. Re: Direction of Stack Growth

    On Oct 23, 12:10 pm, karthikbalaguru
    wrote:
    > On Oct 23, 3:05 am, glen herrmannsfeldt wrote:
    >
    > > Nick Maclaren wrote:

    >
    > > (snip)

    >
    > > > Witness that System/360 stacks were normally upwards growing in the
    > > > 1960s and 1970s, and changed as the new generation of people with a
    > > > DEC background moved in during the 1980s.

    >
    > > The S/360 that I used, running OS/360 and descendants, used
    > > linked lists for subroutine calling, register saving, and
    > > argument lists.

    >
    > I am eager to understand more about this.
    > Linked lists for subroutine calling.
    > Is it a good method or a bad method of design ?
    > Where can i get more information about this ?



    The standard S/360 calling convention used a liked list of register
    save areas. Mind you that this was designed before languages with
    small subroutines and default external linkage became popular, so this
    was really intended for a fairly heavyweight program to program call,
    and is not a particularly good design by today's standards, and the
    convention was almost never followed by compilers (or assembler
    programmers) within a program, just at the external calls and entries.

    In short, ever program was responsible for allocating a 18 word save
    area for the callee to use. During a call, R1 pointed to a list of
    pointers, one for each parameter (everything was pass by reference),
    with the high bit set on the last pointer. Optionally, R1 might point
    directly to a single parameter, but this was rare (usually it was just
    R1 pointing to a single pointer).

    R13 pointed to the register save area from the caller (R15 was the
    called address, R14 the return). The called program would save
    registers in the passed save are, typically with a "STM
    R14,R12,12(R13)", which would store R14, R15, R0..R13 staring in the
    fourth word of the save area. The called program would then allocate
    a new save area, and store the address of the prior save area in the
    second word of the new area. That second word is how you did the
    "pop" to get back to the caller. The other two words in the save area
    had uses in some cases, but in most programs were ignored.

    See chapter 2 of:

    http://publibz.boulder.ibm.com/cgi-b...20070426031033

    If you wanted to do a linked list of activation records today, you'd
    do it a bit differently, and you'd almost certainly have something
    that looked a lot like a conventional stack allocated activation
    record, just allocated from the heap. Perhaps something like:

    +0 : back link
    +4 : return address
    +8 : local variable area for callee
    +n : parameters (after local area)

    In that scheme, the called routine needs to publish not just its entry
    point, but the required size of its local area.

    This obviously has some overhead, namely the allocation of the
    activation record from the heap rather than the trivial allocation
    done by adding (or subtracting) to the stack pointer. OTOH, some of
    that can be optimized fairly easily. For example, if you know , or
    can limit, the size of the activation record(s) needed by a second
    level callee, the caller can just preallocate it inside the first
    callee's activation record. Obviously things like recursive routines
    need to not do that sort of thing. Pool allocators might also work
    well in many cases, especially since most activation records are
    fairly small.

    An interesting benefit of the linked list approach is that it does not
    have the problem of consuming large quantities of address space with
    unused stack, which eliminates one of the major problems with the
    thread-per-connection approach to servers (there are others, but
    that's a biggie).


    > > I haven't looked at what Linux/390 does, though.

    >
    > What does linux follow/390 do ?
    >
    > Where can i get more information about this ?



    On zLinux (64 bit) or Linux/390 (31 bit), it's more like the
    conventional C-like calling conventions you see on other platforms,
    although a little weird.

    There's a downward growing stack, pointed to by R15, and a defined
    stack frame format (basically there's a back chain, some preallocated
    register save areas in which the callee can save callee save
    registers, if necessary), and then the usual local and parameter
    areas. R14 is the return address (and is one of the callee regs).
    The first five integer parameters are passed in R2..R6, the fisrt two
    FP parms in F0 and F2 (for zLinux it's four FP parms in F0, F2, F4,
    F6), return in R2 or F0. With some fairly conventional special
    handling for structures, and whatnot. There are some other minor
    differences between the 31 and 64 bit platforms (for example, 64 bit
    parameters are passed in single registers in zLinux, in register pairs
    in Linux/390).

    Starting at about page nine of:

    http://www.tachyonsoft.com/s8139db.pdf


+ Reply to Thread