Oppolzer - Informatik / Blog

Am 05.11.2014 15:18, schrieb P.G.:
> 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