See my other post also; there should be a separation between the
(address) registers
that have continent information in the upper half and the other that
have not.
The compiler which generates the code takes care about this.
When a runtime function is called, this function will probably need a
service which
implies AMODE/RMODE 24. This means that the (Pascal) code will call the
runtime, which
resides below 16 MB. The details of the parameter passing have to be
designed;
maybe the Pascal code must be able to access the LOC=24 storage before
the runtime
call by manipulating certain address registers. Or, it uses the
remaining registers
(3, 5, 7, 9, 11), which don't contain continent information in the upper
half by default.
Inside the runtime, the AMODE switch is done.
Kind regards
Bernd
Am 11.05.2018 um 21:14 schrieb Paul Edwards:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
