Clarification on unconditional Branch to Label Instruction



High Level Assembler(HLASM) for MVS & VM & VSE

Clarification on unconditional Branch to Label Instruction

Postby ramkumar1992sp » Fri Jan 27, 2017 11:12 pm

        B     SETOP(R1)          
SETOP    LR    R1,R7              
         BR    RE                
         LR    R1,R5              
         BR    RE                
         LR    R7,R5              
         BR    0                  
         LA    RC,CHKTWIN        
         LR    R1,R7              
BYOP     EQU   *                  
         LH    R0,16(R4)  



Does B SETOP(R1) mean branch to the address of SETOP + the number of bytes in R1.

So if R1 is 0 then branch to SETOP LR R1,R7
If R1 is 4 then branch to SETOP LR R1,R5
If R1 is 8 then branch to SETOP LR R7,R5
If R1 is 12 then branch to SETOP LA RC,CHKTWIN ? Since the instructions in between takes 4 bytes.Is my understanding correct?

Also why do we have
BYOP     EQU   *
?Here I think we are equivating the current address to BYOP but why ? Can't we just have
BYOP LH    R0,16(R4)
?
ramkumar1992sp
 
Posts: 71
Joined: Sat Jul 23, 2016 8:52 am
Has thanked: 40 times
Been thanked: 0 time

Re: Clarification on unconditional Branch to Label Instruction

 

Re: Clarification on unconditional Branch to Label Instructi

Postby Robert Sample » Fri Jan 27, 2017 11:16 pm

For your latter question, if you later have to do maintenance on the code and add an instruction before the LH R0,16(R4) -- having BYOP EQU * means you can do so easily by inserting the line between this line and the LH line. However, if the BYOP is on the LH instruction, you'll have additional work to move the BYOP to the correct location.

These users thanked the author Robert Sample for the post:
ramkumar1992sp (Sat Jan 28, 2017 12:23 am)
Robert Sample
Global moderator
 
Posts: 3531
Joined: Sat Dec 19, 2009 8:32 pm
Location: Dubuque, Iowa, USA
Has thanked: 1 time
Been thanked: 252 times

Re: Clarification on unconditional Branch to Label Instructi

Postby ramkumar1992sp » Sat Jan 28, 2017 12:23 am

Thanks Robert.
ramkumar1992sp
 
Posts: 71
Joined: Sat Jul 23, 2016 8:52 am
Has thanked: 40 times
Been thanked: 0 time

Re: Clarification on unconditional Branch to Label Instructi

Postby ramkumar1992sp » Sat Jan 28, 2017 12:38 am

I'm just rephrasing my first question since I felt it wasn't clear earlier.

So if R1 contains a value of 0 in it then branch to SETOP LR R1,R7
If R1 contains a value of 4 in it then branch to SETOP LR R1,R5
If R1 contains a value of 8 in it then branch to SETOP LR R7,R5
If R1 contains a value of 12 in it then branch to SETOP LA RC,CHKTWIN ? Since the instructions in between takes 4 bytes.Is my understanding correct?
ramkumar1992sp
 
Posts: 71
Joined: Sat Jul 23, 2016 8:52 am
Has thanked: 40 times
Been thanked: 0 time

Re: Clarification on unconditional Branch to Label Instructi

Postby steve-myers » Sat Jan 28, 2017 12:23 pm

XX EQU * in a stream of instructions.

This is actually a little controversial. Mr. Sample gives excellent reasons why it's a good thing. Others, like me, avoid it. Why? Two words: boundary alignment. In System/360 derived architectures, an instruction must be on a half word boundary to execute. EQU * does not imply boundary alignment, so it is possible the symbol it defines will not be on a half word boundary.

HASP for OS/360 included the NULL programmer macro, something like:
         MACRO
&NAME    NULL
&NAME    DS    0H
         MEND


It was used as

symbol NULL

The symbol would automatically aligned on a half word boundary, so it could be (and was) used in place of EQU *.

Now I am not saying Mr. Sample is wrong. When it seems appropriate, I will use

symbol DS 0H rather than EQU *.
steve-myers
Global moderator
 
Posts: 1953
Joined: Thu Jun 03, 2010 6:21 pm
Has thanked: 4 times
Been thanked: 210 times

Re: Clarification on unconditional Branch to Label Instructi

Postby ramkumar1992sp » Mon Jan 30, 2017 8:37 pm

Thanks Steve.
ramkumar1992sp
 
Posts: 71
Joined: Sat Jul 23, 2016 8:52 am
Has thanked: 40 times
Been thanked: 0 time


Return to Assembler

 


  • Related topics
    Replies
    Views
    Last post