In old 8-bit processors the status register flags are automatically updated on executing an instruction.

-Some status register flags are processor state that determining what state the processor is in. I - Interrupt enable, D - Decimal mode.
-Some are used in calculations, C – Carry, H – Half-carry, and store parts of the result from the operation.
-Some flags are updated from the result of the last operation, Z – Zero, N – Negative, P - Parity, , V - Overflow.

The last group of flags are never used within an instruction to calculate the new result. They are only used in Branch instructions to determine if a branch should be taken or not. What if we remove the automatic calculation of these flags from the execution path, and only calculate them when needed in a branch instruction? This should shorten the execution time of operations in the ALU and might make the processor able to run a little bit faster clock speed.

The V - Overflow flag use multiple operands of the operation, and might be easier to calculate during the execution of the operation.

When executing a branch on any of the Z, N, P flags, on the second cycle when the processor fetches the branch target offset, it will have a free cycle to calculate the value of the flag used in the branch from the previous operation result. The value is then ready in the third cycle to determine if the branch should be taken or not. Thus, the deferred calculation of the flag does not incur any penalty cycles compared to if it were previously calculated.

This will also mean that these flags are no longer needed in the status register, and will free the bits for other uses.
Removing them will not break interrupts and return from interrupts as the accumulator will still holding the latest result.

The above reasoning is of course flawed. The last result is not always stored in the accumulator as some operations are done directly on memory and then the flags cannot be recalculated without having the result present. Some operations do not even store a result at all but only update the flags.
However, the result from such operations may still be available inside the processor in a data buffer and maybe can be reused to calculate the flags. But to make this work with an interrupt system that buffer must also be stacked.

The last paragraph might actually make the V – Overflow bit superfluous also, and better calculated on test only.

The all above is an insights that struck me when looking into a Test instruction. The objective of all might be to remove unnecessary bits from the status register or maybe shorten the execution path of the ALU. While this is only an outdated theoretical topic, maybe with some further ideas the limitations can be worked around or be used with other restrictions.

It's certainly a tactic sometimes used by emulators, to calculate the more expensive flags only when needed.

I lookup result and flag separately. Sometimes we only need the result bytes and no need to examine what flag bits might have done. Sometimes we only need flags and ignore the result. No reason to gather information that won't be used. Also because flags are a wasteful fit to memory for simultaneous access.

Flags are a tricky topic. I just use the carry flag as status. Since I don't have a 'CMP' instruction have no need for flags.
BCC tests a AC for + - Zero. SCC sets a AC 0/1 for condition. This works for this CPU. Add,sub set the carrry flag,
Adx,sbx has no effect. Ben.

Hi, I believe you are describing Predication, which very loosely is making a instruction (usually a branch) conditional on the state of a flag that is created concurrently during the instruction's execution.

https://en.wikipedia.org/wiki/Predicati ... chitecture)

I posed a similar question to your question on the Vintage Computer Forum and received this very insightful set of replies:

https://forum.vcfed.org/index.php?threa ... l.1239938/

What most surprised me was the statement that this technique was used in the Apollo Guidance Computer, among others.

My project the LALU computer is capable of predication and I use it for all my conditional branches. I don't use predication for any other instructions at the moment, but I think it could be put to good use for memory operations.

Michael