Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Edward E. Jaffe]

OK. So nobody cares about 5-digit device numbers (JOBCAT/STEPCAT is 
always an amusing topic).


How about the wild branch diagnosis improvement? (Does anyone on this 
list still write code?)


z9 109 remembers the last successful branch instruction address and the 
operating system displays that address in dumps. I would guess that at 
least 90% of S0C1 abends are caused by so-called "wild branches" ... a 
large percentage of which end up at location zero. Given that, a typical 
debugging scenario is to look for zeros in R15. If so, assume the return 
address in R14 is the last known address. But what if it isn't? What if 
all of the registers are "clobbered"? There are many different possible 
wild branch outcomes and some can be *extremely* difficult to diagnose 
(BTDTGTS).


My reaction? It's about time! Thank you, IBM!

--
.-.
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
'-'

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/05/2005
   at 04:50 PM, Graeme Gibson <[EMAIL PROTECTED]> said:

>ISTR that the 1401 had a LAR too.  Anyone else recall this?

Are you thinking of the B register? SBR was standard for subroutine
linkage. Of course, that behavior meant that you couldn't pass
parameters in the B register.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Tom Schmidt]

On Fri, 29 Jul 2005 13:56:21 -0700, Edward E. Jaffe wrote:

>How about the wild branch diagnosis improvement? (Does anyone on this
>list still write code?)
>
>z9 109 remembers the last successful branch instruction address and the
>operating system displays that address in dumps. I would guess that at
>least 90% of S0C1 abends are caused by so-called "wild branches" ... a
>large percentage of which end up at location zero. Given that, a typical
>debugging scenario is to look for zeros in R15. If so, assume the return
>address in R14 is the last known address. But what if it isn't? What if
>all of the registers are "clobbered"? There are many different possible
>wild branch outcomes and some can be *extremely* difficult to diagnose
>(BTDTGTS).
>
>My reaction? It's about time! Thank you, IBM!

My reaction is similar to yours, Ed.  I had been wondering about the need
for some kind of "come from" display when IBM brought branch relative long
instructions to the architecture.  The R15/R14 game seems like it falls
apart if the arrival at location 0 (or just arbitrary low storage) came
about because of a branch relative (jump) or worse, a BR-long.

Having the last successful branch displayed in dumps will help (as long as
the "branch from on high" isn't followed by a random branch down low before
the abend strikes; then all bets are off without an itrace).

Frequent culprits are the access method GET/PUT routines not being filled
in (due to OPEN failures that went unchecked) and those cases seem like
they'll be covered by the 'wild branch' display.  (Oh, joy!)

--
Tom Schmidt
Madison, WI

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Eugene S. Hudders]

Hi:

Add to this list an incorrect use of a BCT when you wanted to use a BCTR
(BCT R14,R00).

Regards,
Gene

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Charles Mills]

> Does anyone on this list still write code?

If you want to call it that :-)

Seriously, I have wanted this feature since I started writing assembler
code in 1969.

Debugging h*ll: if it's not R14, look for ANY register that points to a
suspect BAL or BALR. Then hope you can find a non-suspect BAL(R) and
work your way forward. And as others have pointed out, the newish Jumps
only made it worse.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Edward E. Jaffe
Sent: Friday, July 29, 2005 1:56 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Wild Branch Diagnosis (Was: Five Digit Device Numbers)


OK. So nobody cares about 5-digit device numbers (JOBCAT/STEPCAT is 
always an amusing topic).

How about the wild branch diagnosis improvement? (Does anyone on this 
list still write code?)

z9 109 remembers the last successful branch instruction address and the 
operating system displays that address in dumps. I would guess that at 
least 90% of S0C1 abends are caused by so-called "wild branches" ... a 
large percentage of which end up at location zero. Given that, a typical

debugging scenario is to look for zeros in R15. If so, assume the return

address in R14 is the last known address. But what if it isn't? What if 
all of the registers are "clobbered"? There are many different possible 
wild branch outcomes and some can be *extremely* difficult to diagnose 
(BTDTGTS).

My reaction? It's about time! Thank you, IBM!

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Edward E. Jaffe]

Tom Schmidt wrote:


My reaction is similar to yours, Ed.  I had been wondering about the need
for some kind of "come from" display when IBM brought branch relative long
instructions to the architecture.  The R15/R14 game seems like it falls
apart if the arrival at location 0 (or just arbitrary low storage) came
about because of a branch relative (jump) or worse, a BR-long.
 



