Re: CDS and alignment question

[David P de Jongh]

Try STGHEAD-STGPOOL(R5).

 

David de Jongh

Aug 17, 2010 02:37:04 PM, ASSEMBLER-LIST@LISTSERV.UGA.EDU wrote:

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).

Thanks again,

Mark Hammack
Senior Technical Specialist
Systemware, Inc.


On Tue, Aug 17, 2010 at 12:11 AM, Hall, Keven wrote:

> Mark,
>
> How is STGHEAD defined? Is it within a DSECT? How is STGHEAD being
> resolved at assembly time? We can't help you make the code easier to
> maintain if we don't have all the details.
> Personally I think that sandwiching the CDS between ACONTROL FLAG()
> statements could result in at least as much confusion as the original
> un-sandwiched instruction.
>
> Keven Hall | keh...@informatica.com
>
> -----Original Message-----
> From: IBM Mainframe Assembler List
> [mailto:assembler-l...@listserv.uga.edu] On Behalf Of Mark Hammack
> Sent: Monday, August 16, 2010 13:26
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: CDS and alignment question
>
> 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
> > > wrote:
>
> > On Mon, 16 Aug 2010 09:45:39 -0500 Mark Hammack
>
> > 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
> > 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.
> >
>