Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
I'm having a debate, regarding the proper CC to use after an Assembler LTR instruction. I want the branch to go to the label for processing when the result is non-zero. The result will always be an absolute value of zero or greater. The issue is that the coded branch used is a BP (Branch Positive/Plus), which indicates branch on a positive value, but as far as I've found in various manuals, the result COULD be ZERO, which the code uses in a BCT. So upon the first BCT, the register goes to X'FFFFFFFF' when the register is ZERO and we raise a S0C4. I've recommended to change the BP to BNZ as the result is never negative, but I'm hitting resistance.
Any perspective on a BP as to whether this CC includes ZERO would be helpful.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Enrico,
Yes, I broke down the CC's, but the explanation of BP did not include any discussion of ZERO as being a valid PLUS value.
The LTR being issued is after a "DR", with the quotient ALWAYS resulting in an absolute value, never negative. This is why a BNZ would make more sense and would be clearer to the next person.
In the interim, an external colleague has told me that a BP does NOT include a result of ZERO. So, this branch will work after the LTR, with a value that exceeds ZERO. I still prefer the BNZ, but it looks like the BP will remain.
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
Enrico,
Yes, I refer to both of these manuals regularly, but like I said, neither were clear on the BP as to whether ZERO was a consideration in the CC. After all, ZERO is always considered a positive/plus value. Hence, the confusion and the raising of a false positive.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
What you have to do is go to Principles of Operation and check the condition codes set by the instruction that immediately precedes your branch. Most (not all) arithmetic instructions set 4 possible condition codes
Value is positive
Value is 0
Value is negative
Value overflowed
Your problem is you want to think of a 0 result as positive - there is no such thing as a negative 0 in the 2s complement binary arithmetic done for most arithmetic operations - so you have to think out of the box a little. If you ignore overflow, you do not want to branch if the value is negative, but 0 and positive are OK, so think negative: not minus, so your instruction should be BNM, branch not minus.
This raises another question: at least in theory, packed decimal and floating point arithmetic can come up with a -0 result. I don't know
Does the hardware set a -0 value?
If the hardware sets a -0 value, is the condition code set to B'00' (the usual condition code for a 0 result) or something else?
I'm guessing here, but I'd bet the hardware sets +0 and the condition code as B'00'.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Thanks Dick. I like your avatar.
I've been doing a little experimenting. Other than SRP, I think the only instructions that can store a -0 result are MP and DP and the floating point multiply and divide instructions.
As far as I can tell, none of the multiply and divide instructions alter the condition code. I remember a bug I induced many years ago when I thought, incorrectly, that the multiply instruction set the condition code and I did a BZ (or was it a BNZ, who can remember after 40 years?) after the multiply. This makes sense for the non-floating point divide instructions; they produce two results, so which result should set the condition code?
This code -
Code:
MP X,=P'0'
...
X DC PL4'-30'
stores PL4'-0', which one would expect. I ran into trouble with SRP, and I fear I may have found a Hercules issue.
This code produces a +0 result and sets the condition code to 0.
Code:
SRP X,64-1,0
...
X DC P'-3'
If I read Principle of Operation correctly, it should result in -0 and, I presume, a condition code of 0. The key phrase is, "... Only its digit portion is shifted; the sign position does not participate in the shifting. ..." If you start with -30, you wind up with -3, which makes perfect sense and follows the phrase in Principles of Operation. Perhaps someone can try it with real hardware and let us know the result.
my bad I had not read completely Your post
