Oppolzer - Informatik / Blog

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
address (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.

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.

This is, as I understand it, a design decision of z/OS; Linux and z/VM deciced
that they don't regard such problems as severe enough, or they even don't exist,
because Linux is 64 bits from the start (but I don't really know this, only a
guess).

Kind regards

Bernd



Am 05.11.2014 07:54, schrieb B.D.:
> On Tue, 4 Nov 2014 20:27:09 -0700 P.G. wrote:
>
> :>On 2014-11-04, at 19:25, C.A. wrote:
>
> :>> A 64-bit address is only ambiguous when the high word is zero and the
> :>> high bit of the low word is on.  When the high word is non-zero all 32 bits
> :>> of the low word can address storage locations without ambiguity.
>
> :>I'm not sure why you're even discussing 64 bit addresses when in
> :>in AMODE 31.  Isn't that a contradiction in terms?
>
> :>How do VM and Linux, which I understand to not block that range of
> :>addresses deal with the problem?
>
> :>Isn't there a bit in the old PSW that distinguishes between
> :>AMODE 31 and AMODE 64?
>
> :>Give me more context.  Where might I encounter a 64-bit address
> :>such as 0000 0000 8000 1000 and be uncertain whether it was to
> :>be interpreted in AMODE 31 or AMODE 64?
>
> Never.
>
> The issue is addresses accesses via L when in 64-bit mode. There are various
> conventions where setting the high order bit is meaningful such as the end of
> a parmlist or indicating that the routine expects to be called in 31 bit mode.
> Until the code is changed to use LLGT(r) to clean the high order bit, it was
> felt that it was better to force an abend (by not allowing virtual addresses
> in that range to be assigned) rather than allow erroneous access to the wrong
> storage..
>
> --
> B.D.