Pulling Zero/Negative Flags

Hardware
1

The 65x pull instructions affect the negative and zero flags. Eyes & Lichty seem to think this is unusual for microprocessors. What architectures is this not the case on?

(Watch out for the typo on page 483 for PLA where it says they set those flags).

2

As a keen 6502 (and '816) programmer I have to admit that I’ve never really read the E&L book. Possibly because I’d been programming the 6502 for a decade or so when it came out and maybe it just wasn’t popular in the UK Of-course the PDF version is available everywhere so when I did hear about it - just a couple of years back, I did skim through it, but it’s not my “go to” reference…

And the pull instruction(s) affecting flags - well, yes, that’s usual for the 6502 - anything that reads into a register sets flags. Memory to register, register to register, alu to register - they all set flags, so it’s usual for the 6502.

Maybe other microprocessors are unusual from the 6502s point of view?

My PDF copy doesn’t have that many pages…

-Gordon

3

oh, here it is: Programming the 65816 : Eyes, David : Free Download, Borrow, and Streaming : Internet Archive

4

Worth noting that they are talking about PLA, not PLP. It’s not that they pull the flags but that the flags are updated by the new value.

I wouldn’t be surprised if the 6800 does this differently. (Does it even set flags on stores? I don’t know offhand.) If you’re interested and look into it, a table of results for 6800, 8080, z80 and 6502 might be interesting to see here.

Edit: I see “set” is ambiguous, both in the book and in my paragraph above. I’m not sure I’d call it a typo, but I see what you mean.

5

I think, this is a matter of consequence: if the processor is setting the zero flag, it should be setting the negative flag, as well.
So, in my thinking, the question is really: do we expect the processor to set the zero flag on pull and is this useful?

(Like @drogon, I pretty much expect the 6502 to do this. It would be more of an exception, if this was not the case.)

6

I agree, but I would change the language slightly from “setting” to “updating”.

It depends on the circumstances, but I find the 65xx flag update behavior to be generally useful in my own little coding adventures. The 68xx flag updating behavior is foreign to my creative processes, and I often feel like it’s trying to work against me rather than with me (same for x80).

1 Like
7

Instructions that move data from place to place do not affect the zero or carry flags on Intel architectures from the 8080 (or perhaps earlier, I didn’t check) to the modern day. On ARM, loads and stores don’t affect the conditions codes. Some RISC processors don’t have conditions codes, but those that do generally aren’t affected by loads or stores.

I was not a 6502 programmer. I never knew this about the 6502, and I can’t think of another processor that works like this. I think it’s safe to say it’s peculiar.

8

DEC machines come to mind, where conditions always refer to what is currently in the register. On the 6502, this is only true for register to register transfer instructions, as well as the pull from stack.

Just to out me as a radical :slight_smile: : I somewhat miss this for the various load instructions (which leave the negative and zero flags unaffected). There’s hardly a need to preserve the state of the zero or the negative flag across such operations, and it would be great, if these already reflected what had just been loaded without having to execute a separate compare instruction to update these flags.

That is, it’s a bit like with do-while versus while-do:

LOOP: INX          ;increment X updates the zero flag
      LDA $2000,X  ;load $2000 indexed by X (addr.: 0x2000 + X)
      BNE LOOP     ;thankfully, this didn't update the zero flag

versus

LOOP: LDA, $2000,X
      INX          ;here, it doesn't matter, if LDA updates the Z flag or not
      BNE LOOP

More often, we see the latter pattern anyway. However, if the load instructions would update these flags as well, we couldn’t use the former one, at all. So it’s probably fine as-is.

9

6800: All stores affect N, Z , V
6800: PUL instruction does not affect flags unlike the 6502
6502: TSX affects flags
6800: TAP affects flags because it copies A to P!
6800: TSX TXS and TPA do not affect flags.
6502: TXS is the only transfer instruction on 6502 that does not affect flags.

2 Likes
10

Thanks! As someone coming from a mostly 6502 background, I always find it surprising that 6800 sets flags on stores… any thoughts on whether there’s a real difference in code density or performance? The 6502 team must have deliberately decided to do it differently. (And as I understand it, their changes were based on surveying users of 6800.)

11

This reminds me of assembly language programming for the RCA 1802 in my distant past. That processor didn’t have proper condition codes (except for the carry bit), so conditional branch or skip instructions acted on the actual contents of the D register at that instant. This actually made it easy to determine how “condition codes” would be handled.

1 Like