...inline... On Tue, Dec 3, 2019 at 9:10 AM Peter Relson <[email protected]> wrote:
> 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. > > I'm aware that subroutines have their requirements, and one has to deal with them; that's not really an issue. But it's a pretty obvious argument that IBM's services should be consistent with their guidance on other people's AMODE 64 programs, esp. when it's trivial to do so. JAS/L calls are more efficient, if just for not having to load and then reference R15. Irregardless, I'm not bothered about it. It occurred to me that an RMODE SPLIT program could blithely branch back and forth between below and above-the-line CSECTs as long as relative-long branches were used to make the jumps. Whether that's a good or useful idea, I'm not so sure. Thanks to a clue from John Ehrman a few years ago, I've found that relative branch instructions have all the capabilities of A- & V-cons for linkage and relocation (at least on z/OS, using the Binder). > 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. > My deferred comment is that was a terrible waste of a good register. There are many ways to track what program is executing, and the pointer at the beginning of the static area is a good one. > <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. > > It is documented, and clearly. The problem is knowing when you need to re-read the manual. > Peter Relson > z/OS Core Technology Design > -- sas
