Flags: N, V, Z, C - what are they worth to you?

[BigEd]

Mulling over alternative CPU designs, it feels like the four flags are not equal in usefulness. The following is a thought experiment.

If you could have a CPU that's 10% faster, 10% cheaper, would you give up one of the four flags? Which one?

If you could have a 25% faster, cheaper, CPU by dropping two flags, which would you drop?

What if we went down to one flag - which one should we have? How much gain would you demand in exchange?

(It's even possible to have no flags at all, as RISC-V does - you can compare-and-branch, and that turns out to be enough, and makes an aggressively pipelined machine simpler to implement and no doubt simpler to verify too. Which makes it cheaper and faster.)

[jim30109]

The V flag would probably be the obvious answer, but then the designers threw in the SO pin. That isn't a feature I've used, but at the same time I can see where it would be handy at times.

I was just reading things morning about One Instruction Set Computers (OISC). It sounds like an April Fools Day joke, but is a real thing and actually is usable. While you normally have op codes and operands, the OISC only has one instruction and, therefore, only needs to be fed operands.

While it is real and it is implementable, I'm not sure we'll be seeing a lot of OISC based machines anytime soon. I'm working through the software implemented example at:

https://pragprog.com/magazines/2012-03/the-nor-machine

There are other interesting examples and applications with a bit of searching.

Back to your question, for a CPU as cheap as the 6502 I probably wouldn't trade a flag for a 10% cost reduction. (I know it can add up in quantities, but will ignore that for now.) If you offered a CPU that could run 10% or 25% faster, then I might be more interested in the potential tradeoff.

Just my two cents worth...

Jim W4JBM

[Arlet]

Any particular reason why we can't keep all the flags ?

[BigEd]

Yes, it's hard to see that the machine would get very much faster or cheaper in reality ... but over in the One Page Computing challenge, a C-only machine and a ZC-machine both seem feasibly small and simple. For myself, although I see the point of the V flag, I think I could do without it. Which is to say, I think I've very rarely used it. Without the N flag, well, a quick comparison should give the same effect, when it's needed.

Quick check of some dynamic instruction frequencies: BNE and BEQ are the most popular branches, and BVS and BVC are the least popular.

[rwiker]

BigEd wrote:

Yes, it's hard to see that the machine would get very much faster or cheaper in reality ... but over in the One Page Computing challenge, a C-only machine and a ZC-machine both seem feasibly small and simple. For myself, although I see the point of the V flag, I think I could do without it. Which is to say, I think I've very rarely used it. Without the N flag, well, a quick comparison should give the same effect, when it's needed.

Quick check of some dynamic instruction frequencies: BNE and BEQ are the most popular branches, and BVS and BVC are the least popular.

I guess there are three sets of circumstances where the V flag is useful: signed arithmetic, I/O with devices where bit 6 of certain registers can be tested with and I/O that drives the SO pin. The latter two do not seem to used much except for with very MOS- (or Commodore-) centric hardware.

[GARTHWILSON]

I can't really imagine getting rid of any of those, although the only thing I've really used V for is with the BIT instruction, to branch on bit 6, and Jeff has some cool single-cycle I/O tricks that use the SO\ input. I don't think I've ever actually used V for indicating overflow of signed-number calculations. The PIC16 I've used so much lacks the N flag, and you can't even test the W (working) register directly, so you have to AND it with literal $80, losing your original value, which has been a pain sometimes. It does have a DC (digit carry) flag, but I have not really found that to be useful. I would like to add an F flag, reflecting that a result is exactly $FF (not just any negative number).

Apparently there have been various 6502 knock-offs for game machines that didn't have decimal mode and its D flag; but I know that one wasn't on your list, probably because it's for control, not for telling something about a result. I haven't used decimal mode in many, many years. There have also been ones with no IRQ\ input, so the I flag would go unused. I can't go without interrupts for my uses though.

[BigDumbDinosaur]

BigEd wrote:

Mulling over alternative CPU designs, it feels like the four flags are not equal in usefulness. The following is a thought experiment.

If you could have a CPU that's 10% faster, 10% cheaper, would you give up one of the four flags? Which one?

If you could have a 25% faster, cheaper, CPU by dropping two flags, which would you drop?

What if we went down to one flag - which one should we have? How much gain would you demand in exchange?

(It's even possible to have no flags at all, as RISC-V does - you can compare-and-branch, and that turns out to be enough, and makes an aggressively pipelined machine simpler to implement and no doubt simpler to verify too. Which makes it cheaper and faster.)

I'd be unwilling to give up any of them.

[White Flame]

In my AcheronVM, the only flags that I keep are the Carry flag (and a stack of up to 8 of the last Carry outputs, that are popped when used), and which is the "prior" register. For "branch if negative", "branch if zero" and their complements, it reads the value of the prior register directly, instead of having all the other operations always setting N or Z flags regardless of whether they're used later or not.

I think I gleaned the above idea from Sweet16, but ran even further with it: The prior register becomes the active accumulator, so you can do ALU operations specifying only 1 operand. There are up to 128 addressable "registers", any of which could be the current accumulator. Pretty sure some other old CPUs had that notion as well, to reduce instruction size. It really helps with software dispatch speed, to not have to deal with more LDA (ip),Y instructions pulling extra operand bytes. It's sort of like having a Top Of Stack (as the "prior" is implicitly set by load/move instructions), combined with the advantages of register file directness.

However, while this has advantages in software, it's probably less instruction latency in hardware to implement the N and Z flags in the classical push-and-cache instead of this recalculate-when-needed style.

[GARTHWILSON]

Very interesting idea!

[Arlet]

I once wrote a stack based CPU using 18 bit wide RAM, of which 16 bits were used for data, and 2 bits for C and V flags. You could push the result on the stack, and then later, when you popped them back to the top, do a branch using the flags (Z and N were derived automatically from the data portion).

Edit: I put the code for this CPU on github: https://github.com/Arlet/stack-cpu
It was part of my first big verilog project. It doesn't actually have a V flag, but a "less-than" flag.

[cbmeeks]

Am I the only old curmudgeon here that thinks 1 MHz is fast enough? I grew up with the C64 after all.

You whippersnappers and your 14 MHz 65C02's need to stay off my lawn!

lol

[BigEd]

A related question which came up when trying to make a minimal machine: if you could only have one, would you rather have BEQ or BNE?

[Arlet]

I think BNE would be more useful for loops.

[BigEd]

Yes, that would be my guess too. We did collect some dynamic instruction frequencies in this thread:
viewtopic.php?p=45420#p45420
(Ignore my earlier numbers in that thread - something wrong with my data collection or analysis.)

[furrykef]

The zero flag cannot be dropped because it would be impractical if not impossible to do any kind of equality comparison or bit testing. CMP, AND, and BIT become a whole lot less useful.

The carry flag is essential for doing comparisons. How would you write "if foo < bar" without doing a CMP instruction and checking the carry flag? It could be done, but it'd be unintuitive and quite slow. The same goes for 16-bit arithmetic, to say nothing of 24-bit and beyond.

The N flag is not essential. It's darn handy sometimes and I wouldn't care to part with it, but you can replace it with a check for the high bit. In 65C02 and 65816 you can do BIT #$80, for example, and an equivalent on the vanilla 6502 is not difficult.

The V flag is often considered the 6502's least useful flag. Even large programs may never use it at all. That said, two's complement signed comparisons become a lot more difficult without the V flag -- difficult enough that it may be considered preferable to use a different way to encode signed numbers, such as excess-128 (where $00 represents -128 and $FF represents 127). In fact, I've used that representation once even though we do have the V flag, so I consider the V flag nonessential.

So there you have it. If I were to kill two of the flags, I'd kill N and V. If I had to kill just one, I'd probably kill V.