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

Reply via email to