TSS/360 used an explicit length at offset -4 from the parameter list, so the end-of-list bit wasn't an issue.
The addresses transition from 7FFFFFFF_FFFFFFFF to 80000000_00000000 is a z/OS issue rather than an architectural issue. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Tom Marchant <[email protected]> Sent: Wednesday, November 27, 2019 11:41 AM To: [email protected] Subject: Re: BASR to AMODE 64 On Tue, 26 Nov 2019 10:29:32 -0700, Paul Gilmartin wrote: >I believe the greater accommodation was the hardware architecture's >expanding from 24-bit addressing to only 31 rather than 32 because >software so pervasively uses the sign bit for a flag. I don't think so. I don't have any information from the designers of 370/Extended Architecture either,, but, the System/360 model 67 had a 32-bit addressing mode, determined by bit 4 of the PSW. This bit could be modified by a Set System Mask (SSM) instruction, as well as by LPSW. Both of these are privileged instructions, and there was no way for a problem state program program to change the addressing mode. I agree with Peter about the desirability of including AMODE information along with an address. In addition, there are issues with performing arithmetic operations on addresses. Unsigned arithmetic must be used to do it correctly. The Model 67 Functional Characteristics manual (available on bitsavers) has this note for BXH: <quote> When BRANCH ON INDEX HIGH is used for address modification in a 2067 that is equipped with 32-bit addressing and bit 32 is a 1 as a result of address modification, the resulting address will be treated as a negative quantity during the compare process; this can result in an erroneous branch. For that magnitude of address manipulation, care must be taken in the use of this instruction. </quote> The description of BXLE doesn't repeat the caution, but references the one for BXH. The authors of the z/Architecture POO have not given this quite as careful consideration with this note: <quote> Care must be taken in the 31-bit addressing mode when a data area in storage is at the rightmost end of a 31-bit address space and a BRANCH ON INDEX HIGH (BXH) or BRANCH ON INDEX LOW OR EQUAL (BXLE) instruction is used to step upward through the data. Since the addition and comparison operations performed during the execution of these instructions treat the operands as 32-bit signed binary integers, the value following 2^31 - 1 is not 2^31, which cannot be represented in that format, but -2^31. The instruction does not provide an indication of such overflow. Consequently, some common looping techniques based on the use of these instructions do not work when a data area ends at address 2^31 - 1. This problem is illustrated in a BRANCH ON INDEX LOW OR EQUAL example in Appendix A, “Number Representation and Instruction-Use Examples.” A similar caution applies in the 64-bit addressing mode when data is at the end of a 64-bit address space and BRANCH ON INDEX HIGH (BXHG) or BRANCH ON INDEX LOW OR EQUAL (BXLEG) is used. </quote> Actually, the problem with BXHG and BXLEG is not "at the end of a 64-bit address space", but in the middle of the 64-bit address space, when the addresses transition from 7FFFFFFF_FFFFFFFF to 80000000_00000000. -- Tom Marchant
