On Tue, 13 Aug 2019 at 11:39, Steve Smith <sasd...@gmail.com> 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
         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
         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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to