Am 11.05.2018 um 19:34 schrieb Paul Edwards:
On Fri, 11 May 2018 19:22:22 +0200, 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:
Note that he achieved this by allocating 4 GiB
above the 4 GiB bar, in order to get 2 GiB. While
this technique certainly has its merits, it would
be easier to write the compiler if IBM simply
provided an IARV64 GETSTOR USE2GBTO4GB.
Although that wouldn't guarantee a full 2 GiB
like he was able to get with his technique.
I don't think that he gets only 2 GiB;
because the application uses AMODE 64, all 64 bits take part
of the addressing, and that means that all 32 low bits are part of
the address. Every L and ST of addresses loads only the lower part
of the address from storage to register (or the other way round);
the higher part is already there.
You only have to take care if you do arithmetic with all 64 bits of
a register, which changes the upper half, that you do this
either with a register that is not used for addressing or
that you restore the "continent" in the upper half after this
arithmetic.
A branch to another program unit which resided in another
"continent" has to change all upper halfs of all registers that
are used for addressing, accordingly. If there is a (sort of) convention
that tells what registers are used for addressing, you can keep
the places minimal where "continent information" needs to be saved,
loaded or restored.
For example: I'm not really familiar with the new 64 bit instruction,
but there must be an instruction similar to MVCL, involving two
64 bit address registers and two length registers. In this case, the
even registers (containing the addresses) should have the continent
information, but the odd registers (containing the length) should not.
Maybe this would be a simple convention:
even register numbers have continent information in the left half by
default, and odd registers don't have it. Exceptions for the registers 13,
15 and 1, which have continent information, too - due to their role
in the linkage process.
This would leave the registers 3, 5, 7, 9, 11 as pure "data" registers,
where all 64 bits can be changed freely without thinking about the
continent information in the left half.
A compiler generated code for 31 bit using this sort of convention
could maybe run with AMODE 64, too, if the runtime sets the
continent information correctly before calling the generated code.
So you could have the same code (using 4 byte pointers etc.)
running with AMODE 31 and 64 ... using different initialization
sequences in the two AMODEs.
If I had enough time, it would be great fun to check out if this
concept would really work.
I would like to hear if someone sees any basic problem why this
concept could not work ...
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.
If you're generating 64-bit code you may
as well just use 64-bit pointers and produce
a pure 64-bit application?
Yes, but - see above - it would be interesting IMO
to have the same code running in AMODE 31 and AMODE 64
and have only the runtime (or the initialization sequence)
take care of the differences. (If I generate real 64 bit code,
the offsets of structures containing pointers, for example,
change, because all pointers now need 8 bytes ... so the
code is completely different from the 31 bit code).
I don't know yet if this is really possible. But if it is and if it
is done correctly, it should not be slower than "normal" AMODE 64
using 8 byte pointers ... because there is no difference during execution,
except that only the lower half of most pointers is stored and loaded
and the higher half stays the same most of the time.
BTW: even if you do static linkage, your resulting program object
will probably fit into one "continent", so there will be no need to
reload the continent parts of the registers when calling an external
module. Maybe it is possible to limit "cross continent calls" to
very special "dynamic" calls, which are special even at the source level
of the programming language. Same goes for storage allocation;
the normal allocation functions like malloc etc. should retrieve storage
from inside the continent; only very special allocation functions
should be able to allocate storage in new "continents". After all,
4 GB is large ...
Back to your original question: a program generated in this
compatible way could IMO grow up to 4 GB in size, when run in AMODE 64;
this way you have what you want: a program which can be up to 4 GB in size,
runs in AMODE 64 and has 4 byte pointers. But no change from IBM is needed.
If 4 GB is not sufficient, you have to split your programs in parts and
call another "continent".
Kind regards
Bernd
BFN. Paul.
----------------------------------------------------------------------
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
