Glad you find it potentially useful. > isn't it a bit too clever...?
Well, as I said in the last sentence of my first paragraph it is too clever for me to use, but only you know the tradeoffs for you versus some other less than perfect solution. Document it well, put the 123 below into a macro -- perhaps it is not too bad. > Is the 64K limit sufficient for the foreseeable future? I would hope so, but only you would know. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Windt, W.K.F. van der (Fred) Sent: Tuesday, December 12, 2017 10:43 PM To: [email protected] Subject: Re: Address of a =LITERAL > I don't know why I keep thinking about this but I believe I have a > solution. It will give you exactly what you wanted, effectively DC > A(=literal). It is a hack and a kludge and I would not do it myself, but I > believe it will work. > > A. Add a separate CSECT to your code following the record layout. > Let's call it LITCSECT. Ahead of your table establish addressability > on it with USING LITCSECT,0. Put a LTORG in the CSECT. That will > collect all of your literals in that CSECT. > > B. In your table, a three-step process. You might want to put this in > a macro to avoid screwing it up. At each spot that you want your literal > pointer: > > 1. DC A(LITCSECT) > > That will generate an RLD so that whatever gets assembled into the > word, at load time MVS will add the load address of LITCSECT to it. > > 2. ORG *-4 > LA 0,=literal > > That will (a.) generate your desired literal following LTORG in > LITCSECT; and > (b.) overlay the A(LITCSECT) with 41000xxx where xxx is the offset of > the generated literal into LITCSECT. > > 3. ORG *-4 > DC X'0' > ORG *+3 > > That will get rid of the 41. > > So you now have 00000xxx in the table, where xxx is the offset of the > literal into LITCSECT, and an RLD that at load time will relocate the > word by the address of LITCSECT. > > QED Yup, that's creative but the 12 bits of offset are not sufficient: we have large structures with long element names that require more that 4K in the literal pool. I could get even more creative and add more USING statements and use R0 for the first 4K of the literals, R1 for the next 4K etc. That way the S-part in the LA instruction end up creating a 16 bit offset into the literal pool. With 16 USINGs I can cover 16 * 4K = 64K of literals. That is more than enough for any conceivable structure. And it's perfectly feasible to use every register to cover a large literal pool because we are generating load modules that only contain this datastructure. There is no executable code whatsoever in these modules so the macros currently don’t use any base register anyway. I have to look at the pros and cons and maintainability: it's very clever and I don't have to implement my own version of a literal pool in the macros but isn't it a bit too clever...? Is the 64K limit sufficient for the foreseeable future? These kinds of limits come back to haunt you much sooner than you ever thought possible.
