Why doesn't overflowing A with INC set the overflow flag?

[jeffythedragonslayer]

The INX, DEX, INY, and DEY instructions not affecting the overflow flag makes sense to me - the index registers are not designed for doing arithmetic.

But what about INC and DEC? Why don't they affect the overflow flag? Is this an oversight? These are what I refer to as strict New Zealand instructions - they only clobber the n and z flags. Is the overflow flag in a place conveniently accessible by the ALU, but not the accumulator incrementing circuit?

Taking a look at viewtopic.php?p=15729, it does appear that the ALU is adjacent to the accumulator, but the the incrementing circuit is not.

[GARTHWILSON]

I don't know the answer, but I've never found it to be a problem. A related question is why didn't they make INC and DEC work in BCD when the d flag is set. I had to find that out by experience, 35 years ago.

[tmr4]

Seems like a design choice. The E&L manual provides some interesting clues: INX and INY are

Quote:

a special purpose, implied addressing form of the INC instruction.

and

Quote:

Unlike adding a one with the ADC instruction, however, the increment instruction is neither affected by nor affects the carry flag. You can test for wraparound only by testing after every increment to see if the result is zero or positive. On the other hand, you don’t have to clear the carry before incrementing.

This seems to imply that using the ALU circuitry would require doing something with the carry flag, either internally or by the user.

GARTHWILSON wrote:

A related question is why didn't they make INC and DEC work in BCD when the d flag is set. I had to find that out by experience, 35 years ago.

Is that the meaning of this cryptic quote from E&L?

Quote:

The INC instruction is unaffected by the d (decimal) flag.

I'll have to test this out. My emulator doesn't handle that.

[GARTHWILSON]

tmr4 wrote:

GARTHWILSON wrote:

A related question is why didn't they make INC and DEC work in BCD when the d flag is set. I had to find that out by experience, 35 years ago.

Is that the meaning of this cryptic quote from E&L?

Quote:

The INC instruction is unaffected by the d (decimal) flag.

I'll have to test this out. My emulator doesn't handle that.

Yes; even with d set, INC & DEC still do their thing in binary. The d flag is ignored.

[tmr4]

GARTHWILSON wrote:

Yes; even with d set, INC & DEC still do their thing in binary. The d flag is ignored.

Ah. That's clearer.

[BigEd]

For me it does seem like a design choice. In a sense, incrementing is doing something other than arithmetic - if you needed to increment a counter or index during a multibyte sequence, then it's handy to leave the carry bit out of it. Similarly overflow - one might plausibly need to increment and test a counter after a final arithmetic operation and still want to be able to see whether the overall calculation overflowed.

But note that increment does use the ALU: the carry machinery and the BCD machinery is already close by. The only incrementer on the 6502 is for the program counter, and only for that.

I can't see that it would be good to have BCD in use for increment and decrement: it would make counters and address offsets be treated as decimal. Very often this would be confusing or a source of bugs

[GARTHWILSON]

BigEd wrote:

I can't see that it would be good to have BCD in use for increment and decrement: it would make counters and address offsets be treated as decimal. Very often this would be confusing or a source of bugs

That totally makes sense for X & Y; but my early (1988?) effort to increment the accumulator in decimal was to shorten the CLC, ADC #1 sequence for an arithmetic operation unrelated to indexing or addresses. It was just a minor inconvenience to find out INA didn't do decimal. The performance hit was negligible. This was in that computer that spent most of its time at 170kHz to save battery power, and bumped it up to 1MHz when it had a set of floating-point decimal calculations to get through. If I had to do it over with knowledge I've gained since then, I would have done a lot of things radically differently. I was totally green to such a project, and so was the boss.

[Sheep64]

I would have guessed that INC and DEC were sensitive to decimal mode and that even INX, DEX, INY and DEY might be affected. My reasoning is quite simple. 6502 was covered by an elegant decimal mode patent, all computation goes via ALU and 6502 was conceived as a minimal microcontroller where decimal output is important. Decimal inhibit requires additional transistors which is contrary to other goals while precluding useful functionality.

[barrym95838]

Unlike all of the other 8-bitters I've encountered over the last 40 years, the 65c02's flag behavior has always coincided 100% with my personal programmer's intuition. 65c816 addressing mode behavior ... not nearly as much.