Re: Recursive Call

On IBM mainframes there was/is a standard linkage convention to be followed
that uses a standard 18 fullword save area and certain standard register
usage conventions. Register 15 contains the "branch to" address and Register
14 contains the "Return address". So to "call" another program you would do
something like:

L R15,=V(MYSUBRTN)
BALR R14,R15

Another part of this linkage convention is that the calling program provide
within its storage an 18 fullword save area that the subroutine can use to
save the callers registers. The standard is that Register 13 will point to
this save area at entry to the subroutine. The save areas themselves
contain standard offsets where the register contents are saved plus there
are forward/backward pointers that chain the save areas together into a
linked list stack. Usually the first thing a subroutine does is save the
caller's registers and set register 13 to point to it's save area. When an
abend occurs a save area trace is produced in the dump and shows the call
chain. In assembly language there are SAVE and RETURN macros and the RETURN
macros has an option that can be used to set a bit in the save area to
indicate to the dump program that a save area is no longer active. When a
subroutine ends it restores the callers registers and branches to the return
address.

Of course all of the above was the original convention. As IBM hardware and
addressing modes have evolved there are more/different linkage instructions
and branching instructions. Some of these use a linkage stack area and
there are instructions that are used to access and manipulate it. Some work
with 31-bit addressing and others work with 64-bit addressing. With 64 bit
addressing the save area layout had to be modified to accommodate the larger
addresses and larger/wider registers.

This is a pretty standard process for all the machines that I have worked on
and each has it standard entry/exit magic instruction sequences to
accomplish this. Also not mentioned, there is usually a standard way to
pass parameters to the subroutine. I believe that on the IBM mainframe COBOL
follows the convention when subprograms are CALLed.

"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:dl2hl00kku@xxxxxxxxxxxxxxxxxxxx
>
> In article <dktc9l$169$1@xxxxxxxxxxxxxxxxx>, docdwarf@xxxxxxxxx () writes:
>>
>> The fellow with whom I was conversing mentioned use of the stack-trace in
>> debugging; I said that this was not, in my experience, a common method
>> applied to IBM-architecture mainframes. I based this on my experience as
>> a mere apps-jockey; when something blows up I look for the PSW, find the
>> address of the previous statement and proceed from there.
>>
>> This ignores - in the radical sense of 'in (not) gnosis' - what folks at
>> the systems level do. Is there something akin to stack tracing done on
>> Big Blue Big Iron running 'classic' (COBOL/CICS/DB2) systems?
>
> I was curious to see answers to this, but it doesn't appear that you've
> had any takers.
>
> I've not done much debugging of mainframe systems-level code, but the
> folks I've seen do it generally start with a dump, and do sometimes
> manually backtrack through subroutine calls. These programs were
> mostly written in assembly, and they used some variant of BAL (branch
> and link) for subroutine calls, and maintained their own scratch
> areas for return addresses, parameters, and so forth. So there was
> no contiguous "stack" as there is on x86 and the like, but they did
> sometimes trace the flow of execution back using the dump.
>
> --
> Michael Wojcik michael.wojcik@xxxxxxxxxxxxxx
>
> Auden often writes like Disney. Like Disney, he knows the shape of
> beasts --
> (& incidently he, too, might have a company of artists producing his
> lines) --
> unlike Lawrence, he does not know what shapes or motivates these beasts.
> -- Dylan Thomas


.

Relevant Pages

  • VMI Interface Proposal Documentation for I386, Part 5
    ... to three register arguments. ... of the native instruction set. ... Most of these calls behave as standard C functions, and as such, may ... clobber registers EAX, EDX, ECX, flags. ...
    (Linux-Kernel)
  • Re: Design ASM routine to be called from C
    ... For most of the register which is used ... > convention that the Microsoft platform also follows. ... POSIX standard about what register usage is or should be on 32-bit x86 ... UNIX existed long before the original 8086, ...
    (comp.lang.asm.x86)
  • Re: Design ASM routine to be called from C
    ... > Hi, from the PC Assembly Language document written by Paul, I was ... > " C assumes that a subroutine maintains the values of EBX, ESI, EDI, ... For most of the register which is used ... There is no ANSI C standard for register usage in C. ...
    (comp.lang.asm.x86)
  • Re: multiple threads and volatile
    ... Yet the standard tries to guarantee that your code will work. ... ensured to be copied from memory to register, ... threads conceptual machine nor the POSIX threads conceptual machine ...
    (comp.programming.threads)
  • Re: [PATCH] Generic platform device IDE driver
    ... It's likely that ARM will switch over to using the MMIO resources if ... or we can simply have an element for the spacing interval if you ... Here's the decision matrix for libata: Will the hardware use the standard taskfile push/pull functions like ata_tf_load, ata_tf_read, ata_exec_command, etc.? ... If the hardware requires non-standard I/O accessors, or the register sizes themselves changed, then you must implement your own taskfile I/O ...
    (Linux-Kernel)