The 6502 Status Register: a Guide to Black Magic

[Chromatix]

Some of them do test only one status bit (as on the 6502), but some test combinations of two bits. The ARM has similar measures.

[BillG]

GARTHWILSON wrote:

You can do your code example on the '02 also.

It took me awhile to grasp what you meant by that. Those two examples are for the 6502.

On the 680x, I just do:

Code: Select all

    cmpa #Value
    bhi   There


There

[BitWise]

You can generate them with macros.

Code: Select all

bhi     .macro label
        beq    *+4
        bcs     label
        .endm

bhs    .macro label
        bcs     label
        .endm

I like the 6800 but why do store instructions need to set the NZ flags? Very odd.

[Chromatix]

It may be that the flags are generated from an internal bus rather than from the ALU.

[BigEd]

I should think there could be one or two cases where the 6502 approach saves some bytes. It's one of the things a beginner has to get to know, that the value of a flag can be quite long-lived, and it can be checked in a branch quite some distance away from where it was set.

[BillG]

BitWise wrote:

I like the 6800 but why do store instructions need to set the NZ flags? Very odd.

I have done much programming on Motorola processors. Their designs were supposedly inspired by the PDP-11.

The PDP-11 does not have separate load and store instructions, but a unified move instruction which affect the flags. The follow-on 68000 family is the same except when an address register is the destination.

A few times setting the flags on store was a help or a problem. Most of the time it did not matter.

[load81]

So, I was pointed to this post after asking about Inequality Logic in the 6502. I was trying hard to build something like a digital comparator table for the 6502. I really was only after cmp and friends, their relationship to the processor status register, and their implications for mathematical inequality. I was ignoring the branch instructions on purpose.

I was after: [combination of status register flags after comparison] [corresponding inequality symbol].

After mulling over the code at the top of this post, my question, and some tutorials am I correct in understanding that might have been wrong headed on my part? What I mean is, is there a sort of Schrödinger's cat relationship here? Are the flags not relevant until the branch instructions execute and resolve the question of mathematical inequality for us? That is, looking at them from the "vantage point" of the branch instruction is the equivalent of opening the box to finally see the status of the cat?

If I'm still "not getting it" that's fine. I'll keep trying until the proverbial light-bulb comes on.

[BigEd]

You previously linked to Bruce Clark's
6502 Compare Instructions
and there's a table in there under the heading

• Use of Branch Instructions with Compare

Doesn't that contain exactly the wisdom you're after? Here are the instructions, here's what they mean.

[Chromatix]

I think the main subtlety is that the correct method of performing compares changes between signed and unsigned values, and between single-byte and multi-byte values. The ARM generates status flags according to the same rules (modified for the much wider ALU), but has a much richer array of branch instructions (actually, condition field values that can be applied to most instructions, not just branches) which make dealing with signed values far more convenient:

Code: Select all

Code | Meaning      | Test         | 6502 equivalent
====================================================
 EQ  | equal        |  Z           | BEQ t
 NE  | not equal    | !Z           | BNE t
 CS  | unsigned >=  |  C           | BCS t
 CC  | unsigned <   | !C           | BCC t
 MI  | negative     |  N           | BMI t
 PL  | not negative | !N           | BPL t
 VS  | overflow     |  V           | BVS t
 VC  | not overflow | !V           | BVC t
 HI  | unsigned >   |  C & !Z      | BEQ *+4  : BCS t    (or reverse operands and use BCC)
 LS  | unsigned <=  | !C || Z      | BCC t    : BEQ t    (or reverse operands and use BCS)
 GE  | signed >=    |  N == V      | BMI *+6  : BVC t   : BRA *+4 : BVS t
 LT  | signed <     |  N != V      | BPL *+6  : BVC t   : BRA *+4 : BVS t
 GT  | signed >     | !Z && N == V | BEQ *+10 : BMI *+6 : BVC t : BRA *+4 : BVS t
 LE  | signed <=    |  Z || N != V | BEQ t    : BPL *+6 : BVC t : BRA *+4 : BVS t

The above table works only for comparing single-byte operands (though on the '816 you can also use it for 16-bit compares). For multi-precision compares, the correct method is to refer to the above table for the most-significant byte, but if they are equal you must defer the result of the comparison to an unsigned compare of the next significant byte, and so on if there's more than two.

The PowerPC takes a rather different approach to this: the three status flags are equivalent to Positive (or Greater), Zero (or Equal), and Negative (or Less). There are distinct signed and unsigned compare instructions to generate these flags correctly. For floating-point comparisons there is a fourth flag meaning Unordered.

[BillG]

BitWise wrote:

I like the 6800 but why do store instructions need to set the NZ flags? Very odd.

The question on the flip side is why does the 6502 set flags when pulling from the stack?

Consider some code in which all of the registers are being used. The stack is used to temporarily free one up to make a comparison.

On the 6800, the code is

Code: Select all

.0F40 36              [4] 02079          PSHA
.0F41 96 8A           [3] 02080          LDAA   TEMP      GET 3RD CHAR
.0F43 A1 02           [5] 02081          CMPA   $02,X     SEE IF MATCH
.0F45 32              [4] 02082          PULA
.0F46 26 E4 (0F2C)    [4] 02083          BNE    TYP12C    IF NOT-LOOP
.0F48 A6 03           [5] 02084          LDAA   $03,X     GET DATA

While on the 6502, it becomes more convoluted

Code: Select all

.1763 48              [3] 03085          pha              ; Stash 1st character
.                         03086
.1764 A5 84           [3] 03087          lda    TEMP      ; GET 3RD CHAR
.1766 DD 17AE       [4/5] 03088          cmp    OptLst+2,X  ; SEE IF MATCH
.1769 F0 04 (176F)  [2/3] 03089          beq    Typ12E
.                         03090
.176B 68              [4] 03091          pla              ; Recover 1st character
.                         03092
.176C 4C 174F         [3] 03093          jmp    TYP12C    ; IF NOT-LOOP
.                         03094
.176F 68              [4] 03095 Typ12E   pla              ; Clean up the stack
.                         03096
.1770 BD 17AF       [4/5] 03097          lda    OptLst+3,X  ; GET DATA

[GARTHWILSON]

There will always be times that you'll want one thing or another to affect the flags or leave them alone. I know there are times I was glad to take advantage of PL_ affecting the flags, and times I wished INX did not (although usually it's perfect that INX does). I think the 6502 designers did a good job of taking their 6800 experience and improving on the 6800 when they designed the 6502.

[Chromatix]

My theory is that loads (including from the stack) pass through the ALU on their way to the register bank, so the NZ flags get updated by that.