Everything is relative. Certainly some 31-bit code is easy to thunk to, but it's not just arguments that need to go below the bar, it's any control blocks those arguments point to and any control blocks those control blocks point to, etc. You also need to handle call-backs from 31-bit code, exceptions thrown from same, etc.
As for stack extensions, there isn't a lot of code that would go deeper than one megabyte and that's the minimum allocation size for 64-bit. There's a bunch of tuning knobs for this stuff if you do have such an application. In article <985915eee6984740ae93f8495c624c6c232c1e0...@jscpcwexmaa1.bsg.ad.adp.com> you wrote: > 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:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tom Marchant > Sent: Thursday, April 24, 2014 4:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > 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. > -- -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637 Cary, NC 27513 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
