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. -- Tom Marchant ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
