The NZVC condition codes scheme, and corresponding set of 14 conditions for branches, is the nearly only in current ISAs that utilizes condition codes at all. The first computer I know that used it is PDP-11 (1970).

Is PDP-11 the truly first for this?

How this scheme has been invented? I failed to find similar prototypes in earlier computers, and it looks like appeared "from scratch". The condition codes themselves in Program Status Word register (whatever used name was) were, of course, known for more than decade, but no such elaborated scheme was present. This looks like a single genius strike. Are there any memories from DEC?

UPDATE: more details: for example, to compare with System/360:

Signed arithmetic instructions produce condition code:

  • CC=0: no overflow, result == 0
  • CC=1: no overflow, result > 0
  • CC=2: no overflow, result < 0
  • CC=3: overflow, result sign/zero are irrelevant, compared with the overflow fact

Unsigned ("logical") arithmetic instructions produce condition code:

  • CC[0]: result is not zero
  • CC[1]: carry out of result width

One should combine results of both types to a single condition code set, and this is the first part of the leap I mean. The second one is using carry flag in combined 3-argument ADC/SBC operations (S/360 haven't done this despite carry bit in CC).


My take is that this scheme has been invented the same way everything has been invented: Slowly, by evolution and combining existing ideas, and not "from scratch" by a strike of genius.

The carry flag has been around a long time before that (other PDPs, and previous computers). Branches or skips that test the carry flag have also been around (other PDPs, and previous computers). Branches or skips that combine testing the carry flag with testing the accumulator for the sign bit, or equality to zero have also been around.

From there it's only a small step to add extra flag bits for the sign and zero to the carry flag, especially if you are about to make a program status word anyway. And while you are at it, you can also add on overflow bit for signed 2's complement.

If anything, I'd consider the overflow bit for signed 2's complement a strike of genius, because that (and its implementation) isn't really obvious.

  • Carry is pretty obvious because the simplest logic element implementing an accumulator, the half adder, already produces it. The others are just combinations of bits entering and leaving the uppermost bit.
    – tofro
    Apr 28 '18 at 6:01
  • @tofro: I think the important step that instead of just producing a carry, storing it in a flag-register was what already has been accomplished (and that's also not hard, because you have to do something with the carry output, once you go beyond a bit-serial implementation where you just feed it back). The other flags are just extending that principle.
    – dirkt
    Apr 28 '18 at 6:11
  • 1
    @dirkt Overflow detection in the same manner is known since System/360 or earlier. It exposed overflow as CC=3 for arithmetic instructions, and carry as CC[1]=1 for logical (i.e. unsigned) instructions.
    – Netch
    Apr 29 '18 at 6:35
  • 2
    @Netch: I didn't say it's new, or happened at this particular stage. I said the logic how to do overflow detection in two's complement isn't obvious (at least to me). While pretty much all of the rest is.
    – dirkt
    Apr 29 '18 at 10:52
  • 2
    @rackandboneman: As the question states, prior designs didn't do it that way, so it's certainly not a byproduct of the hardware design; it's a design choice.
    – dirkt
    May 3 '18 at 4:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.