I've recently extended this code/data LOCTR concept further by defining a
second data location counter.  The second one is for data not referenced by
SS instructions and therefore can have an offset greater than 4K off the
'data' base register.  Useful if you're near (or have exceeded) the 4K
limit with your data fields.  Just need to remember to always use long
displacement instructions to reference fields defined in the @YONDER LOCTR.

Robert Ngan
CSC Financial Services Group



From:   Binyamin Dissen <[email protected]>
To:     [email protected]
Date:   2012/01/11 04:20
Subject:        Re: Enhanced CALL macro?
Sent by:        IBM Mainframe Assembler List <[email protected]>



On Tue, 10 Jan 2012 15:20:22 -0600 "McKown, John"
<[email protected]> wrote:

:>I could use an enhanced CALL macro. I am writing RENT code and trying to
be "baseless". For the RENT, I am using CALL with MF=(E,(1)) and GPR1
pointing to an array of fullwords in dynamic storage. The parameters within
the CALL are a mixture of locations within the CSECT (these are read-only
"constants") and areas in dynamic storage. Basically the CALL uses an "LA
0,..." to load the address of the parameter into GPR0 followed by a "ST 0,n
(0,1)" to save the address in the parameter area. I wish that there were a
way to tell the CALL to use a LARL instruction to address the parameters
which are within the CSECT. Even if I had to do it on a parameter by
parameter indicator, such as prefixing the symbol with an "invalid"
character. For instance, a !. So my CALL would look like: CALL
(15),(!IN_CSECT,IN_DYN),MF=(E,(1)) . So that CALL would use

:> LARL 0,IN_CSECT
:> ST 0,0(0,1)
:> LA 0,IN_DYN
:> ST 0,4(0,1)
:> BALR 14,15

:>This would eliminate almost all base+index instructions in my current
code. Well, I still have a few MVCs and CLCs left too.

:>Am I going too crazy? I'm a bit "register poor" because I really love to
keep values in registers, rather than do redundant loads and stores.

There are separate issues here. One cannot really remove "all base+index
instructions" unless one restricts oneself to a very limited set of
instructions.

No base register need be used for the program code. Data is a completely
different story. Is it worth using LARL any time you wish to address a
literal? I know allow myself to write CSECTs without size limit since I no
longer need to tie up a register for every 4K. I have used LOCTR's for long
time since it allows me to place the data in the source file next to
instructions that use it.

Now as part of my CSECT start I have

   name     CSECT
   @CODE    LOCTR ,
   @LITERAL LOCTR ,
   LITERALS DC    0D'0'
   @DATA    LOCTR ,
   @CODE    LOCTR ,
            .
            .
            LARL  Rliterals,LITERALS
            USING LITERALS,Rliteral

At the end

   @LITERAL LOCTR ,
            LTORG ,

With an @DC macro that places the constant after the @DATA loctr.

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