On Mon, 16 Aug 2010 09:45:39 -0500 Mark Hammack <[email protected]>
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 <[email protected]>
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.

Reply via email to