On 05/07/2018 07:39 AM, Tom Marchant wrote: > On Sun, 6 May 2018 15:00:23 -0500, Paul Edwards wrote: > >> As far as I can tell, the BAR exists for the same >> reasons that 16 MiB LINE exists - historical >> curiosity. > Right. And compatibility > >> No reason to be stuck with that forever. >> Most other 32-bit programming environments >> allow access to the full 4 GiB and z/Arch is >> capable of delivering the same functionality >> to z/OS users. > You can argue over the wisdom of IBM going to 31-bit addressing with > 370/Extended Architecture in 1982. You can also argue about the wisdom > of their decisions around managing the nearly 8 PB above the bar > differently than the 2 GB below it. These are decisions that were made > long ago. Jim has offered you a suggestion that will give you what you > are asking for - a way to allocate storage in the range from 2 GB to 4 GB. > > The notion that you want z/Architecture to behave like it supports 32-bit > addressing is silly. > > That's my opinion, and there is no way I will support your RFE. > One of the big advantages of IBM mainframes (since S/360) has been upward compatibility for application code. Unlike other platforms, you don't have to redesign application assembly code or re-compile all application programs just because of an operating system upgrade or an architecture upgrade. Documented application code interfaces continue to be compatible.
>From the early days of S/360 the high-order bit of a full-word address pointer has a documented function in standard subroutine linkage of indicating the last parameter address for subroutines that accept a variable number of parameters, so even if the architecture might not restrict using that bit for memory addressing, long-standing software standards for AMODE24 and AMODE31 do. Changing the documented conventions for using the high-order bit of a 32-bit address word to create a new "AMODE32" would potentially adversely effect too many things for minimal benefit. Not going to happen, since there are already much less disruptive alternatives available for large in-memory code (AMODE64) and large in-memory data (Dataspaces); and there are ways to mix both of those approaches with AMODE31 code if you don't want to go the full AMODE64 route. Most of the peculiarities in z/OS aren't preserved for their historical curiosity value, but to avoid breaking functional application code. That is a design philosophy that large corporations with thousands of existing programs with functional application code tend to appreciate. Joel C. Ewing -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
