I thought LAY required a more recent processor? Sent from my iPhone
On Aug 15, 2013, at 14:47, Robert Ngan <[email protected]> wrote: > If the label could be in the module or in a dsect, I'd use LAY instead of > LARL. > Of course, this assumes you currently have addressability to the dsect, and > the label is within +/- 512K of the dsect base register (or your module > static data base register) which in 99.9% of cases is a good assumption. > And you don't have to worry about halfword alignment. > > Robert Ngan > CSC Financial Services Group > > IBM Mainframe Assembler List <[email protected]> wrote on > 2013/08/15 06:19:06: > >> From: "John P. Hrtmann" <[email protected]> >> To: [email protected] >> Date: 2013/08/15 06:21 >> Subject: Making an old macro baseless >> Sent by: IBM Mainframe Assembler List <[email protected]> >> >> CMS Pipelines ships the macro #LAL. One would write: >> >> #LAL 2,'a message' >> >> This expands to a LA 2,=c'...' and LA 3,<length>. As the constant goes >> into a literal pool I can substitute LARL for even length literals >> without adding failures (unless the literal pool is more than 4G away). >> >> The general case of >> >> #LAL 2,label >> >> expands also to a LA. I can change that to a LARL only when the >> reference is to a control section. If the label is declared in a dummy >> section, there is no way around the USING and LA. (If the label is >> undefined at the time the #LAL macro is issued, all bets are off and I >> must clearly be conservative and go LA). >> >> So my question is: How to determine whether a label is in a DSECT or >> CSECT/RSECT? I think I can determine whether the symbol is absolute >> from the type attribute, so we don't need to worry about that. >> >> Or is there a way to determine the name of the section a symbol is in? >> If not, would a SETC function SECTION(x) returning the appropriate name >> be useful in generl? All it has to do is look in the symbol table and >> return a null string for undefined or absolute. A SETA function >> returning the ESD number of the containing section would also solve my >> problem (DSECTS have negative ESD IDs internally; absolute symbols are >> in ESD 0). SETA also gets round the problem of the symbol being in >> private code, so it is really the best. >> >> I guess there is the additional wrinkle that the target must be on a >> halfword boundary, but I can add a trailing blank to a literal that is >> an odd number of characters (as long as I don't mess up the length). >> >> Any suggestions?
