And z/VSE followed the same pattern as z/OS.
And, as a little extra, this is why the 31/64 line is called a BAR, not
a LINE. The unusable addresses are what is in the BAR. So, you can be
above the bar, or below the bar, but not in the bar. (No drinking
allowed. :-) )
Tony Thigpen
Bernd Oppolzer wrote on 11/05/2014 03:27 AM:
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 Binyamin Dissen:
On Tue, 4 Nov 2014 20:27:09 -0700 Paul Gilmartin
<[email protected]> wrote:
:>On 2014-11-04, at 19:25, Chuck Arney 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..
--
Binyamin Dissen <[email protected]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
