Testing for zero after DEC

[Victim_RLSH]

LDX CollisionCount ; count down the block that was collided with
DEC BlockData+BlockCount,X
LDA BlockData+BlockCount,X
CMP #$00 ; remove block from playfield if it is reduced to 0
BEQ RemoveBlock

The 6502 opcode guide in the Programmer's Reference Manual says DEC affects the zero flag, so is the LDA and CMP here unnecessary? Just trying to shave off a few bytes wherever I can get away with it.

[malcontent]

Yes, it's unnecessary.

[tlr]

The LDA affects Z as well, so your example uses a double redundant construct. Using an unnecessary CMP has the side effect of overwriting the C-flag which you may not want in a particular case.

[beamrider]

@tlr, assume you mean Z is already set by the DEC so LDA and CMP are both superfluous here?

[tlr]

@tlr, assume you mean Z is already set by the DEC so LDA and CMP are both superfluous here?

Yes. The OP questions if the LDA and CMP is necessary. It would work if you remove just the CMP, but the LDA is redundant too.
And of course: in addition to the C-flag, Acc gets overwritten as well in the original example.

[Victim_RLSH]

I found many other instances where I'm testing to set a flag that has already been set by another opcode. My 6502 gears haven't turned in 35+ yrs, so this is definitely a good workout.

[bjonte]

Sometimes it's nice to have the CMP for clarity and when using symbols it can keep the code working even if the symbol changes in the future. I made a macro to do the CMP only if the value to compare is non-zero. It looks a bit worse but I rather be safe than sorry.

Code: Select all

lda response_buffer
cmpi(RESPONSE_OK)
bne .response_error

Code: Select all

macro cmpi(.constant)
{
	if (.constant != 0) {
		cmp #.constant
	}
}

A common thing I do that I can get a few bytes back from is ending a subroutine with a JSR followed by an RTS. In some cases the RTS can be removed if the JSR is changed to a JMP.

Code: Select all

jsr something
jsr something_else
rts

Code: Select all

jsr something
jmp something_else

[Mike]

A common thing I do that I can get a few bytes back from is ending a subroutine with a JSR followed by an RTS. In some cases the RTS can be removed if the JSR is changed to a JMP.

That's a common programming technique that not only applies to 65xx machine language, and which goes by 'tail-call optimization'.

I found many other instances where I'm testing to set a flag that has already been set by another opcode. My 6502 gears haven't turned in 35+ yrs, so this is definitely a good workout.

In any case, keeping track of the flags should become second nature when writing 65xx machine code. It's like seeing the operator precedences of a numeric expression at first glance. Sometimes, for clarity, it might be sensible to put subexpressions in brackets. But we don't want to become lost in a labyrinth of parentheses, no?

[tlr]

I found many other instances where I'm testing to set a flag that has already been set by another opcode. My 6502 gears haven't turned in 35+ yrs, so this is definitely a good workout.

In any case, keeping track of the flags should become second nature when writing 65xx machine code. It's like seeing the operator precedences of a numeric expression at first glance. Sometimes, for clarity, it might be sensible to put subexpressions in brackets. But we don't want to become lost in a labyrinth of parentheses, no?

I quite often find myself typing out the state of flags in comments, or even writing out the actual opcode and comment it out when redundant, eg:

Code: Select all

print_hex:
        pha
        lsr
        lsr
        lsr
        lsr
        jsr     ph_skp1
        pla
        and     #$0f
ph_skp1:
        cmp     #10
        bcc     ph_skp2
; C=1
        adc     #"A"-"0"-10-1
; C=0
ph_skp2:
        adc     #"0"
        jmp     $ffd2
;       rts

[chysn]

I quite often find myself typing out the state of flags in comments, or even writing out the actual opcode and comment it out when redundant

I was going to suggest this as well. Future you will thank you.