I'm glad you agree with me, Tom. But, I honestly don't see how the 
advent of relative branch has compounded this long-standing issue in any 
way. I consider the possibility of a relative branch becoming "wild" to 
be quite remote. (One of their chief benefits!) Remember, they don't 
depend on a GPR being loaded correctly and/or an associated USING being 
properly specified. They are always relative to the current PSW.


For example, ,'BC 15,0(0,0)' will definitely go to location zero and 
leave no linkage trail in a register. How would you even code (on 
purpose or by accident) a BRC or BRCL to branch to location zero? 
Likewise, 'BAS xx,0(0,0)' will definitely go to location zero, but there 
will be a linkage register trail. Again, I don't see how you would even 
code the equivalent relative instructions BRAS or BRASL to branch there.



Having the last successful branch displayed in dumps will help (as long as
the "branch from on high" isn't followed by a random branch down low before
the abend strikes; then all bets are off without an itrace).
 



Agreed re: a wild branch to a branch. In my experience, that's quite 
rare. Having the processor remember one branch instead of the last 'n' 
branches will probably help with 99% of the hard-to-diagnose wild branch 
cases. For the others, you could say we're still one branch closer to 
knowing what happened. :-\


BTW, what is itrace? Do you mean system trace with branch tracing 
enabled? That won't trace the above instructions anyway. It traces only 
BALR, BASR, BASSM, BSA, BAKR (when 'r2' is non-zero), BSG, and RP ... 
not BC, BRC, BRCL, BAL, BAS, BRAS, or BRASL.



Frequent culprits are the access method GET/PUT routines not being filled
in (due to OPEN failures that went unchecked) and those cases seem like
they'll be covered by the 'wild branch' display.  (Oh, joy!)
 



Excellent example!

--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Edward E. Jaffe]

Charles Mills wrote:


... as others have pointed out, the newish Jumps
only made it worse.
 



Again, I really just don't see how...

http://bama.ua.edu/cgi-bin/wa?A2=ind0507&L=ibm-main&P=R100227&I=1

--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Jim Phoenix]

Try calculating a relative branch manually for a zap.  Don't forget to 
miscalculate or fat finger keying it in! ;-)


Edward E. Jaffe wrote:

Charles Mills wrote:


... as others have pointed out, the newish Jumps
only made it worse.
 



Again, I really just don't see how...

http://bama.ua.edu/cgi-bin/wa?A2=ind0507&L=ibm-main&P=R100227&I=1



--
| Jim Phoenix  | Voice:   (310) 338-0400 x316   |
| Senior Software Developer| Fax: (310) 338-0801|
| Phoenix Software International   | Alt fax: (310) 337-2685|
| 5200 W. Century Blvd., Suite 800 | [EMAIL PROTECTED] |
| Los Angeles, CA 90045| http://www.phoenixsoftware.com |

Opinions expressed by this individual are not necessarily those of the Company.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Ed Finnell]

 
In a message dated 7/29/2005 4:47:43 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

My  reaction is similar to yours, Ed.  I had been wondering about the  need
for some kind of "come from" display when IBM brought branch relative  long
instructions to the architecture.  The R15/R14 game seems like it  falls
apart if the arrival at location 0 (or just arbitrary low storage)  came
about because of a branch relative (jump) or worse, a  BR-long.



>>
Remember the old language construct to do away with GO TO's
and replace with COME FROM's? 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Ted MacNEIL]

...
Remember the old language construct to do away with GO TO's
and replace with COME FROM's?
...
Talk about predictive processing.

We used to joke about that at UoW, in the mid-1970's.

-teD

In God we Trust!
All others bring data!
 -- W. Edwards Deming

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Ed Finnell]

 
In a message dated 7/29/2005 6:01:17 P.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

We used  to joke about that at UoW, in the mid-1970's.



Right. Might be where we got it. Had lots of their
offshoots, WatFOR, WatFIV, WatCOB, there was clamor for
WatASS but everybody looked at us funny in the halls(more 
so than normal).   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Edward E. Jaffe]

Jim Phoenix wrote:

Try calculating a relative branch manually for a zap.  Don't forget to 
miscalculate or fat finger keying it in! ;-)



I've seen plenty of mistakes made zapping based branches as well.

Mistakes made while "hand assembling" instructions notwithstanding, my 
point was that a properly assembled relative branch will never be 
"wild". OTOH, a based branch -- even one that is assembled 100% 
correctly -- is dependent on the contents of its base register being 
correct at run time. If the base register becomes corrupted, all bets 
are off!


--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Tom Schmidt]

