In general, based addressing is for data and relative addressing is for instructions. So if the macro is branching, use the relative instructions. And macros generally assume that base registers and USINGs will be established to access any data.
Until recently there were no relative data access instructions. But even if the program will only run on a machine with those instructions, there is little reason to use them. If modifiable data fields are separated from instructions and constants, then a base register will be needed for them anyway. And the immediate instructions reduce the need for constant data fields. If you look at what the compilers generally do, they establish a base register for the constants and one or more base registers as needed for the modifiable data areas. This same scheme works well for the assembler programs that I write and I have not run into the situation that you describe. If your macros need to be generate different instructions depending on if certain instructions are available, look at what many of the z/OS macros do when SYSSTATE ARCHLVL is set. Or macros can check if the OPTABLE contains specific instructions by testing the O' attribute. David Bond On Mon, 20 Dec 2010 10:28:21 -0500, Bodoh John Robert wrote: >Steve, > >Some of my macros generate a CALL or LINK to a subroutine and pass a parameter list consisting, in part, of the address of storage locations specified through arguments on the macro. In generating the storage address (reentrant code), a LA or LAE(based), or LARL (baseless) would be used. > >You're right about calling CSECT or DESCT based. I was referring to the code I needed to generate rather than the location of the symbol. > >I guess what irks me is that the macro has no way of knowing what to generate. There is a hole in the assemble architecture. For example, before baseless, when I reference a symbol, the assembler knows how to resolve the storage location. It would lookup the symbol, determine the base register for the storage and the displacement, and generate the machine code. > >John
