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