On Fri, 29 Jul 2005 15:25:49 -0700, Edward E. Jaffe
<[EMAIL PROTECTED]> wrote:

>Tom Schmidt wrote:
>
>>My reaction is similar to yours, Ed.  I had been wondering about the need
>>for some kind of "come from" display when IBM brought branch relative
long
>>instructions to the architecture.  The R15/R14 game seems like it falls
>>apart if the arrival at location 0 (or just arbitrary low storage) came
>>about because of a branch relative (jump) or worse, a BR-long.
>>
>>
>
>I'm glad you agree with me, Tom. But, I honestly don't see how the
>advent of relative branch has compounded this long-standing issue in any
>way. I consider the possibility of a relative branch becoming "wild" to
>be quite remote. (One of their chief benefits!) Remember, they don't
>depend on a GPR being loaded correctly and/or an associated USING being
>properly specified. They are always relative to the current PSW.
>
>For example, ,'BC 15,0(0,0)' will definitely go to location zero and
>leave no linkage trail in a register. How would you even code (on
>purpose or by accident) a BRC or BRCL to branch to location zero?
>Likewise, 'BAS xx,0(0,0)' will definitely go to location zero, but there
>will be a linkage register trail. Again, I don't see how you would even
>code the equivalent relative instructions BRAS or BRASL to branch there.

Never say never:  Consider a badly constructed base for an EXecute
instruction that "happens" to address an X'C0' "somewhere in virtual
storage".  The X'C0' is interpretted by the processor as a valid BRC
instruction and... off we go!

Granted this should be a rare event, but then the non-rare events are
supposed to be handled by the applications folks themselves thus leaving
these WTF-events to us to marvel over.

I have not come up with any cases where your favorite future instruction -
EXR - could cause such weirdness, by the way.

(There may be more wonderous cases to be found - I don't know (yet).)

--
Tom Schmidt
Madison, WI

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Tom Schmidt]

On Fri, 29 Jul 2005 15:25:49 -0700, Edward E. Jaffe wrote:
...snipped...
>For example, ,'BC 15,0(0,0)' will definitely go to location zero and
>leave no linkage trail in a register. How would you even code (on
>purpose or by accident) a BRC or BRCL to branch to location zero?

Here's a manufactured relative branch to low storage (I might miss
location 0 but I'll scare it from above at least).

So how about:
   LA R15,LOWRENT+L'LOWRENT  Beyond jump instruction's address
   SRLR15,1Compute number of halfwords to zero
   LNRR15,R15  zero is a "backwards jump"
   STCM   R15,B'',LOWRENT+2  Alter relative address in instr.
LOWRENT BRCL  15,0  Go fly off to (very) low storage (modified)

(Granted it may not be exactly zero but the idea s.b. clear now.)
That won't necessarily get you there in Amode 64 but will in 24 or 31 bit
mode.


>Likewise, 'BAS xx,0(0,0)' will definitely go to location zero, but there
>will be a linkage register trail. Again, I don't see how you would even
>code the equivalent relative instructions BRAS or BRASL to branch there.
>

>>Having the last successful branch displayed in dumps will help (as long
>>as the "branch from on high" isn't followed by a random branch down low
>>before the abend strikes; then all bets are off without an itrace).
>>
>
>Agreed re: a wild branch to a branch. In my experience, that's quite
>rare. Having the processor remember one branch instead of the last 'n'
>branches will probably help with 99% of the hard-to-diagnose wild branch
>cases. For the others, you could say we're still one branch closer to
>knowing what happened. :-\
>
>BTW, what is itrace? Do you mean system trace with branch tracing
>enabled? That won't trace the above instructions anyway. It traces only
>BALR, BASR, BASSM, BSA, BAKR (when 'r2' is non-zero), BSG, and RP ...
>not BC, BRC, BRCL, BAL, BAS, BRAS, or BRASL.

By "itrace" I meant a GTF SLIP instruction trace of the offending address
space.

>>Frequent culprits are the access method GET/PUT routines not being filled
>>in (due to OPEN failures that went unchecked) and those cases seem like
>>they'll be covered by the 'wild branch' display.  (Oh, joy!)
>>
>
>Excellent example!

I'm glad you agree.

I posted yesterday that there might be a possibility of an EXecuted BRCL
jumping to location zero (or a strange place, anyway) if the EXecute
target byte was X'C0'.  It would need to be more specific (and therefore a
little harder to believe) since it would need to be X'C0F4' or else the
EXecute register1 contents would need to OR-the byte following X'C0' so
that the result was X'F4'.  Less likely, sure, but possible -- and
devilishly difficult to track.

