Ref: Your note of Fri, 15 Mar 2013 12:31:01 -0700
There are currently something like 373 extended mnemonics defined
in the current HLASM operation code table, and I'd rather not add
too many more unless there's a very good reason for them. Some
"obvious" mnemonics have already had to be adjusted, so for
example we have "Jump Long Unconditional" (JLU) because JL was
already taken.
I think the worst problem here is the historical one that long
ago the Subtract Logical instruction (which was quite obscure at
the time) was defined in terms of the Add Logical instruction,
which results in unexpected condition code values. I think
everyone is surprised when they find out that a result of zero
doesn't give CC 0. This in turn means that the standard
mnemonics are unhelpful.
For Add Logical, the condition code makes more sense in that the
two bits of the condition code value simply indicate whether the
carry and the main result are non-zero. I usually simply code a
binary condition code mask in that case.
There are other cases too where the existing mnemonics are
unhelpful, for example after TMLL/TMLH, where a "mixed" set of
bits can either set CC 1 (as for "minus") or CC 2 (as for
"plus", depending on whether the leftmost bit is a 1.
In such cases, I don't see a major problem with simply using
numeric condition code values, which can be specified using
equated symbolic names to document the intended meaning. It
is also of course possible to define CC_NOT or similar as a
mask of B'1111' for inverting the condition, for example:
BC CC_NOT-CC_CARRY,NOCARRY
Another way to minimize the problems is to encapsulate useful
combinations of functions in macros, then forget about the
details. I used to use logical instructions for 64-bit
arithmetic, for example on STCK values. For such cases, I wrote
a set of 64-bit arithmetic macros where the test for overflow or
borrow was within the macro, so that I didn't have to remember
the mask values.
Jonathan Scott
HLASM Development, IBM Hursley, UK
