Thanks! However, I think you meant ACONTROL FLAG(NOALIGN)/ACONTROL FLAG(ALIGN). At least that is what worked for me.
Thanks again, Mark Hammack Senior Technical Specialist Systemware, Inc. On Mon, Aug 16, 2010 at 1:00 PM, Binyamin Dissen <bdis...@dissensoftware.com > wrote: > On Mon, 16 Aug 2010 09:45:39 -0500 Mark Hammack <mark.hamm...@gmail.com> > wrote: > > :>I have a question about alignment that maybe someone will be able to > :>answer. I recently came across this in a piece of code: > > :>BB68 5004 00000004 31508 CDS R6,R8,4(R5) > > :>According to the POO, " The second operand of COMPARE AND SWAP (CSG) and > :>COMPARE DOUBLE AND SWAP (CDS, CDSY) must be designated on a doubleword > :>boundary". As it turns out, R5 in this case, points to the second word > of a > :>quadword so that +4 is in reality a doubleword. However, when I tried to > :>make it more maintainable by coding: > > :>BB68 5004 00000004 31507 CDS R6,R8,STGHEAD > > :>(notice the same object code) I get a warning: > > :>** ASMA213W Storage alignment for STGHEAD unfavorable > > :>I assume that it doesn't like 4(R5) for a 'doubleword boundary'. My main > :>question is why doesn't the assembler complain when 4(R5) is hardcoded > vs. > :>the derived value from STGHEAD? My subsequent question is, from an > :>architecture perspective, which is more important, the absolute address > of > :>the second operand be double word aligned (i.e. that R5+4 equate to a > :>doubleword) or that the offset is 'doubleword aligned' (i.e. remap the > DSECT > :>so that STGHEAD is at +0, +8, etc.) regardless of where the base register > :>points. Obviously the 'easy' (and maybe the best) solution is to ensure > both > :>the base address of the DSECT and the CDS target are doubleword aligned > :>(there are historical reasons I don't want to make THAT change if I don't > :>have to but I will in a future release). > > DSECTs are assumed to be at a doubleword boundary. Explicit offsets know no > boundaries. You can suppress the warning for that particular statement > (since > you know that it is bogus) by bracketing it with PROCESS FLAG(NOALIGN) and > ALIGN. > > -- > Binyamin Dissen <bdis...@dissensoftware.com> > http://www.dissensoftware.com > > Director, Dissen Software, Bar & Grill - Israel > > > Should you use the mailblocks package and expect a response from me, > you should preauthorize the dissensoftware.com domain. > > I very rarely bother responding to challenge/response systems, > especially those from irresponsible companies. >
