On Dec 20, 2010, at 08:49, Bodoh John Robert wrote: > > What about lookahead? Does that not set attributes based on the > characteristics of symbols not already defined? Why not an attribute > that indicates whether not a symbol is addressable by relative > addressing instructions? > Lookahead has its limits. I have a cute example in which every symbol is defined textually prior to its application, yet HLASM by its rules can not resolve the definitions. This doesn't even involve base-displacement resolution.
> -----Original Message----- > From: IBM Mainframe Assembler List > [mailto:[email protected]] On Behalf Of Binyamin Dissen > Sent: Monday, December 20, 2010 10:39 AM > > On the first pass the assembler does not know that it can address the > symbol. > But as the instruction uses the same amount of space anyway, it does not > matter. At a later pass the assembler figures out if it has > addressability and > then either reports and error or completes the instruction. > "[S]ame amount of space" is crucial. LA is 4 bytes and LALR is 6. I could imagine a pseudoinstruction mnemonic which on Pass 1 reserves 6 bytes and on Pass 2 generates either LALR or a 2-byte NOP followed by LA; whichever works. As John E. states, this determination can not be made by a macro (but will John G. agree?). Would macro authors welcome such a facility or shun it? On Dec 20, 2010, at 08:32, David Bond wrote: > > 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. > Are modifiable data fields separated for pipeline performance? How? In separate CSECTs, or by "DS 4096C"? If in the same CSECT, the reach of relative addressing is sufficient for a wide range of programs. -- gil
