Modifying the CC in the PSW

[David Eisenberg]

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

[Steve Smith]

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 <deise...@optonline.net>
wrote:

[David Eisenberg]

>I think it would much more straightforward to adjust the condition<

Steve,

I understand what you mean. My issue is that the macro is intended to replace pre-existing CLC instructions within legacy applications (the macro will examine and potentially modify the comparands prior to the compare). My hope is to code the macro in such a way that the original two CLC operands can be passed as positional parameters to the macro without swapping their order, and without the need for the developer to change any of the conditions in the subsequent jump instructions. I.e., my desire is to make the macro as functionally transparent as possible to the invoking applications.

If it’s too nonsensical for me to modify the CC after a CLHHSI, then I’ll probably take the approach of putting the operands in the high-halves of R0 and R1 and doing a CLHHR.

Thanks,

David

[Steve Smith]

So, your macro doesn't know the condition. I was thinking of something
like an IF macro.

OK, some more unsolicited free advice (as usual maybe worth what you pay
for it). I doubt that loading the operands into registers and comparing
them there is going to be any faster than a CLC. It will definitely take
up more space, which may cause USING range problems.

I'll take it for granted you know all operands fit into 4 bytes.

sas

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

[Paul Gilmartin]

On 8/11/23 06:08:44, David Eisenberg wrote:
> ...

> 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.)

Are the Set/Insert Program Mask instructions useful for this?

--
gil

[David Eisenberg]

>Are the Set/Insert Program Mask instructions useful for this?<

Yes, that's in the code snippet I posted at the start of this thread... I'm wondering if there's an even more efficient way to do it. Perhaps not!

[Jonathan Scott]

Any sequence of multiple instructions is almost certain to be
slower than the original CLC which I assume would be comparing
with a literal, especially if the macro expansion required a
branch. For baseless code, I normally still have a base
register for a static area containing literals and constants,
and I would expect that keeping the original CLC with a literal
would be the simplest and fastest solution in any case where the
operands would otherwise be the wrong way round.

Jonathan Scott, HLASM
IBM Hursley, UK

[David Eisenberg]

Jonathan,

Thank you for that information! It's very helpful.

David

[Jon Perryman]

> David Eisenberg wrote:
> I want to generate baseless code using as few instructions as possible,

> Can my macro modify the resulting condition code?

I'm horrified this was your solution especially considering all the other options available.

1. Regardless of programming language or whatever you are doing, you should always ask yourself if you are making a choice for the right reason. Far too often we overthink a decision or problem only to find we are solving problems that will never exist.

2. In the next 5 years, how many programs will need that extra register and you are willing to give up addressability to constants? For most people, it will only be at couple. Don't disable a useful HLAsm feature because someone convinced you that baseless is important. Your only job at this time is to make that extra register a simple choice if if's more important than constants. Needlessly removing the base reg is a terrible idea but preparation is important. The truth is that constant addressability is more important than as an 11th register. Truly baseless is often not the answer. For me, baseless was not a solution when I added entries to a large TSO parser table that caused addressability problems. Each addressability problem is unique and, in this situation, moving the table after all constants (including LTORG) was the only acceptable solution. It's understandable you want to solve a problem but consider the cost/risk/benefit of going beyond preparation.

3. Forget about converting B to J by hand because you can't modify IBM macros. The correct and very simple solution is to internally translate B to J. OPSYN B instructions to a macro. The macro only coverts B to J when it doesn't involve a register (no parenthesis). There are a couple of extremely unlikely exceptions but it's doubtful anyone will experience these exceptions.

4. Inform everyone of how to use their new choices. If they need a second base reg, simply change the using to the start of the constants because executable code does not need addressability since you B is now J (with a couple of IBM macro exceptions). If they absolutely need the extra register, then they need to decide how to best handle constants.

5. If you insist on conversion instead of prepping for baseless code, then instead of CLHHSI, use LARL R1,=X'1111' before the CLC. No sense in making this complicated.

6. Depending on CC outside the macro should be avoided if possible.

7. I suggest you look at using the structured macros available in the IBM HLASM Took Kit. Your CLHHSI problem is about esthetics. You may find coding IF (CLHHSI,AA,LE,X'1111') more palatable.