Post by Tony Harminc ***@gmail.com [hercules-390]Post by ***@yahoo.com.au [hercules-390]z/Arch is in an interesting position where 32-bit
code can actually execute in the same mode
(ie 64-bit mode) as 64-bit programs.
I'm not sure there is anything meaningful to the term "32-bit code" in
the zArch context. Surely it is just 64-bit code that avoids using a
few features. Well, sure, you can apply any labels you like to code,
but is "32-bit" any more valid than "structured" or "recursive" or
"doesn't use the new z14 instructions"?
Excellent question, and what keeps me up at night
trying to get to grips with the world of computers.
I used to think that if something disturbed the
high 32 bits of registers then it was a 64-bit
program that required a 64-bit save area.
So even a program running AM31 that used
64-bit longs would be considered 64-bit.
That's still the case, but not the criteria for
marking a module as ELF32.
There are two independent things that would
need a module flagged as 32, to let the OS
know it needs to handle differently.
One is if code pointers are 32-bit, so someone
has coded like:
SGR Rx,Rx
L Rx=V(MYFUNC)
Or perhaps the SGR is not there at all, and the
program has assumed that the high 32 bits are
0, or doesn't even know that they exist.
This more-or-less necessitates that the module
itself needs to be loaded in RM32 space.
But even if code pointers were 64-bit, the data
pointers may still be 32 bits, and a module
loaded above 4 GiB would still need malloc()
to return addresses below 4 GiB. So another
reason why the module would need to be
marked "32".
It is possibly ideal that the figure "32" should
be split into 32C and 32D as independent
flags. In practice I would say that 32 implies
both C and D, which is what people would
normally do by compiling with gcc -m32 or
whatever.
Post by Tony Harminc ***@gmail.com [hercules-390]Post by ***@yahoo.com.au [hercules-390]1. The high 32 bits of registers are zero.
2. Negative indexes are not used.
Are you quite sure those are the only restrictions?
No. But my small test program works fine as AM64.
GCC doesn't work fine as AM64 because of the
negative index use, but it does run fine as AM32.
Post by Tony Harminc ***@gmail.com [hercules-390]Post by ***@yahoo.com.au [hercules-390]If this is done, 32-bit programs should have
access to a full 4 GiB virtual address space,
instead of being restricted to 2 GiB.
So a BXLE loop will work fine...?
Gerhard uses BXLE in MVS380MN, and I have
confirmed that when that is run as AM64, it still
seems to work fine.
Post by Tony Harminc ***@gmail.com [hercules-390]Post by ***@yahoo.com.au [hercules-390]I wish to get some version of z/Linux to start
using a full 4 GiB (if it isn't already) address
space, to provide prior art to getting the same
thing done in z/OS.
Who, imaginably, would do this for z/OS? IBM has certainly made their
feelings clear.
I'm holding out for an important customer saying
"hey, z/Linux gives 32-bit applications the full
4 GiB address space, why can't we have the
same in z/OS".
Post by Tony Harminc ***@gmail.com [hercules-390]And they are even more certainly not going to copy
some code that you put in the PD into z/OS.
I don't believe I have any PD code that will
help IBM developers. The most I would be
able to do one day is demonstrate 4 GiB
addressing on MVS/380 or PDOS/380 to
prove what is technically possible.
BFN. Paul.