On Tue, 13 Aug 2019 at 11:39, Steve Smith <[email protected]> wrote:
> There's a big difference between B- (base-index-displacement) branches and
> J- (or BR-) (relative address) instructions. Surely by now, this should go
> without saying. Regardless of whether they're "faster" or not, they are
> much better, and as that is well-documented, I won't belabor it.
>
There is one way in which the relative branch instructions are "worse", not
at run time, but assembly time. Say you have a module with (generally good
practice) a bunch of small internal subroutines. Let's say SUBA to start:
SUBA entry code
USING SUBA,Rbase
do SUBA's work
LTR R15,R15 Success?
BZ UPDATE_DATA_A
deal with failure and return
UPDATE_DATA_A store some data related to A
Return
DROP Rbase
Now you want to add a routine to do work B. So you clone the SUBA code, and
then change all the labels.
SUBB entry code
USING SUBB,Rbase
do SUBB's work
LTR R15,R15 Success?
BZ UPDATE_DATA_A
deal with failure and return
UPDATE_DATA_B store some data related to B
Return
DROP Rbase
But - as I did above - you fail to change the branch to UPDATE_DATA_A to
UPDATE_DATA_B. With BZ you will have an addressibility error (or at least
with careful use of USING and DROP you can force one), but with JZ it will
almost certainly assemble without error. Then at run time you will branch
into the middle of the wrong routine.
I'm not aware of assembly time tools or options to avoid this. Really this
is a larger assembler issue where name scoping is required, but the
relative branch instructions have made it a much easier mistake to make.
Tony H.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN