Good point. But note that if the application also uses LOC=24 or LOC=31 storage, that will need to be in an address register that has the upper 32 bits as 0.
BFN. Paul. On Fri, 11 May 2018 14:09:59 -0500, Mike Schwab <mike.a.sch...@gmail.com> wrote: >If you stick with 32 bit arithmatic instructions, it does not use the >upper 32 bits. of each register, so having the upper 32 bits set like >the address register does no harm. > >On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer ><bernd.oppol...@t-online.de> wrote: >> What I found most interesting in this whole thread was a suggestion >> from (IIRC) a SAS guy some days before. He suggested, if I understood >> it correctly, that a large application should run in AM64, but store >> internally >> only 32 bit pointers; the left half of all registers used as address >> registers >> containing the same (nonzero) value all the time ... as long as the current >> "continent" (defined by this nonzero value in the left half) is not exited. >> >> This could be a pattern for compiler writers, too, IMO, and has some >> implications: >> >> you need a separation of address registers and arithmetic registers >> internally; that is: the compiler has to know all the time which one >> out of the 16 general registers is used for what, and it has to do >> some housekeeping on this. And: passing control to another >> "continent" is somehow complicated. >> >> But imagine what you get for this: no need to change all the pointer >> fields from 4 byte to 8 byte. I find this very promising. Every seperately >> compiled "unit" should fit into one continent, anyway ... >> >> As you might probably know, I am the maintainer of the New Stanford >> Pascal compiler; if I ever reach the point where generating 64 bit code >> gets interesting, I will think more about this option. At the moment, >> even 31 bit would be very nice, because I am still bound to AMODE 24. >> >> Stanford Pascal website: http://bernd-oppolzer.de/job9.htm >> on Facebook: https://www.facebook.com/StanfordPascal/ >> on GitHub: https://github.com/StanfordPascal/Pascal >> >> Kind regards >> >> Bernd >> >> >> >> >> >> Am 11.05.2018 um 17:48 schrieb John McKown: >>> >>> On Fri, May 11, 2018 at 9:10 AM, Wayne Driscoll < >>> wdrisc...@rocketsoftware.com> wrote: >>> >>>> Paul, >>>> Unlike Hercules, z/Architecture is part of a business, and, as such, a >>>> business value needs to be made in order to get support for changes, in >>>> particular radical changes like AM32. "it would be nice" and "but it's so >>>> cool" aren't business rationalizations for the amount of potentially >>>> broken >>>> customer code that would result from the change you propose. In order to >>>> not have to recompile all applications, or maintain strict bounds between >>>> 32 bit apps and 64 bit apps like most other 64 bit architectures, I will >>>> gladly sacrifice 2 GiB out of the massive virtual space offorded by a 64 >>>> bit address space. If your mythical AM32 was invented, applications would >>>> still have to switch back to AM31 before calling other AM31 code that >>>> expects a variable length paramter list. I still fail to see any business >>>> value to IBM's customers in what you are proposing. >>>> >>> The real solution is to go back to the 1960s and tell the OS/360 >>> developers to not use bit 0 as an "end of list" indicator. If OS/360 had >>> used either an initial half(or full) word which indicated how many >>> addresses were in the list following or, similar to CMS, had indicated the >>> end-of-list with a fullword of high values (x0FFFFFFFF), then when the >>> architecture was extended to "beyond 24 bit addresses", they could have >>> use >>> AMODE(32) and we wouldn't be having this discussion. AMODE(31) is, IMO, >>> the >>> direct result of this "problem" in the design of OS/360. Of course, the >>> OS/360 design made finding the end-of-list "easier" and did not "waste" a >>> fullword of storage. I guess back in the day, that was a very big >>> consideration. >>> >>> >>> >>>> Wayne Driscoll >>>> Rocket Software >>>> Note - All opinions are strictly my own. >>>> >>> >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > >-- >Mike A Schwab, Springfield IL USA >Where do Forest Rangers go to get away from it all? > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
