I have recently been pondering some 6502 instruction set issues, and I found one thing peculiar:

The CMP instruction actually is an SBC but not setting the result back into AC.
_AND_ it has the difference that the V-flag is not set.

I have been wondering whether making CMP setting the V-flag would work, and how much legacy software it would probably break.
It would have the advantage that you could branch for signed overflow (as compared unsigned overflow) on (N xor V).

Note: Hans Franke has pointed out that you could use an indexed-loop to do some arithmetic and thus use CPX/CPY but need to
carry V over that compare. So the ideas is to not set V on CPX or CPY. Or maybe a "compare signed" opcode that works like CMP
but sets V?

What is your opinion on that?

Cheers
André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

IMO letting the CMP instruction set the V flag in the 8-bit mode should not raise a significant incompatibility with most legacy 6502/65C02 programs. They should already be written to perform signed comparisons without the benefit of the V flag. Therefore, I suspect most 6502/65C02 programs using CMP for conditional branching should not care if the V flag is set or not.

All that being said, I didn't allow CMP to set V flag in the 8-bit mode of my M65C02A core because I was trying to maintain a high degree of compatibility with the 6502/65C02 processors. I opted to add my extensions to my M65C02A core in a manner that should allow legacy applications to run unmodified. In my M65C02A core, the 16-bit version of the CMP instruction sets the V flag, and I've extended the conditional branches that core provides to use the V flag to derive conditional branches like less than (BLT), less than or equal (BLE), greater (BGT), and greater than or equal (BGE).

_________________
Michael A.

It's a funny little wrinkle in the instruction set - I wonder if it's related to the SOB input pin, which allows external events to set the V flag? In those few designs which use that pin, it would be useful to be able to use more instructions without the possibility of changing that flag.

Which is to say, arithmetically, having CMP update V just as SBC does makes good sense.

I do believe there have been times that I was glad that V, which I probably had set or cleared by BIT, was unaffected by a comparison, so I could branch on V later. I can't remember details though.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Some 6502 coders with a keen obsession to optimize for size and/or speed may use the V flag for things like a loop exit flag when C is already being used elsewhere in the loop body. See this for a specific example. Little gems like this probably account for a tiny percentage of working code that would break and need to be rewritten, but that percentage is not 0.00000000%. I am reminded of reading somewhere about a subtle parity bit difference between the 8080 and Z80 that was a porting issue with some early Microsoft code.

Mike B.

How many signed number are only 8 bits wide?

I think just setting V on a CMP is almost useless unless you have a CPC setting V.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Depending on your personal definition of zero, I would have to say either 255 or 256


I'm a little slow tonight ... what does CPC do?

Mike B.

Compare with carry! I just meant to say that you need a new opcode anyway.

If I think of it more thoroughly a CPC wouldn't help eather as the justification for CPC over SBC is to leave the accumulator alone. With a larger than 8-bit wide number the accumulator must be loaded with individual bytes of one operand and the advantage of not changing the accumulator is waived.

So using SBC for signed compares seems almost perfect for me. No need to have a CMP with V as it is limited to 8-bit signed numbers only. SUB & ADD without carry or borrow would be a more obvious improvement.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5