On Thu, 09 Dec 2010 10:36:43 -0500, Tom Marchant <[email protected]> wrote:
Prior to that, it is true that that IARV64 would never create a memory object in the range from 2GB to 4GB. That was an arbitrary decision intended to avoid confusion. As I understand it, there was some concern that a user might see an address with bits 0-31 all zero and bit 32 on and be confused. Is it a 31-bit address with the high order bit on to signify AMODE(31) or is it a 64-bit address? It seems to me that it hes led to considerable other confusion.
It was more than to avoid "confusion". It was to prevent code that used the high order bit of 32-bit registers as a flag bit (yes, usually to indicate AMODE, but not always) and was changed to run in 64-bit mode from accidentally "working", where "working" means clobbering storage between the 2G and 4G area or, at the very least, picking up the wrong data from that area. The z/OS folks made a wise decision to burn a teeny bit of storage (for the extra page table entries) in the interest of reliability. This is also the reasoning behind the IARV64 guard bands and I encourage people to use these generously. I can attest that making the addresses from 2G to 4G unaddressable along with guard band support has been very effective in catching bugs in the 64-bitting of code. If possible, it's also a good idea to put junk into the high order 32 bits of registers at strategic points to try to ensure that code is using proper hygiene in loading addresses into registers (using LLGF/LGF rather than L). Unfortunately, it's all too easy for code to accidentally work in 64-bit mode because someone happened to clear the high order 32 bits of some register shortly before the accidentally working code. And, as we all know, code that works by accident today, might not work tomorrow. -- Cheers, Alex Kodat Sirius Software
