Ian Worthington asks about this text he read:
> New instructions must be assembled using the YOP
> instruction set on LINUX HLASM. The rest of the
> system is assembled against the ZOP instruction set
> "to avoid the use of long displacements."
Here's what I think the short answer is:
On the original machines on which the Long Displacement Facility was first
implemented, these new instructions were not implemented in hardware. As a
result, they were very slow -- much slower than the similar [same opcodes,
in fact!], non-long displacement instructions. Later, a high performance
implementation in hardware was made available on newer machines.
> Would this simply be so that the rest of the
> system would run on hardware without the long
> displacement facility
While that is a true statement (the system would thusly run), I think the
answer to the question you were probably actually, in context, asking is:
No, that's not why they said that. The bottom line is that you can ignore
the statement under the present circumstances, since it is most likely no
longer relevant (to you, or to most of us here).
The long answer follows:
I think that what that (old, and probably no longer relevant) comment you
found meant -- at the time -- was this:
First, in order to support the new instructions (in programs that
intentionally used and presumably needed to use long displacements), such
programs had to be assembled with OPTABLE(YOP), else they would fail at
assembly time.
Second, the "rest of the system" -- which, by implication, did not [want to]
intentionally use long displacements [meaning 20-bit signed displacements]
was to be assembled (for performance reasons) using OPTABLE(ZOP). The
performance reasons which I think are implied by the statement refer to the
performance of the Long Displacement Facility instructions, which they did
not want to (inadvertently) use. In order to _detect_ any such inadvertent,
unintentional use, they did not want to use OPTABLE(YOP). In other words,
this meant that instructions (or, more precisely, instruction mnemonics) for
which the Assembler _could_ use the long displacement form would _not_ use
that form [20-bit signed long displacement] but would instead be limited to
the standard, old form [12-bit unsigned displacements -- which also meant no
negative displacements] and would result in an error at assembly time if any
such reference was (inadvertently, accidentally) attempted. It was a
self-protection mechanism (but not from errors at execution time, but from
poor performance at execution time).
Hence, I believe it is an old, no longer pertinent comment reflecting the
fact that, at the time it was written most likely, the only machines with
the Long Displacement Facility had only slow, non-hardware implementations
(or not all machines that were available then had a hardware implementation
thereof).
Today, you are likely to have a machine which implements these instructions
in hardware, and so it should _not_ be an issue for you. They are
implemented in hardware starting with the z990 and the z890. The z900 and
z800 are the only machines on which they are not implemented in hardware.
Conclusion: Ignore that (old) comment you found. For you (and most others)
it is now just a red herring.
The actual technical issue, which is subtle unless you were well read and
paid close attention [on this list] around June 2003, is that the Assembler
can assemble what are essentially _different_ machine instructions for the
_same_ Assembler instruction MNEMONICs (such as LG), which use the _same_
machine code operation codes, depending upon whether or not you have
specified an OPTABLE which has the "Long Displacement Facility" instructions
included. For example, as the very astute David Bond indicated in a prior
message, the LG mnemonic will assemble as follows:
With OPTABLE(ZOP):
+---------+----+----+----+------------------+---------+---------+
| X'E3' | R1 | R3 | B2 | D2 [12 unsigned] | X'00' | X'04' |
+---------+----+----+----+------------------+---------+---------+
0 8 12 16 20 32 40 47
NOTE: D2 is the 12-bit _unsigned_ displacement
With OPTABLE(YOP):
+---------+----+----+----+------------------+---------+---------+
| X'E3' | R1 | R3 | B2 | DL2 [12] | DH2 [8] | X'04' |
+---------+----+----+----+------------------+---------+---------+
0 8 12 16 20 32 40 47
NOTE: DH2||DL2 together form a 20-bit _signed_ displacement
(but note the order: DH2 goes before DL2)
Of course, in order for the 8-bit DH2 value to be non-zero (and so
distinguish itself as a Long Displacement Facility instruction) either a
negative displacement or a positive displacement larger than 12 [unsigned]
bits is actually needed to cause the DH2 byte to contain a non-zero value.
The problem, of course, as David Bond pointed out, is that since the
operation codes for the non-Long Displacement Facility instructions are
exactly the same as for the non-Long Displacement Facility instructions, one
can assemble a program that uses either negative displacements or positive
displacements larger than 12 (unsigned) bits [and thus requires a machine
with the Long Displacement Facility implemented in order to execute
properly] and not know it. If that program is then executed on a CPU without
the Long Displacement Facility, bits 32-39 (DH2 8 bits) of the instructions
will be ignored. The processor will think it is executing the old
instructions [the only ones it supports], which only support 12 bit unsigned
displacements; it will not S0C1 ABEND on the actual, new Long Displacement
Facility instructions if given any to execute, apparently [because the
definition of the instructions, most unfortunately, was that those 8 bits
"are ignored" -- instead of, as should have been the case, required to be
all zero (and so verified)].
If you know that you don't want that dangerous event to occur, then simply
don't specify an OPTABLE that includes the Long Displacement Facility
instructions. But I doubt that you have a processor that does not implement
those instructions, or that you have one of the very old processors that do
not do so in hardware (a z800 or z900).
The "Long Displacement Facility" was announced in June 2003 and is described
in the third (June 2003) edition of the z/Architecture principles of
Operation (SA22-7832-02). That is (now) a very old level of that
publication. The facility provides for 20-bit signed displacements in 69
existing POPS-named instructions and in 44 new instructions, as well as new
floating-point load and store instructions, and the new Load Byte
instruction. They were initially added to the z900 (GA2 level) [2064], but
none were apparently implemented in the hardware on that CPU (the z900
[2064]). Later, a so-called "high performance" implementation (meaning:
hardware) was available on the z990 [2084] and z890 [2086] boxes. I assume
that the "slow" version only was made available for the z800 [2066] CPU.
At the Assembler level, the new Long Displacement Facility instructions
require OPTABLE(YOP) or "later." NOTE: YOP also adds support for new
instructions other than just those added for the Long Displacement Facility.
For the x/OS XL C/C++ Compiler, these instructions are used if ARCH(6) or
above. For that IBM compiler, by the way:
ARCH(5) is for the 2064-xxx (z900) and 2066-xxx (z800)
ARCH(6) is for the 2084-xxx (z990) and 2086-xxx (z890)
ARCH(7) is for the 2096-xxx (z9 BC) and 2094-xxx (z9 EC)
The long-displacement facility is (now) on all z800, z890 and z990
processors. For the z900 processor, it should be there with all current
service levels of the microcode (level 3G or later was required, but I doubt
there are any in the field that backlevel).
--
WB
