Ed,
I have used the following (in a macro) to do that:
$ALIGN EQU &VALUE-((*-&CSECT)-(((*-&CSECT)/&VALUE)*&VALUE))
DC ($ALIGN)X'00' SET ALIGNMENT
&VALUE is whatever boundary you want (256, 512, 8, 4, …).
&CSECT is the name of the csect (or location counter).
DC or DS can be used.
Bill Hitefield
> -----Original Message-----
> From: IBM Mainframe Assembler List <[email protected]>
> On Behalf Of Ed Jaffe
> Sent: Friday, November 17, 2023 4:51 PM
> To: [email protected]
> Subject: Re: BAKR/PR and Linkage Convenction
>
> BAKR/PR provides wonderful capabilities, but it's slower than a traditional
> save/restore into already-acquired storage.
>
> BAKR/PR is faster than acquiring storage for a save area.
>
> Generally, our programs use a save area stack acquired by the mainline at
> initialization time. For such programs:
>
> o If we're calling a routine in the same CSECT, we use JAS/BR.
>
> o If we're calling a routine in another module, we use BASSM/BSM.
>
> On 11/17/2023 1:19 PM, Jo ão Reginato wrote:
> > Hi
> >
> >
> >
> > I’m very interested in knowing your performance experiences about
> > using BAKR/PR versus the Linkage Convention traditional way.
> >
> > I use BAKR/PR only when there is no dynamic storage acquirement in my
> > programs otherwise I prefer save/restore regs adding 18F on it.
> >
> > Am I right?
> >
> > TIA
> >
> > João
> --------------------------------------------------------------------------------
> This e-mail message, including any attachments, appended messages and the
> information contained therein, is for the sole use of the intended
> recipient(s).
> If you are not an intended recipient or have otherwise received this email
> message in error, any use, dissemination, distribution, review, storage or
> copying of this e-mail message and the information contained therein is
> strictly prohibited. If you are not an intended recipient, please contact the
> sender by reply e-mail and destroy all copies of this email message and do not
> otherwise utilize or retain this email message or any or all of the
> information
> contained therein. Although this email message and any attachments or
> appended messages are believed to be free of any virus or other defect that
> might affect any computer system into which it is received and opened, it is
> the responsibility of the recipient to ensure that it is virus free and no
> responsibility is accepted by the sender for any loss or damage arising in any
> way from its opening or use.
