Page 2 of 2
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Tue Apr 28, 2020 6:38 pm
by 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.
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Tue Apr 28, 2020 6:44 pm
by BillG
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:
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Wed Apr 29, 2020 8:37 am
by 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.
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Wed Apr 29, 2020 11:27 am
by Chromatix
It may be that the flags are generated from an internal bus rather than from the ALU.
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Wed Apr 29, 2020 11:42 am
by 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.
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Thu Apr 30, 2020 7:23 pm
by BillG
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.
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Sun May 03, 2020 3:54 pm
by 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.
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Sun May 03, 2020 4:09 pm
by 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.
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Sun May 03, 2020 10:12 pm
by 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.
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Mon May 18, 2020 10:04 pm
by BillG
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
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Mon May 18, 2020 10:11 pm
by 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.
Re: The 6502 Status Register: a Guide to Black Magic
Posted: Tue May 19, 2020 1:59 am
by 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.