A couple of things.
One, yes, my assertion that it is easy was based on my own experience primarily
with modest-sized programs that I had written myself -- in some cases years
earlier. If you are talking about 10,000 lines of spaghetti enhanced over the
years by lots of folks, with embedded local macros and various cleverness, then
it could be a large and fraught project.
Two, I am not advocating for "baseless" programming -- eliminating base
registers like they were forbidden GOTOs in some COBOL program.
a. Relative jumps are goodness in any event. They are thought to be generally
faster than based branches. So even if you did nothing else, replacing 90% of
your branches with jumps could be a good thing.
b. I think all of my programs use a code base register. One code base register.
One. I am advocating for (i) getting rid of "4K anxiety" and (ii) freeing up a
register or two in those old programs with two or three code base registers.
Here's the structure (and apologies for starting from @Peter's example) --
untested, of course
TEST CSECT
MAIN1 LOCTR
M1 DC 'Eyecatcher at front of CSECT'
MAIN2 LOCTR
DS H alignment
MYENTRY EQU *
ENTRY MYENTRY
SAVE ...
LARL R12,MAIN1 no more BALRs!
USING MAIN1,R12
code ...
MAIN1 LOCTR
* put any macros that need a base in little subroutines here
LTORG
Small constants and, if CSECT not relocatable, work areas
MAIN2 LOCTR
Any large buffers or tables
END
So long as MAIN1 is less than 4K the whole thing will work with just the one
code base register, no matter how long MAIN2 is. The organization in storage is
R12 points here --> MAIN1
Eyecatcher
LTORG
Macro subroutines
Small constants
MAIN2
Main code
4K addressability ends somewhere above or below here
Large buffers and tables
Charles
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On
Behalf Of Bernd Oppolzer
Sent: Friday, April 1, 2022 2:51 PM
To: [email protected]
Subject: Re: Eliminating Base Registers (was: Inlining routines)
See some answers below.
In general the elimination of base registers for the code section
with existing large programs is a major task and needs careful testing.
I did this sometimes, and I had many issues and headaches, until the
programs worked (again). More hints below ...
Kind regards
Bernd
Am 01.04.2022 um 20:41 schrieb Dave Clark:
> "IBM Mainframe Assembler List" <[email protected]> wrote on
> 04/01/2022 02:14:38 PM:
>> Where I disagree is on the base register issue. Base registers and
>> code addressability issues should have gone away. It is pretty
>> trivial to replace old branches with their newer relative
>> counterparts. Should be faster code, too, FWIW.
>
> OK, I'll bite. This discussion has probably been done before but
> I wasn't around for that. Forgive my newbie questions -- even though I
> have been programming in assembler on and off since 1978. That said...
>
> I understand relative branching on a basic level. But I haven't
> really looked into them and haven't used them at all to this point. So...
>
> 1. Is it as simple as just using a different mnemonic for the branch?
In general, yes, but, see above, there are different problems,
with IBM or site-specific macros which generate inline definitions etc.
and literals etc. ... and which assume that there is a base register which
covers the code section. You can change them, or you can establish a
temporary base (maybe register 1,14, 15) around the macro call.
> 2. Does the target label still have to be within 4K for the relative
> branch?
No, even the simple relative branches can reach 64 k in both directions
from the current PSW
> 3. ...or is there an extended relative branch that uses the extended
> displacement feature?
there are extended branches, but when converting existing programs,
you normally don't need them
> 4. What about the target for the EXecute instruction? Is there a relative
> version of this?
no need for this during normal conversion, because you need a base register
for the data part, anyway, and the target of the EX is in the data part
> 5. Even if code base register(s) is(are) eliminated, you still need a data
> base register -- yes?
yes, sure. If you read my former post about local procedures, which had
for example two base registers in the past, you may now reduce the
two base registers to one, and the one covers the "local" data area
of the local procedure, which is the data area which lies behind the
code section of the local procedure. The code section doesn't need
a base register any more. With the older technique, both code and
data area were limited to 8 k; now the data area is limited to 4k,
but the code area is unlimited (if you manage to get is baseless).
> 6. If you have a large program with constant data at the end of the
> program, how do you establish the base register needed for that data area?
you should IMO move the "global" data after the code section for the
mainline, and then establish a base register from the mainline, which
makes this global data section available for all "local subroutines".
This way, you can access all data with only two base registers,
say 10 and 11: 10 for the global data area, and 11 for all the local
data areas; every local procedures assigns reg 11 to the base address
of its local ares on entry. The addressing of these areas is always
established using address constants.
> 7. Lastly, if the code base register has been eliminated, does this mean
> you should no longer have things like LTORG at the end of each subroutine
> to force data to be stored near the subroutine that uses it (where
> previously the code base register for the subroutine would have served
> double-duty as the data base register)?
you need LTORG as before; see above ... you still have a base register
which points at the data area for every subroutine. The difference to
the older solution is that the base address now is not the beginning
of the subroutine but instead somewhere near the end and that
the base register does not cover the code section (and the data section)
but only the data section, which lies behind the code section.
The LTORG should be located directly following the return instructions,
at the end of the code section of the subroutine.
>
>
> Sincerely,
>
> Dave Clark
