We've been using the STOC/LOC (STORE/LOAD ON CONDITION) instructions
for some time...
But, we just noticed a few words in the Principles of Operations (I'm
quoting
from the STOC discussion):
When the condition specified by the M3 field is not met (that is,
store operation is not performed), it is model dependent whether
any or all of the following occur for the second operand: (a) an
access exception is recognized, (b) a PER storage-alteration event
is recognized, (c) a PER zero-address-detection event is recognized,
or (d) the change bit is set.
Now - a rather common programming idiom is to store a result if a pointer is
not NULL. So, it would seem that a comparision of a pointer to x'0'
followed by
a STOC would be a nice programming idiom.
However, one of our recent tests (on a zPDT platform) blows up with this
paradigm... getting an 0C4. Even though the condition in the STOC is not
met and the store will not occur...
The Principles of Operation also appear to be inconsistent, it makes
this claim:
For example, the following two instruction sequences are equivalent.
STOCG 15,256(7),8 BC 7,SKIP
STG
15,256(0,7)
SKIP DS 0H
But, according to the paragraph quoted above, the two sequences are not
equivalent. The sequence on the right might not have the possibility
of generating an access-exception, while the STOCG does have that
possibility
even though the store would not occur.
I find these semantics a little baffling and wonder if that doesn't
essentially
make STOC/LOC pretty much unusable in all but the most restrictive
situations?
Thoughts/Opinions???
- Dave Rivers -
--
riv...@dignus.com Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