--
Tom Schmidt
Madison, WI

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Edward E. Jaffe]

Tom Schmidt wrote:


On Fri, 29 Jul 2005 15:25:49 -0700, Edward E. Jaffe wrote:
...snipped...
 


For example, ,'BC 15,0(0,0)' will definitely go to location zero and
leave no linkage trail in a register. How would you even code (on
purpose or by accident) a BRC or BRCL to branch to location zero?
   



Here's a manufactured relative branch to low storage (I might miss
location 0 but I'll scare it from above at least).

So how about:
  LA R15,LOWRENT+L'LOWRENT  Beyond jump instruction's address
  SRLR15,1Compute number of halfwords to zero
  LNRR15,R15  zero is a "backwards jump"
  STCM   R15,B'',LOWRENT+2  Alter relative address in instr.
LOWRENT BRCL  15,0  Go fly off to (very) low storage (modified)

(Granted it may not be exactly zero but the idea s.b. clear now.)
That won't necessarily get you there in Amode 64 but will in 24 or 31 bit
mode.
 



I think our "wires" got crossed somewhere...

I never suggested it was *impossible* to branch into PSA using a long 
relative branch. Obviously, if one branches into data or constants 
anything is possible. I simply pointed out that it's not possible to 
code such a branch in an assembler program. (Your pathological relative 
branch scenarios involving EXecute and/or self-modifying code help 
illustrate that point quite well.)


In other words, I never meant to imply one couldn't write code to 
*construct* a relative branch that goes to location zero. What I meant 
was that you couldn't assemble one in your program. Specifically, 'J 0' 
is totally invalid (will not assemble) whereas 'B 0' does exactly what 
you think it does -- branches to location zero. More to the point, 'J 
XXX' can *never* be "wild" whereas 'B XXX' can be "wild" any time the 
base register becomes corrupted or the USING is coded improperly.


I have long considered relative branches to be part of the solution .. 
not part of the problem.


--
-
| Edward E. Jaffe||
| Mgr, Research & Development| [EMAIL PROTECTED]|
| Phoenix Software International | Tel: (310) 338-0400 x318   |
| 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801|
| Los Angeles, CA 90045  | http://www.phoenixsoftware.com |
-

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Tom Schmidt]

On Sun, 31 Jul 2005 20:22:31 -0700, Edward E. Jaffe wrote:
>
>I never suggested it was *impossible* to branch into PSA using a long
>relative branch. Obviously, if one branches into data or constants
>anything is possible. I simply pointed out that it's not possible to
>code such a branch in an assembler program. (Your pathological relative
>branch scenarios involving EXecute and/or self-modifying code help
>illustrate that point quite well.)
>
>In other words, I never meant to imply one couldn't write code to
>*construct* a relative branch that goes to location zero. What I meant
>was that you couldn't assemble one in your program. Specifically, 'J 0'
>is totally invalid (will not assemble) whereas 'B 0' does exactly what
>you think it does -- branches to location zero. More to the point, 'J
>XXX' can *never* be "wild" whereas 'B XXX' can be "wild" any time the
>base register becomes corrupted or the USING is coded improperly.

I agree with your general position but for the "not possible" extreme.

For example, here is some assembler source that WILL branch to (or near,
depending on exactly where it is loaded) location 0:

BRCLTEST START 0
BRCLTEST AMODE 31
BRCLTEST RMODE 24
 PRINT NOGEN
 YREGS ,
BRCLTEST CSECT ,
 BASR  R12,0
*SRR1,R1
AHILEN   AHI   R1,1
 JLU   -UPEQU No WARNING IF SUP(058) ON EXEC PARM
LO2HERE  DSECT
UPLENDSXL(32730/2)
UPENDDS0X
UPEQUEQU   *-LO2HERE
 END   ,

Granted, it is (still) a largely pathological case since its branch to
location 0 depends on where the routine is loaded (on one of our LPARs it
hits 0 as-is, on another LPAR I needed to change the 32730 constant to
32756 to hit the target; that's why I BASR R12,0 - to help me hand-compute
the target).  The example is interesting in that the target address is not
within the CSECT.

What it demonstrates is that the assembler will let you shoot your toes off
even with a relative branch, by incorrect use of an EQU as a jump target.
In other words, a coding error at o'dark-thirty could still result in funky
behavior in spite of the coder's intentions and the architect's solid
attempt to prevent bad things.


>I have long considered relative branches to be part of the solution ..
>not part of the problem.

