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
