It would be nice if the doc explicitly stated the contents of R14 when entered
in 64 bit mode, that R14 is a pure address without flags..

On Sun, 17 Aug 2025 03:58:13 +0000 James Mulder <[email protected]> wrote:

:>  The code which Peter Relson put into module CSVRBBLD in 1998 says:
:>
:>XSBG64HE = 0;                   /* Make sure return in 64-bit       
:>                     mode will work. If he BR's back, this will be   
:>                     OK. If he BSM's back, he'll be in 24-bit        
:>                     AMODE which is OK.                            */
:>/* We set the high order bit of GPR 14 so that the target            
:>   routine can tell if the caller is AMODE 24 or 31.                 
:>   But as GPR 14 is also used as a return register, we cannot        
:>   do this for the AMODE 64 target: if we set the low order          
:>   bit, that would require the target to BSM back. If it issued      
:>   BR, that would program check.                               @L8A*/
:>IF ¬NewPRBP->PswINRB.PswAMODE64 THEN  /*                       @L8A*/
:>  IF EXSA31MS=ON THEN            /* caller in 31/64 bit mode?  @L8C*/
:>     RBGRS14=RBGRS14|MODEBIT;      /* yes, indicate so to exit rtn */
:>  ELSE;                          /* caller in 24 bit mode  @ZMC1694*/
:>ELSE DO;                         /* Target is AMODE 64         @L8A*/
:>  ;                              /* We cannot do anything except     
:>                                    provide a "normal" address here  
:>                                    so that the return in AMODE 64   
:>                                    will work OK               @P6A*/
:>
:>The LINK/LINKX documentation says:
:>
:>14
:>    Contains the return address the called module will return to. If the 
high-order bit of this register is on, the issuer of the LINK or LINKX macro is 
running in 31-bit mode; if off, the issuer is running in 24-bit mode.
:>15
:>    Requested program's entry point address
:>    When the target of the LINK or LINKX is AMODE(64), then reg 15 contains
:>
:>    xxxxxxxY
:>
:>where Y is:
:>
:>    0 if the caller was AMODE 24
:>    2 if the caller was AMODE 31
:>    4 if the caller was AMODE 64
:>
:>The ATTACH/ATTACHX documentation says:
:>
:>14
:>    Return address. Bit 0 is 0 if the subtask routine gets control in 24-bit 
addressing mode; bit 0 is 1 if the subtask routine gets control in 31-bit 
addressing mode.
:>15
:>    When the subtask routine is to run in 24-bit or 31-bit addressing mode, 
the entry point address of the subtask routine.
:>    When the subtask routine is to run in 64-bit addressing mode, it is 
expected to use relative branching and register 15 contains a value that can be 
used to determine the addressing mode of the issuer of the ATTACH or ATTACHX 
macro as follows:
:>
:>        Issuer AMODE 24: X'FFFFF000'
:>        Issuer AMODE 31: X'FFFFF002'
:>        Issuer AMODE 64: X'FFFFF004'
:> 
:>Jim Mulder
:>
:>-----Original Message-----
:>From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
Jon Perryman
:>Sent: Saturday, August 16, 2025 7:35 PM
:>To: [email protected]
:>Subject: Re: Running a program RMODE64
:>
:>>That has nothing to do with whether the target module can be RMODE64. 
:>                                                                           
:>R15 is the target module address (not R14).=20                             
:>                                                                           
:>>>Since RMODE is not documented for ATTACHX, RMODE64 is not supported. 
:>                                                                           
:>>>Therefore, R14 will never be above the bar (64 bit address).             
:>>False. That says you must not invoke ATTACHX in RMODE64.=20               
:>                                                                           
:>R14 (return address) refers to the ATTACHX module (not target module) whi= 
:>ch as we both agree can never be RMODE64. R14 can handle but can the addr= 
:>ess be above the bar with the RMODE64 restriction?                         
:>                                                                           
:>>>R14 is "return address" which implies R14 will always be a valid addres= 
:>s regardless of the AMODE. 
:>                                                                           
:>You included this as part of the snip which needs some clarification. Are= 
:> you saying that R14 might not be valid for the AMODE upon entry and that= 
:> we should be using BSM instead of BR? Is IEFBR14 actually a BSM now? Thi= 
:>s is going to be a hard habit to break.                                    
:>                                                                           
:>>:>ROTFLOL, this is why RMODE capability shouldn't be documented as a 
requirement. Out of sight, out of mind.
:>>What does RMODE have to do with it? My statement was regarding AMODE.
:>>The R14 values for both 24 & 31 bit are appropriate for BSM and 
coincidentally BR.
:>
:>IBM has geniuses developing simple yet effective solutions to problems. RMODE 
plays a huge role in AMODE but is not always blatantly obvious. 
:>
:>For ATTACHX, what do we know about R14 (return address) because RMODE64 is 
prohibited? Since the load module is required to be RMODE31 or RMODE24, R14 
will always be a valid address below the bar (31-bit). It may be in a 64-bit 
register but is guaranteed to be a valid address below the bar. IBM does not 
document 64-bit R14 because it is not possible. You can argue it should be 
documented but RMODE restriction tells us the valid R14 values.
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to [email protected] with the message: INFO IBM-MAIN

--
Binyamin Dissen <[email protected]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to