I think it would much more straightforward to adjust the condition, i.e.
when you need to reverse the specified operand order, you change JL to JNL,
H to NH, NL to L, NH to H.  Might be messy in the macro, but the executable
part would be clean.

For the record, I wouldn't go down this road at all.  Every assembler
programmer has to deal with coding compare instructions, so let them handle
it.

sas

On Fri, Aug 11, 2023 at 8:09 AM David Eisenberg <deisenbe...@optonline.net>
wrote:

> I’m trying to puzzle something out… I hope this question isn’t too goofy.
>
> I’m coding a macro to logically compare a halfword in storage to a 2-byte
> unsigned constant that is calculated by the macro assembler. I want to
> generate baseless code using as few instructions as possible, and I’d like
> to use the fewest number of registers possible (although I have no problem
> using the high-halves of any registers). My preference is to use CLHHSI to
> do the compare, because no literal is required for the constant.
>
> However: CLHHSI requires that the constant be the second (immediate)
> operand. There will be times when the macro parameters will indicate that
> that comparands must be reversed (i.e., where the immediate operand must be
> the first comparand), in which case I can’t use CLHHSI.
>
> I know that I can always code the comparands in the correct order by
> loading them into the high-halves of R0 and R1, then use CLHHR. Or, of
> course, I can generate a CLC with a literal. But I figured I’d ask: if I
> use CLHHSI, then (if the macro determines that it’s necessary) can I modify
> the resulting condition code to appear as though the original comparands
> were swapped? (I.e.: CC=00 stays the same, CC=01 becomes 10, CC=10 becomes
> 01.)
>
> So far, this is what I’ve come up with (just as an example of the macro’s
> generated code):
>
>          CLHHSI HALF,X'A24B'     I like CLHHSI… no literal needed
>          JE    DONE              if the comparands are equal, don’t modify
> the CC
>          IPM   R1
>          XILF  R1,X'30000000'    flip the bits in the CC
>          SPM   R1                set the new CC, program mask remains
> unmodified
> DONE     DS    0H
>
> Is that the best I can do? Or might there be some clever way to modify the
> CC using fewer (or shorter) instructions? (Or is my entire concept
> ridiculous?)
>
> Thanks so much,
>
> David
>

Reply via email to