Well, if you have carry, you can test for zero by adding FF and then testing the carry - so zero is optional. But I agree, it's very useful!

In a recent but very recently superseded effort at a minimal CPU, we had predicates for carry and non-zero. (We thought that branching on non-zero is just a little more valuable than branching on zero.)

Interestingly, in an accumulator machine you could have a test for zero which tests the accumulator directly, and yet omit the zero flag. So that's an intermediate situation - you have a test, but no flag bit. Once you start adding other registers, like the 6502's X and Y, then a zero flag looks more useful - only being able to test the accumulator is limiting.

The main thing I've used V for is branching following a BIT instruction for hardware input (since BIT transfers bit 6 to V, regardless of what's in A). Jeff Laughton uses it also in his 65c02 designs for ultrafast I/O as shown at http://wilsonminesco.com/6502primer/potpourri.html#Jeff .

_________________
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?

I extensively use flags in POC's firmware in which both bits 7 and 6 are significant. Testing with a BIT instruction is fast and economical in such cases.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

The processor flags as a whole are completely unnecessary if a CPU instruction set is designed that way. Instead of having instructions like "branch if ... flag is set/clear", we have "branch if RegX > RegY" or "brankch if RegX is zero/nonzero". We could even do it 65xx style and have "branch if A is higher than MEM" or stuff like that. It's just as intuitive, and removes the need for flags. The major inconvenient is that it needs a wider set of instructions to reach the same functionality, and is harder to delay decisions (rather than just store the decision in the flag and use later, we have to keep the comparison source in registers).

If I had a fixed function project that had certain timing to meet, I was within 10% of it but just couldn't get there, then goodbye V flag.

I don't think I'd want to lose any of the other flags as it would make all reference code incompatible, and make writing code more painful. That said, if I _had_ to choose:

• 3 flags: N, Z, C
• 2 flags: Z, C
• 1 flag: C

On the last one, the C flag alone gives me both multi-byte arithmetic and BCC, BCS, which should be the basis for a lot of derived functionality. But like the "One Instruction Set Computer" approaches, simple operations can explode without the right tools. Something as simple as branching if A == some_value becomes a challenge without Z. How would I do it?... Hmmm.. Ok, here's one idea:

This is what I'd like to do, but I can't because no Z:


So instead, I'm going to make a function called cmpz, which returns equality in the C flag. If C=1 then equal, else not equal. cmpz EORs the two variables and then uses the result to branch into a 16-entry table that, at the [0] index, sets the C flag, and otherwise clear the C flag. As that comprises two instructions (e.g. SEC; RTS or CLC; RTS), I'll do it in two steps - first checking bits [3:0] of the EOR result and then [7:4]. The original pattern only uses A, and preserves it, and the function pattern will do the same.



Ugh, that looks awful. Can someone with more current 6502 experience save me from my 30 year atrophy?

Ha! Then I read BigEd's comment. Add #$FF. Of course.



Doesn't preserve the original pattern, but you get the idea.

"Hello, my name is dummy. Nice to meet you." - me.

If you don't have a Z flag, you can always create a "Branch if A is zero" instruction instead, which uses the entire register as a simulated flag. Forth does this with TOS a lot for decisions, for example. Without a C flag, you could also overwrite X or Y with carry. This obviously tramples a lot of state, but might reuse a lot of data paths in the CPU instead of routing to specialized flag registers.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Not all processors even have a V flag.
Add minus 1 and a C test for to replace Z. ( 2's complement )
N can be tested with an add to one self and a C test.
That leaves only C for every thing.
Dwight

MIPS processors (as in the PIC32) have no flags at all. There are a few conditional instructions (e.g. branch if reg1 == reg2, compare and set register, etc.) and a register that always contains zero and which can be compared against.

The compiler derives carry from intermediate results, for example 64-bit add on a 32-bit device.

The first ADDU add the low words, the second the high words. The SLTU sets V1 to one if a carry occurred otherwise zero. The final ADDU (in the delay slot after the jump to return address) propagates it into the result.

One of the add instructions can trigger an overflow interrupt but many languages like C don't use it.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Back in the 20th century I worked with minimalist CPU's that did multi-axis motion control, and the technology was 7400 series TTL (no microprocessor). Program memory was a pair of bipolar PROM's, and each 16-bit instruction included only three opcode bits. There were a few wrinkles that allowed eleven possible instructions, not just eight, but it was definitely minimal.

The machine had just a single status flag, and its meaning depended on the context (Dwight and Sark02 mentioned points along this line). The flag got its data from two possible sources. An ADD instruction would write its Carry result to the flag, whereas a BIT instruction caused the flag to update reflecting the Zero result.

There was only one instruction to test the flag -- a conditional branch. I don't recall whether it branched on flag set or on flag clear.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hi Dr.
As often with me, I missed that there was a page 2.
I get to excited to post and don't look.
Even Z can do all but a little different. I suspect
that one could even use N or V as well with a little
thought.
Dwight

Ah, yes. The infamous Diablo printer.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Very interesting thoughts and observations, everyone! I hadn't realised PIC32/MIPS was flag-free. I know RISC-V is.

For the OPC series of CPUs, it looks like we're going with Z and C at present, and just C for the minimal machine.

I've got a homebrew architecture which has four flags:
C - Carry
V - Overflow
I - Interrupt Enable
U - User

C & V are provided by the ALU chip I'm using. I is obvious what it does. U is never set or cleared by the hardware at all, but the programmer can do so, and it has its own set of branch instructions. I originally intended to have U be a Z flag, but the way i've implemented the flags register unfortunately makes this impossible. At least, I recall there being a reason but I cannot remember what it is now....

I did consider not using V and providing C and Z instead, but it does seem to me that V is particularly hard to simulate if you are using signed arithmetic and don't have the flag. Whereas Z is relatively easy to simulate.

EDIT: had a look at my circuit diagrams - its because it can't modify the U/Z flag without also clearing the I flag, which is not a good idea....

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Interesting! Have you written anything about your architecture?