Thomas David Rivers wrote:

> 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 -
>
> --
> [email protected]                        Work: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com

It seems likely someone or some group at IBM have a use for this, or it would
not have been added to the architecture. The purpose of these instructions is to
remove the branch, which may or may not be reliably predictable and may stall
the pipeline. Load/store/whatever on condition instructions are common on other
architectures. A version of conditional execution is fundamental to Itanium and
is present in ARM. I believe Sparc also has conditional execution of some
instructions.

Although not suitable for the idiom you describe, there is certainly a wide
range of situations where this might be useful.

Regards,
Henry

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to