Am 05.11.2014 15:18, schrieb Paul Gilmartin:
On 2014-11-05, at 01:27, Bernd Oppolzer wrote:
Maybe it can be explained this way:
when we migrated from 24 bit to 31 bit, we had lots of problems
when loading 24 bit addresses (for example parameter addresses)
from fullwords and using them in 31 bit mode,
and the addresses had some non zero values in the first (leftmost) byte
of the register (which was no problem in 24 bit mode). There was no way
around this but to clean the register's first byte before doing the storage
access (if the address was a 24 bit address in the beginning).
Now we have the same situation; the leftmost bit of the fullword is
ignored when using the addresses in storage access (in 31 bit mode),
be it 0 or 1 ... and it is 1 sometimes.
When expanding a 31 bit address to 64 bit, simply by adding 32 zero
bits on the left or by loading a fullword into the right half of a 64 bit
register,
the 31 bit address will be the wrong address, if the leftmost bit in the
fullword
was set.
A similar approach as for 24 to 31 bit conversion applies. Simply
clear bit 0.
But this time we have the chance to flag such errors, simply by excluding this
address range (0x00000000_80000000 to 0x00000000_FFFFFFFF) from
the range of allowable 64 bit addresses in z/OS. It is, given the overall
address range, not too large.
Are you suggesting that someone might do 64-bit STORAGE OBTAIN and save
only low-order fullword. This will certainly cause problems, but those
are not solved by excluding that address range. Or that someone do 64-bit
STORAGE OBTAIN and decide based on whether the high-order fullword is 0
that it suffices only to store the right half?
I still don't envision a plausible scenario in which a problem is avoided
by excluding that range of addresses. Supply context.
load a 31 bit address which points to storage below the bar from a fullword;
the fullword has the first bit set (maybe because it is the last
fullword in an address list).
The target of the load is a 64 bit register (say reg 5), where the left
half is zero.
Now you switch to AMODE 64 and use that register for adressing ... ouch.
Without excluding that address range, you risk to access wrong storage
(if at
that wrong address there is accessible storage, by chance). By excluding
that
address range, you will get an ABEND in any case, which is better.
**
More:
I understand that BASSM sets bit 63 of the return address to indicate
that the return address is to AMODE 64. Does Content Supervision
follow the same convention, setting bit 63 when LOADing an AMODE 64
module?
I don't think so; what LOAD does, depends on the RMODE of the module.
It may be different for LINK, XCTL, ATTACH ...
Hmmm. I believe I can declare an ENTRY at an odd offset from the CSECT.
(It had better be data, not a branch target.) I can make that ENTRY an
ALIAS for my module. When I LOAD it, how can I tell if it the address
returned with bit 63 set indicates an AMODE 64 CSECT or an actual odd
address.
don't know, what exactly will happen, but the module containing this
ENTRY has an
RMODE, and you will not get an address different from that module's RMODE.
Don't mix up addresses in the PSW which are always even with data adresses,
which may be even or odd. Because addresses in the PSW are even all the time
(all instructions are on even adresses), the last bit in the instruction
address in the PSW
can be used for any other information (in theory) ... but in fact it is
not used;
it is always zero. BTW: in the PSW bit 31 indicates AMODE 64, this is
not part
of the instruction address (which is at bits 64 to 127; 127 is always
zero and needs
not to be saved by BASSM, for example).
Perhaps the answer is, "Don't do that!"
Does Binder resolve 31-bit V-CONs setting bit 0 to indicate AMODE 31?
Does Binder resolve 64-bit V-CONs setting bit 63 to indicate AMODE 64?
storing the AMODE information in bit 63 of an address is only valid for
addresses
that are related to machine instructions, such as return addresses;
there are only
some instructions like BASSM that use this technique. V-CONs can be
related to
data areas as well or they are not used with AMODE switches, so it would
make no
sense for me if V-CONs would do something implicitly with bit 63.
-- gil
HTH,
kind regards
Bernd
