Michael S (already5chosen.delete@this.yahoo.com) on February 27, 2013 4:24 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on February 26, 2013 11:13 am wrote:
>
> >
> > So yes, I don't dispute that the exact bit pattern details etc change. But I do claim that the
> > four flags are fundamental, and not at all random and implementation-defined in any conceptual
> > sense. The same way everybody wants to have an "add" instruction, everybody pretty much wants
> > to have the four status bits. They just sometimes get encoded really oddly (where "really oddly"
> > can include "don't ever have an instruction that sets them all, but have lots of instructions
> > to set each case separately", which I argue is stupid and only complicates things).
> >
> > Linus
>
> One thing bothers me w.r.t. "fundamentality" of four arithmetic flags: with four flags in hand it is possible
> to check for 2**16 different conditions. However all flags-based ISA's I am aware of have far fewer than
> 2**16 types of "arithmetic" conditional branches (the same applies to conditional moves).
> Take, for example, x86, SPARC and ARM.
> They are not just using almost the same definition of flags (except for ARM having different polarity
> of carry for subtracts), but their conditional facilities check for exactly the same 14 arithmetic
> conditions which are based on values of four flags. Somehow, it seems to me, that 12 out 14 conditions
> (equality, overflow, signed greater/less, unsigned greater/less plus opposites of all 6) are much
> more fundamental than four flags that are commonly used to implement them.
> I say 12 rather than 14, because I don't think that negative/non-negative conditions are really fundamental.
> IMHO those two are implemented in most flag-based ISAs not because they are especially usefull, but because
> they are easy to implement and there are 2 otherwise unused places in 4-bit condition field.
>
> Now, do we really need 4 flag bits in order to implement 12 (or even all 14) fundamental
> conditions? No, we don't. Up to 64 conditions, including all 14 defined in x86/ARM?SPARC,
> can be easyly derived from just 7 distinct states = 3 bits.
> For example, like those:
> 0 - unsigned_less && signed_less. Implied non-overflow && negative
> 1 - unsigned_less && signed_greater && non-overflow. Implied non-negative
> 2 - unsigned_less && signed_greater && overflow. Implied negative
> 3 - unsigned_greater && signed_less && non-overflow. Implied negative
> 4 - unsigned_greater && signed_less && overflow. Implied non-negative
> 5 - unsigned_greater && signed_greater. Implied non-overflow && non-negative
> 6 - equal. Implied non-overflow && non-negative
>
> O.k. I realize that I almost certainly reinvented some 60 y.o. wheel.


Why yes, yes you did. Or at least a 59 year old wheel. ;-)

As I mentioned upthread, S/360 uses a two bit CC, and different instructions set those in different ways. For example, signed addition sets (sum is) zero (0), less than zero (1), greater than zero (2) or overflow (3). The conditional branch instructions then specify a four bit mask to select which of the four possible CC values to branch on. For example, "BC 10,address" would branch if either 0* or 2 were set, or "sum greater than or equal to zero". Of course the assembler provides a shorthand for the popular combinations, and you can code "BNH address" after a compare instead of remembering that's actually a "BC 13,address".

And yes, you suggested a three bit CC. Having only a two bit CC means that S/360 has separate signed on unsigned arithmetic instructions, the major different being how the CCs are set (Add Logical, for example, sets the appropriate one of the four combinations of carry and zero).

But ZSCO are pretty fundamental, in that they’re both easy to derive, and adequately represent most of the interesting cases.


*S/360 tradition is to number bits from left to right, so the mask/value scheme makes perfect sense from that perspective.