I see the descriptions of the XPLINK and XPLINK-64 conventions in that manual, but nothing about those conventions would prevent calls to programs with other linkage conventions or address modes, IMHO without much trouble at all. The code to implement a call to a 31-bit program will obviously cost CPU cycles to move the arguments below the bar, and perhaps more to set up a non-XPLINK DSA and stack (assuming a call to an LE-enabled module), but none of that is impossible. It's only a question of knowingly bearing the cost of those extra linkage steps and some enclave-initialization-time cost to proactively set up a 31-bit DSA and stack for those inter-linkage-convention calls.
I also saw in section "2.3.2.2.2 Stack Overflow" in the XPLINK-64 area this statement: "The stack floor is the lowest usable address of the current stack area. In the lower storage addresses, it is preceded by a store-protected guard area used to detect stack overflows." The "guard area" in XPLINK-64 is 1M, the minimum allocation size, so they are using the hardware store-protect mechanism to detect stack overflow. Seems wasteful of CPU cycles to me, since PIC exception processing is so much more expensive than one prolog instruction to test the available space in the stack frame, but I guess with above-the-bar storage being so plentiful they are trading prolog CPU cycles for far more expensive stack-extension cycles, with the implied assumption that stack extension will be far less common than below the bar. It obviously argues that they expect you to allocate far more stack than you think you may ever need to avoid stack extension costs. I share your opinion that the LE people have gotten this wrong. The only excuse I can imagine is that it makes true exception processing "too difficult to implement", FSVO "difficult". The only other explanation would seem to be "we don't care about legacy code any more", which is a bit scary. Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Tom Marchant Sent: Thursday, April 24, 2014 4:32 PM To: [email protected] Subject: Re: Enterprise COBOL v5.1 and RDz v9.x On Thu, 24 Apr 2014 10:33:50 -0400, Farley, Peter x23353 wrote: >PMFJI here, but it is my impression (please correct me if I am wrong) >that XPLINK is the z/OS analog of the calling mechanism developed in >Germany for z/Linux from the kernel on up to user space. I don't know about that. XPLINK was introduced with OS/390 2.10 The LE Concepts Guide has this in its glossary: <quote> Extra Performance Linkage (XPLINK). Extra Performance Linkage (XPLINK) is an enhanced linkage between programs that can significantly improve the performance of your C and C++ programs. The primary goal of XPLINK is to make subroutine calls as fast and efficient as possible by removing all nonessential instructions from the main program path. The XPLINK run-time option controls the initialization of the XPLINK environment. </quote> >Yes, it's fast, but it provides no call backtrace (i.e., no register >saveareas) unless specifically requested at compile time. Yes, it does, but it does it differently. The XPLINK save areas are documented in the LE Vendor Interfaces manual. Not all registers are necessarily saved, but register 7, the return address with XPLINK, is always saved. Fast? Well, you can pass a few parameters in registers. And it doesn't do a GETMAIN for a save area in the code for every program entry. And it doesn't check the stack to see if there is sufficient room in the stack every time. Instead, it relies upon a Program Interruption Code 4 if it tries to store the caller's registers outside of the stack. I don't remember how they ensure that a PIC 4 occurs with XPLINK, rather than overlaying something. With XPLINK-64, the stack is above the bar and a guard area is allocated. This causes its own issues. For example, if an XPLINK-64 program wants to call a program that uses standard linkage, even a standard program like GET or PUT, it needs to allocate a save area below the bar for its save area. Actually, LE uses a stack with standard linkage too, so it doesn't need the GETMAIN either, but it tests the stack to see if there is sufficient space available. If not, more stack is acquired. In XPLINK, the same kind of thing is done, but it is triggered by the PIC 4. If I am a Cobol programmer, I might want to write a program that is called to look up something in a table that resides above the bar. The limitations on interoperability mean that it is more difficult to do that and the small performance improvement that would be available in an environment that is all XPLINK-64 becomes a bigger performance penalty each time the program is called. LE would have me recompile the entire system to run XPLINK-64. And if my system uses subroutines that are also used by other systems, maybe I should recompile all of them as well. The LE people apparently don't share my opinion about this. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
