From z/Architecture Principles of Operation: "The second operand of COMPARE AND SWAP (CS, CSY) must be designated on a word boundary. The second operand of COMPARE AND SWAP (CSG) and COMPARE DOUBLE AND SWAP (CDS, CDSY) must be designated on a doubleword boundary. The second operand of COMPARE DOUBLE AND SWAP (CDSG) must be designated on a quadword boundary. The R1 and R3 fields for COMPARE DOUBLE AND SWAP must each designate an even-numbered register. Otherwise, a specification exception is recognized."
-- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Mark Hammack wrote:
Thanks for all of the suggestions! Of course, one fundamental question that the discussion has prompted in my mind is: Why does the data for a CDS need to be on a doubleword anyway? The data is read from or loaded into the low order 32 bits of two consecutive registers. As such, it seems that the data is really two consecutive fullwords, not a doubleword. Using STGHEAD-STGPOOL(R5) is a good idea unless and until I need to change base registers, in which case, I have to remember to change the instruction. Better, but not ideal IMO. To answer the (first) original question, I guess HLASM doesn't "look" at hardcoded offsets, just generated base/offset (S-con). I am still not sure whether the actual data MUST be on a true doubleword boundary or if it would work on a fullword boundary. Guess it's time for an experiment. Thanks again, Mark Hammack Senior Technical Specialist Systemware, Inc. On Tue, Aug 17, 2010 at 1:27 PM, Schwarz, Barry A < [email protected]> wrote:If you expect STGHEAD to always be double word aligned and R5 to always contain the address of an odd word, you need a way to inform the assembler you are violating conventional alignment. One possible method is STGXXX DSECT DS F STGPOOL DS 0X STGSIZE DS F STGHEAD DS A ... which has the advantage of not requiring any changes to your USING statements. All of which begs the question of why STGHEAD is DS A and not DS D. Or at least preceded by a DS 0D. If updating the DSECT is impractical at this time, you can still eliminate the hardcoded offset by using STGHEAD-STGPOOL in place of 4. Your code will be self adjusting if the DSECT ever does change. -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Mark Hammack Sent: Tuesday, August 17, 2010 7:33 AM To: [email protected] Subject: Re: CDS and alignment question Yes, STGHEAD is in a DSECT: STGPOOL DSECT STGSIZE DS F STGHEAD DS A STGCNT DS F STGERR DS F As I said in the original e-mail, the "easy" thing to do would be to rearrange the dsect so that STGHEAD is on a doubleword boundary (i.e. move STGERR before STGHEAD and add DS 0D before the actual data). However, finding all of the procedures that rely on this particular layout may be difficult. But I will be changing it in a future release of the software. My other option is to 'go back' to hardcoded offsets (i.e. 4(R5) ) since HLASM doesn't complain about that) and document why things are done the way they are (forcing the pool definition to a 'doubleword+4' boundary so that STGHEAD is on a doubleword for example which was another interesting exercise and exactly what 4(R5) is).
