It's important to note that the reservation of x'80000000' through x'FFFFFFFF' is merely to help avoid addressing issues, as well-explained previously. It's not a fundamental issue at all, and the architecture itself doesn't have any such restriction.
Also, you CAN allocate memory in this area (which was extended to x'7_FFFFFFFF'). There's an undocumented keyword on IARV64 called something like USE2GTO32G. You can expect no one to help you debug storage overlays if you decide to do that! I read somewhere that Java wanted this area because it could "compress" pointers to 4 bytes. I presume that they only need to address to doubleword granularity, and so can shift the address 3 bits to the right to store it in a 4-byte word (and conversely shift left 3 bits to use it). Addresses up to 32G are the maximum that will fit in that scheme, and that's where the "restricted" area now ends. I don't know why Java (or anyone else) would really need to do that - I'd think just going to 8-byte addresses would be more sensible. But there it is. On Wed, Nov 5, 2014 at 9:18 AM, Paul Gilmartin < [email protected]> wrote: > On 2014-11-05, at 01:27, Bernd Oppolzer wrote: > > > Maybe it can be explained this way: > > > > when we migrated from 24 bit to 31 bit, we had lots of problems > > when loading 24 bit addresses (for example parameter addresses) > > from fullwords and using them in 31 bit mode, > > and the addresses had some non zero values in the first (leftmost) byte > > of the register (which was no problem in 24 bit mode). There was no way > > around this but to clean the register's first byte before doing the > storage > > address (if the address was a 24 bit address in the beginning). > > > > Now we have the same situation; the leftmost bit of the fullword is > > ignored when using the addresses in storage access (in 31 bit mode), > > be it 0 or 1 ... and it is 1 sometimes. > > > > When expanding a 31 bit address to 64 bit, simply by adding 32 zero > > bits on the left or by loading a fullword into the right half of a 64 > bit register, > > the 31 bit address will be the wrong address, if the leftmost bit in the > fullword > > was set. > > > A similar approach as for 24 to 31 bit conversion applies. Simply > clear bit 0. > > > But this time we have the chance to flag such errors, simply by > excluding this > > address range (0x00000000_80000000 to 0x00000000_FFFFFFFF) from > > the range of allowable 64 bit addresses in z/OS. It is, given the overall > > address range, not too large. > > > Are you suggesting that someone might do 64-bit STORAGE OBTAIN and save > only low-order fullword. This will certainly cause problems, but those > are not solved by excluding that address range. Or that someone do 64-bit > STORAGE OBTAIN and decide based on whether the high-order fullword is 0 > that it suffices only to store the right half? > > I still don't envision a plausible scenario in which a problem is avoided > by excluding that range of addresses. Supply context. > > More: > > I understand that BASSM sets bit 63 of the return address to indicate > that the return address is to AMODE 64. Does Content Supervision > follow the same convention, setting bit 63 when LOADing an AMODE 64 > module? > > Hmmm. I believe I can declare an ENTRY at an odd offset from the CSECT. > (It had better be data, not a branch target.) I can make that ENTRY an > ALIAS for my module. When I LOAD it, how can I tell if it the address > returned with bit 63 set indicates an AMODE 64 CSECT or an actual odd > address. > > Perhaps the answer is, "Don't do that!" > > Does Binder resolve 31-bit V-CONs setting bit 0 to indicate AMODE 31? > Does Binder resolve 64-bit V-CONs setting bit 63 to indicate AMODE 64? > > -- gil > -- sas
