On Fri, Apr 25, 2014 at 9:59 AM, Farley, Peter x23353 <[email protected]> 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. >
Java has the area above the 2GB line. If the top of that is store protected, you could place the stack right above the protected Java area. <deleted> Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
