On Dec 20, 2010, at 07:05, Bodoh John Robert wrote: > Ed, Martin, John, Tony, et al, > > What I am doing is creating macros that are used by any other application. I > was hoping to avoid having the user of these macros have to specify the > technique needed to address symbols. That sounds clutzy and it nowhere else > in the assembler do I have to tell the assembler that kind of detail. > ... > I am surprised this not considered a hole in the assembler and is not more > pervasive than just for me and my simple case. Do not other macros have the > same problem?
On Dec 18, 2010, at 15:24, Peter Relson wrote: > > > Unless specified otherwise, references by the macro will use LA (or LAE). > And it is up to you to set things up and specify things so that that LA(E) > works. > I suppose an IBM employee can easily be unaware that the "you" coding the macro may not be the same person, or even from the same organization as the "you" invoking it. On Dec 17, 2010, at 15:18, John Ehrman wrote: > > > Unfortunately, there's no general way HLASM can know which base registers > cover which parts of the program until after the end of the first pass -- > which is when macro expansion occurs. > I sympathize. > If it's really important to you, your best bet is to write your own > "MyUSING" and MyDROP" macros that capture useful information and then issue > the normal USING and DROP instructions. > That may be impractical, even impossible, and may not meet the OP's need. Some assemblers have instruction mnemonics that generate different opcodes as required or permitted by context. This is particularly difficult when the instruction lengths differ and the decision can not be made in the first pass. And I recall a wise colleague's railing decades ago at an Intel assembler which second-guessed him on an opcode to use in a timing-sensitive area. Sic transit IHBINNRA. R.I.P. The sophistication of the zSeries hardware outpaces the ability of the assembler to exploit it. Is any reader here unconstrained by confidentiality so as to be able to describe how PL/X deals with such needs? Or perhaps an erudite reader can advocate a macro approach. -- gil
