Is there a CPU ISA preferring a test for the value of one over testing for zero?

Question

While discussing a question about the origin of Zero as value for the default exit code for success, I reflected if there is any Instruction Set Architecture or implementation thereof where testing a byte or word for a value of ONE is favoured over testing for a value of ZERO, but couldn't think of any. All ISA I have meet so far do worst in handling a test for ONE.

Or in a more generic form: is there any ISA treating any discrete value, i.e. a single value, not a range, other then zero, privileged over zero?

(To keep wording simple I'll continue asking about a value of one, but any other than zero will do it)

To give a clear benchmark: The test for ONE must measured against the test for ZERO on these criteria with lower numbers being better:

• number clock cycles
• required memory footprint
• number of instructions

A solution is considered better if it has a lower value on any of these criteria, while not being higher on any of the other. Mixed cases (one higher one lower) might be as well valid after a closer look.

Note, this is about a test of the values of ONE or ZERO of a byte or larger memory unit (like a word), as used for return values. This is not about testing single bit tests (within a byte or word). Of course methods that test for a value of one using on bit test instruction are quite fine. Also, the test must be non-destructive.

So, is there any ISA where testing for a value other than zero performs better than testing for zero?

---

Bonus: An ISA where testing for any other discrete values is as privileged as testing for zero would already be interesting.

(Note: it still must be privileged over generic compare)

---

Examples

For example on a 6502 (or 68xx) testing a byte for a one value can be done by loading the value to be tested and compared :

 LDA  <value>
 CMP  #1
 BEQ  was_one

Or, if no longer needed in A decrementing will save a byte (only 65C02)

 LDA  <value>
 DEA
 BEQ  was_one

In contrast, testing for zero is done by just loading the byte in question:

 LDA  <value>
 BEQ  was_zero

This is possible as a load instruction sets the zero flag accordingly. Thus testing for zero will always be one instruction less, at least one byte shorter and two clocks faster than testing for one.

Of course this is a benefit of architectures that set flags during load. Architectures that set their flags/condition codes only due test instruction will usually need more instructions, but still often prefer tests for zero. For example an 8080 needs with

 LDA  <value>
 ORA  A
 JZ   was_zero

6 bytes and 27 cycles, while testing for one will be as well 3 instructions, but 7 bytes and 30 cycles

 LDA  <value>
 CPI  1
 JZ   was_one
 

Two address architectures like x86 or /370 will usually perform equal for both cases, as it comes down ot a simple compare - unless the input is already in a register, where a test instruction again prefers test for zero.

---

P.S.: I'm confident RC.SE patrons will soon find all possible loopholes :))

Answer 1

ISZ on the PDP-8.

In the special case where the flag will only ever be tested once (because the test trashes the flag), the PDP-8 "ISZ" instruction distinguishes the value -1 from all other values.

This allows the construction of a 2-word (24 bit) conditional branch, the shortest possible on this ISA.

ISZ     flag
JMP     notset
...     / it was set (to -1)

Also, this sequence does not perturb any registers, which is very useful as there is only one of those.

Testing for zero on the same machine requires 3 words,

TAD     flag
SZA
JMP     notset
...     / it was set (to 0)

and trashes all the registers.

Answer 2

In the General Instruments PIC architecture families that debuted in the 1970s, and were adapted into the Microchip architecture families of the same name, there is no instruction to directly test whether the entire byte at an address is zero, but there are instructions to directly test whether bit 0 of a byte is set, whether bit 1 of a byte is set, etc. up through bit 7. To test whether an entire byte is zero, one must read the entire byte and then test whether bit 2 of the status register is set (it will be set if the byte was zero).

On the 6502, one can quickly test for whether a byte is zero by loading it into a register if one doesn't mind trashing the value of the register in question. On the other hand, it's possible to simultaneously test the state of both of the upper two bits of a byte in memory, and branch on them separately, without affecting the state of any registers. Thus, storing a pair of flags in the top two bits of a byte may allow code that would generally need to inspect both of them whenever inspecting either to be more efficient than would be possible if the bits were stored in two separate bytes.

Answer 3

A little contrived, but:

The PDP-11 (in all but the earliest models) has the SOB instruction:

SOB Rn, LABEL

The register is decremented, and if the result is non-zero, a branch is made to LABEL. Thus you can code a (destructive) test for Rn == 1 in a single instruction.

Any similar test for zero, unless you already have the condition codes set from the previous instruction, requires at least two instructions:

 TST  Rn
 BEQ  LABEL

I grant you that the advantage is lost as soon as you're talking about a value in memory.

Answer 4

The Burroughs B5000 has no way to test a complete word directly against a value, be it zero or one. Looking at the instructions (section 5), the only conditional branch operations are BFC (branch forward conditional) and BBC (branch backward conditional), which both test the low-order bit of register B (the next to top-of-stack register) and branch if this bit is zero.

So while you can directly branch on "boolean" values (where only the low-order bit counts), for everything else you need to load a literal and execute a comparison.

So as far as testing for complete values is concerned, zero performs equally well as any other value, and the particular case if taking the branch the low-order bit is clear performs better.

So that at least sort of matches the question in the sense that testing for particular values is "as privileged" as testing for a complete zero.

Answer 5

I dimly recall the i960 setting aside a few bits in certain instructions so that the opcode could include a small number, possibly 4 bits signed IIRC so that values in the range -8 to +7 could be handled without the need for a second fetch cycle. That wouldn’t make any value faster than testing for zero but would make the performance equal. The engineers at Intel had realised that the majority of numbers handled at machine code level were quite small and so this feature could significantly boost performance in a fairly wide range of situations, well worth setting aside some bits of the RISC instruction set for (who needs 4 billion instruction types anyway).