Topic
3 replies Latest Post - ‏2010-12-09T16:13:45Z by KirkWolf
KirkWolf
KirkWolf
8 Posts
ACCEPTED ANSWER

Pinned topic CCN8806 with OS_DOWNSTACK in _LP64 mode

‏2010-12-08T17:49:18Z |
An XPLINK 64 assembler routine that uses CELQPRLG can be called from C++ (xplink, _LP64) using this:

extern "OS_DOWNSTACK" {
int32_t MYROUTINE(...);
}

And this is what the documentation in the C++ programmers guide suggests.

When you compile you get:

CCN8806 (W) The linkage specifier "OS_DOWNSTACK" is not supported in the current context.

But it works.

If you change "OS_DOWNSTACK" to extern "C" then it crashes, so I don't see an alternative other than to put up with this error message.

Thanks for any suggestions.
Updated on 2010-12-09T16:13:45Z at 2010-12-09T16:13:45Z by KirkWolf
  • SystemAdmin
    SystemAdmin
    196 Posts
    ACCEPTED ANSWER

    Re: CCN8806 with OS_DOWNSTACK in _LP64 mode

    ‏2010-12-08T18:45:19Z  in response to KirkWolf
    Since 64 bit code supports only the XPLINKage convention, in theory there's no reason to specify "OS_DOWNSTACK", and hence the warning message. But it's crashing, so there is a problem somewhere....

    My only suggestion is to run the program with dbx, let the program crash and then see which instructions/registers are causing the problem and take it from there.
  • SystemAdmin
    SystemAdmin
    196 Posts
    ACCEPTED ANSWER

    Re: CCN8806 with OS_DOWNSTACK in _LP64 mode

    ‏2010-12-09T15:45:16Z  in response to KirkWolf
    When you write your code in assembler using CELQPRLG+CELQEPLG you effectively are creating an XPLINK 64-bit function. Therefore the function should be considered an XPLINK function and there is no need to identify it as OS_DOWNSTACK in your C/C++ code. This is the reason the warning message was issued.

    However, the compiler does react to OS_DOWNSTACK in an undesirable way for constructing the calling code. The undesirable part is that the compiler will construct a by-reference parameter list in an OS linkage fashion and loads the first 3 words in GPR1 - GPR3.
    Check if your assembler code relies on this undesirable way of passing the parameters. If it does, we suggest you modify your assembler code to receive the arguments in a true XPLINK fashion.
    If this "int32_t MYROUTINE(...);" is the signature of your assembler routine, we suggest you examine the calling code in the pseudo-assembly listing generated for your C++ code (with the OS_DOWNSTACK removed) to see how the parameters are setup. The var_args support is a C/C++ concept. The variable portion of the parameters are expected to be retrieved using the C/C++ way, e.g. va_list/va_start/va_arg/va_end etc. If you want to retrieve the compiler formatted var_args parameters in your assembler code, you are on your own. Particularly for 64-bit code there is no high-order-bit to turn on to highlight the end of a variable parameter list. Your assembler routine needs to have a different way to determine the number of arguments. Hopefully all your parameters are of integer types so you do not need to be concerned about where exactly to find your values, e.g. float.
    • KirkWolf
      KirkWolf
      8 Posts
      ACCEPTED ANSWER

      Re: CCN8806 with OS_DOWNSTACK in _LP64 mode

      ‏2010-12-09T16:13:45Z  in response to SystemAdmin
      I almost sure that you are correct - OS_DOWNSTACK has different parameter passing techniques than "C" in LP_64 mode.

      I would point out that the documentation incorrectly does not mention that OS_DOWNSTACK is not supported in LP_64 mode, and in fact it used to work fine without a warning in an earlier version of the compiler (1.8 or 1.9, I'm not exactly sure now).

      This problem is somewhat frustrating as we have code that can be built in either 31 or 64 bit. In LP64, the assembler routines use conditional assembly in their prolog/epilog and in 64 bit downshift to AMODE=31.

      But since IBM has silently dropped "OS_DOWNSTACK" linkage support in LP64, we will also need to #ifdef the C++ code to use "C" linkage, along with modifying the assembler 64-bit code to handle different parameter linkage. Figuring out this inter-language linkage is bad enough without being blind-sided by undocumented changes.

      So I will take your suggestions for fixing my code, but IBM needs a DOC APAR that points out that programmers need to change their assembly code :-)

      Thanks for your help.