None of the existing instructions modifies access registers (AR's). You must use AR specific commands to modify them (e.g. LAM, LAE, SAR).
This is good because you must specifically use these instructions to manipulate AR's. 1. It keeps exceptions to how instructions function to a minimum (e.g. LAE always sets AR and LA nevers sets it). 2. Programs are easier to maintain because AR's don't get inadvertently modified (e.g. LA R4,5 doesn't change AR4 to 0). 3. You don't have to worry about macro's and called programs inadvertently modifying access regs. 4. It keeps instruction overhead down (e.g. LA is used alot so adding AR copy adds to it's time). Regards, Jon Perryman. ________________________________ From: John McKown <[email protected]> To: [email protected] Sent: Wed, April 11, 2012 2:32:59 AM Subject: Re: curiosity: In AR mode, why doesn't BALR/BASR/BRAS/BRASL set the value of the corresponding AR register ? True, I was thinking of being in secondary addressing mode. Peter Relson has consistently said of home space mode: "Don't even consider it!". So I didn't. It is one of those "forbidden" states unless you've got a lot of internals information. On Wed, 2012-04-11 at 08:26 +0000, [email protected] wrote: > Edward Jaffe <[email protected]> wrote > > > On 4/10/2012 11:31 AM, McKown, John wrote: > >> But that made me wonder why the z/Architecture does not specify that the > >> contents of the AR register associated with the link register in any of > >> the "branch and link" type instructions: BALR, BASR, BRAS, BRASL, and > >> BASSM will be set to 0? > >> > >> Anybody have any idea why these type of instructions don't set the AR? > > > > Unnecessary. Instruction fetch is always from the primary address space. > > No, in Home-space mode instructions are fetched from the HASN. > > Since you can't branch out of the current address space with any of the > instructions you listed, there is no reason to test or manipulate the AR. -- John McKown Maranatha! <><
