Steve Smith wrote <snip> I found that a couple of IBM AMODE 64 callable routines expect R15 to be set to their EPA, although most do not. I discovered these when I made the calls using JASL ( </snip> I trust you are aware that "callable" really does mean using "CALL" (whether in a HLL or, in assembler, by the CALL macro). Use of any linkage instruction that is not the default should not be assumed to work unless the service documents that it is OK to do so. Even when using BRASL as your linkage instruction, unless you know the requirements of the target, setting up reg 15 (perhaps via LARL) is often a good idea. Both LARL and BRASL can have as their operands things not within the same CSECT. The binder handles most of these cases. The loader handles others as part of "relocation". And, yes, there are cases were relocation applies even to use of relative branches. I'll leave that teaser as an exercise for the readers.
Keith Moe wrote <snip> Even when using "baseless" code, I like to keep ONE register as the base/entry point of the module (plus what ever is needed for constant/data areas beyond the first 4K). Having a register thus set makes looking at a dump easier as this base register (90% of the time R12) points to the current module. Also, when tracing back through the save area chain or linkage stack, there's a register that is pointing to each module that did the linkage. </snip> FWIW, the convention we adopted long ago was that the first word/doubleword pointed to by the "static area register" contains the beginning of the module. Thus if you have a convention of which is the "statreg", your dump reading involves using that register's value to locate the area that contains the address of the module. Sacrificing a register, especially for compiled code, can be a big deal performance-wise. The approach of using LOCTR to have your static data at the beginning is a good one too, at the minor expense of wasting an I-cache line. You definitely would not want to take that approach for a non-reentrant module if doing so meant that that first data could need to be in both the I-cache and, for write, the D-cache. <snip> > And, of course, R15 is not even loaded with the entry point address for programs given control in AMODE(64) :-\ > That strikes me as thoughtless; bad design. High astonishment factor and breaks consistency between CALL and JCL EXEC. </snip> Significant thought was given to this design. We could not find a reasonable alternative that met all the requirements. The fact that you made this statement leads me to think that you have not thought of some of the requirements. I suggest that you look up what the value in reg 15 means for this case (it should be documented somewhere), and for the other system-assisted linkage cases. Yes, there's a high astonishment factor. But use of AMODE 64 itself was totally new and compilers were expected to do the right thing -- not rely on entry reg 15 for AMODE 64 modules. That left the assembler users. Perhaps we failed to document this expectation. There is no problem with (or need for) 'consistency' in this case because the target is expected not to care if the source did or did not set reg 15. Peter Relson z/OS Core Technology Design
