c400-l-bounces+blairw=us.ibm.com@xxxxxxxxxxxx wrote on 11/16/2004 07:35:06
PM:

> Is there any documentation or explanation of the Application Binary
> Interface (ABI), or equivalent, when in native mode (non-PASE)?
>
> I want to be able to determine how parameters are passed and where they
> are located in memory when one C function calls another (a "static
> procedure call", I believe) which would cover both intra-program calls
> and inter-program (*PGM to *SVRPGM) calls.

The pass-by-value semantics of C language are the overriding specification
here.  Since C is pass-by-value, and since C supports variable-length
argument lists, "programmable" access to parameter storage is a required
part of the language itself.  (Consider the venerable printf(const char*,
...) -- it's that ellipsis ... that says it all.  :-)

The <stdarg.h> standard C header file contains the relevant prototypes for
getting to your argument storage.  Routines have names like:
      va_start
      va_list
      va_end
      va_arg


> The V5R3 ILE Concepts manual explains the use of call stacks which is
> how it all appears to happen, but there doesn't seem to be a way to
> access these directly from within C.

This is where stdarg.h comes into play...

>
> I'm using teraspace-enabled programs so pointers are 8-bytes rather
> than 16-byte tagged pointers, if that matters.

Just a nit, but being teraspace-enabled doesn't use 8-byte pointers, it
just allows and tolerates them.  To use 8-byte pointers everywhere, I'm
guessing you're using teraspace storage model with data model LLP64.

HTH.

-blair

  ___   _           Blair Wyman                  IBM Rochester
 ( /_)  /  _  ' _   (507)253-2891            blairw@xxxxxxxxxx
__/__)_/_<_/_/_/_'  Opinions expressed may not be those of IBM





This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].