On Fri, May 11, 2018 at 12:22 PM, Bernd Oppolzer <[email protected] > 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 > All of this "continent" stuff basically makes me think of "far pointers" in the segmented (16 bit) Intel era. A far pointer was 32 bit field in which the upper 16 bits was loaded into the ES(?) segment register and the lower 16 bits into the ? register. The continent methodology is similar except that each "register" is 32 bits and both together are actually kept in a single 64 bit register. I am guessing that the continent portion would use the LFH to be loaded into the high word of the register, and just a plain L to load the "offset within continent" into the low word of that register. The "crossing continent" makes me wonder. If one could require that any single object reside in a single continent, then it might be possible to use the IARV64 interface to use a "guard" area to cause an exception if the code tries to overflow from one continent to another. -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
