Reading to cure insomnia: There may be a real reason why Paul's wording of an RFE "perhaps" "might" "possibly" be a non-started?
The requests had no suggestions for 32-bit programs. Non-U.S. based Paul just has issues with English. There were no suggestions for AMODE 32. Non-U.S. based Paul just has issues with English. There is no issue with non-AMODE 64 parameter lists. There is no issue with writing or rewriting code. The wild tangents dreamed up to claim why GETMAIN LOC=2GB.to.4GB-1 is an issue are dreamed up wild tangents. ELSQA memory fragmentation is a minor inconvenience for people using the requested feature only. IARV64 REQUEST=GETSTOR losing 2GB out of 16XB or JAVA area losing 2GB is sad but I'm not crying. But there is a real reason why GETMAIN LOC=32 may have an issue. Dr. Gene claimed that the reason that IBM dropped from AMODE 32 to AMODE 31 was because of a typo in the Principals of Operation for BXH/BXLE. Translated, even S360-24bit used algebraic 32 bit addresses for BXH/BXLE to allow negative displacements. Algebraic indexing from 2GB-1 to 2GB gives the higher address a negative number so it is lower than the low address. There should be logical BXH/BXLE equilavants but are not. Was IBM switching from AMODE 32 to AMODE 31 better than just adding logical equivalents for BXH/BXLE ? Of course, the data area is requested for AMODE 64 programs so using BXH/BXLE in AMODE 31 has no relavances to the GETMAIN change request. But I checked the manuals. See below. You can skip to the last note which is for the zArch for BXH/BXHG/BXLE/BXLEG to see the issue. I had to change the format for exponentiation because I post in plain text. Sorry. Copy/Paste from OCRed .pdf file could also introduce some errors. Sorry again. Of course, Paul will say that all is AMODE 64 with all 64 bits registers so both switching to AMODE 31 and using BXH/BXLE on the 2GB to 4GB-1 memory should cause the issue the programmer asked for. Using the proper AMODE 64 or the proper AMODE 64 instructions BXHG/BXLEG does not have the issue with 32 bit algebraic values. I can't fix the problem with Paul calling the using of addresses from zero to 4GB-1 a 32-bit system. It's AMODE 64, it works no difference than GETMAIN LOC=24 or GETMAIN LOC=31 when used by an AMODE 64 program. No difference than a 24 bit address being stored in an 8 byte register. Yes, the high order 5 bytes are zero but that is a given. Can't fix Paul. A22-6821-0 IBM System/360 Principles of Operation Really old and not dated Pages 64 and 65 Branch On Index High BXH RS The second operand is added to the first operand, and the sum is compared algebraically with the third op- erand. Subsequently, the sum is placed in the first operand location, regardless of whether the branch is taken. When the sum is high, the instruction address is replaced by the branch address. When the sum is low or equal, instruction sequencing proceeds with the updated instruction address. The first and the second operands are in the registers specified hy Rl and R3. The third operand register ad- dress is odd and is either one larger than R3 or equal to R3. The branch address is determined prior to the addition and comparison. Overflow caused by the addition is ignored and does not affect the comparison. Otherwise, the addition and comparison proceed as in fixed-point arithmetic. All 32 bits of the general registers participate in the opera- tions, and negative quantities are expressed in two's- complement notation. When the first and third oper- and locations coincide, the original register contents are used as third operand. Condition Code: The code remains unchanged. Program Interruptions: None. Programming Note The name "branch on index high" indicates that one of the major purposes of this instruction is the incre- menting and testing of an index value. The increment may be algebraic and of any magnitude. SA22-7832-10 z/Architecture Principles of Operation March 2015 Pages 7-39 and 7-40 BRANCH ON INDEX HIGH BXH R1,R3,D2(B2) [RS-a] BXHG R1,R3,D2(B2) [RSY-a] BRANCH ON INDEX LOW OR EQUAL BXLE R1,R3,D2(B2) [RS-a] BXLEG R1,R3,D2(B2) [RSY-a] An increment is added to the first operand, and the sum is compared with a compare value. The result of the comparison determines whether branching occurs. Subsequently, the sum is placed at the first- operand location. The second-operand address is used as a branch address. The R3 field designates registers containing the increment and the compare value. For BRANCH ON INDEX HIGH, when the sum is high, the instruction address in the current PSW is replaced by the branch address. When the sum is low or equal, normal instruction sequencing pro- ceeds with the updated instruction address. For BRANCH ON INDEX LOW OR EQUAL, when the sum is low or equal, the instruction address in the current PSW is replaced by the branch address. When the sum is high, normal instruction sequencing proceeds with the updated instruction address. When the R3 field is even, it designates a pair of reg- isters; the contents of the even and odd registers of the pair are used as the increment and the compare value, respectively. When the R3 field is odd, it desig- nates a single register, the contents of which are used as both the increment and the compare value. For purposes of the addition and comparison, all operands and results are treated as 32-bit signed binary integers for BXH and BXLE or as 64-bit signed binary integers for BXHG and BXLEG. Overflow caused by the addition is ignored. The original contents of the compare-value register are used as the compare value even when that regis- ter is also specified to be the first-operand location. The branch address is generated before general reg- ister R1 is changed. The sum is placed at the first-operand location, regardless of whether the branch is taken. Condition Code: The code remains unchanged. Program Exceptions: • Transaction constraint Programming Notes: 1. Several examples of the use of the BRANCH ON INDEX HIGH and BRANCH ON INDEX LOW OR EQUAL instructions are given in Appendix A, “Number Representation and Instruction-Use Examples.” 2. The word “index” in the names of these instruc- tions indicates that one of the major purposes is the incrementing and testing of an index value. The increment, being a signed binary integer, may be used to increase or decrease the value in general register R1 by an arbitrary amount, sub- ject to the limit of the integer size. 3. Care must be taken in the 31-bit addressing mode when a data area in storage is at the right- most 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 per- formed during the execution of these instructions treat the operands as 32-bit signed binary inte- gers, the value following 2 to the 31st -1 is not 2 to the 31st, which cannot be represented in that format, but -2 to the 31st. 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 to the 31st - 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. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