Here we agree completely -- they are PART of the solution, but not a
complete solution.  They are much, much, much better than what we had.

--
Tom Schmidt
Madison, WI

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Patrick O'Keefe]

On Fri, 29 Jul 2005 13:56:21 -0700, Edward E. Jaffe
<[EMAIL PROTECTED]> wrote:

>...
>z9 109 remembers the last successful branch instruction address and the
>operating system displays that address in dumps. ...
>
>My reaction? It's about time! Thank you, IBM!
>

I'm surprised it has taken IBM this long.  They had this built into the
37xx hardware thirty years ago.  The Lagging Address Register would
contain the address not taken by a branch.  The z hardfware and microcode
is a lot more complicated than the 37xx hardware was, but the concept was
viewed as useful way back then.

Pat O'Keefe

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Graeme Gibson]

ISTR that the 1401 had a LAR too.  Anyone else recall this?

Graeme.

At 05:41 AM 8/5/2005, Pat O'Keefe wrote:

...
>z9 109 remembers the last successful branch instruction address and the
>operating system displays that address in dumps. ...

I'm surprised it has taken IBM this long.  They had this built into the
37xx hardware thirty years ago.  The Lagging Address Register would


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Paul Gilmartin]

In a recent note, Graeme Gibson said:

> Date: Fri, 5 Aug 2005 16:50:35 +1000
> 
> ISTR that the 1401 had a LAR too.  Anyone else recall this?
> 
Hmmm.  An architecture with a LAR would have no need for a
BALR-type instruction; the called routine could simply save
the LAR.

Hmmm.  The LAR would need to be preserved through interrupts.

> At 05:41 AM 8/5/2005, Pat O'Keefe wrote:
> >...
> > >z9 109 remembers the last successful branch instruction address and the
> > >operating system displays that address in dumps. ...
> >
> >I'm surprised it has taken IBM this long.  They had this built into the
> >37xx hardware thirty years ago.  The Lagging Address Register would

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Robert A. Rosenberg]

At 19:07 -0400 on 07/29/2005, Ed Finnell wrote about Re: Wild Branch 
Diagnosis (Was: Five Digit Device Numbers):



Right. Might be where we got it. Had lots of their
offshoots, WatFOR, WatFIV, WatCOB, there was clamor for
WatASS but everybody looked at us funny in the halls(more
so than normal).


WatASS actually existed - It was called Assembler G. There was even 
some code in a HASP Routine that processed Object Decks to support 
the Object Decks it output (I think it had to do with better RLD 
Cards where ASMG output the cards with more entries per card in some 
cases compared with the IBM ASMF/ASMH Assemblers).


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Ed Finnell]

 
In a message dated 8/7/2005 12:01:44 A.M. Central Standard Time,  
[EMAIL PROTECTED] writes:

WatASS  actually existed - It was called Assembler G. There was even 
some code in  a HASP Routine that processed Object Decks to support 
the Object Decks it  output (I think it had to do with better RLD 



>>
Think I was leaving as they were converting to RCA/Serry/UNIVAC
so the clamor died down. Then the Minis started firing up. PDP/8
there Varian somewhere else RCA110A in EE and one of PFCSK's discovered  X/PL 
from UCLA or STANFORD. Got several emulators rolling pretty good. He went  
over to Music department to help with the Varian and next thing I heard he's  
headed off to Muscle Shoals to be a studio musician. Asta la  vista. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 08/05/2005
   at 04:50 PM, Graeme Gibson <[EMAIL PROTECTED]> said:

>ISTR that the 1401 had a LAR too.  Anyone else recall this?

The Store B Register (SBR) instruction could be used for subroutine
linkages. I have mercifully forgotten the details.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Wild Branch Diagnosis (Was: Five Digit Device Numbers)

[Gerhard Postpischil]

Robert A. Rosenberg wrote:
WatASS actually existed - It was called Assembler G. There was even some 
code in a HASP Routine that processed Object Decks to support the Object 
Decks it output (I think it had to do with better RLD Cards where ASMG 
output the cards with more entries per card in some cases compared with 
the IBM ASMF/ASMH Assemblers).


It had other peculiarities. "Mad man" Metz used SETCs with long strings 
to test whether or not the running assembler was G or IBM's F, which 
truncated at 8 bytes. Waterloo G if I recall correctly supported 80 bytes.


And it had a peculiarity that never got fixed. When you had a character 
string with embedded apostrophes, properly doubled, and the first of the 
pair landed in column 71, the compiler treated the continuation as comments.


Gerhard Postpischil
Bradford, VT

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html