Robert Raicer wrote:
<begin snippet>
When I first read about the Long Displacement Facility in Principles of
Operation I was surprised that IBM did such a truly stupid thing with respect
to assigning meaning to bits documented as "unassigned" in previously existing
general (unprivileged) instructions. I suppose the real flaw was in the weak
implementation in prior machines with respect to enforcing that unassigned bits
in instructions were zero. IBM does have legitimate wiggle room here with
respect to what is documented in Principles of Operation (but I still think
what they did was stupid).
</end snippet>
This passage puzzles me. I should prefer the word reserved, which is in fact
used in some IBM documentatioin, to the word unassigned; but what is the issue
here? Did Mr. Raicer or someone he works with set and use some of these bits?
If so, how and why?
It would be easy, albeit diseased, to write macros to set these bits at
assembly time, using generated binary or hexadecimal DCs interpolated among
instructions; and they could then be interrogated. Setting them at execution
time would sometimes be impossible, at least for reentrant programs, which are
often stow-protected.
Perhaps even more puzzling is the notion of "enforcing that unassigned bits in
instructions [be] zero". The assembler sets these bits to zero in such
instructions; one must use instruction punning to set them otherwise. How can
one guard against such misguided schemes (without crippling the assembler)?
Or again, there may be other issues here that I have missed. If so, I should
be grateful to know what they are.
John Gilmore
Ashland, MA 01721-1817 USA
