rwessel (rrobertwessel.delete@this.yahoo.com) on February 18, 2013 12:01 am wrote:
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on February 17, 2013 1:47 pm wrote:
> > Linus Torvalds (torvalds.delete@this.linux-foundation.org) on February 15, 2013 6:34 pm wrote:
> > > Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on February 15, 2013 5:46 pm wrote:
> > > >
> > > > That's a good tradeoff, but you need 3 extra bits on compares of course
> > >
> > > It's worse than that. You'll want to do subtract-and-test,
> > > bitops, yadda yadda. Compare really isn't even close
> > > to complete. Otherwise you'll just end up playing games
> > > with other arithmetic-logical ops to then be able to
> > > compare the result. Which is *not* an improvement, no matter how some people would want to twist it,
> >
> > One condition bit for arithmetic and logical operations is enough,
> > more than 90% of the time you only need a zero/non-zero
> > result. You only need special opcodes for add with carry, but then again you need those anyway.
>
>
> I have to disagree. A single condition code bit fails to fully take advantage of the
> separation of the computation of the condition, and its interpretation and use.
>
> While comparing for equality (or a variation thereof) is certainly common, I don't think
> it's as common as you're saying. And with only a single CC bit, all of those will require
> specific instructions, or multiple instructions to compute the condition.

I don't think you get what I'm saying. Non-compare ALU instructions which set the flags are almost exclusively used for equality comparisons. See my other posts with all the statistics. That means if you support an adds instruction, setting the single condition bit on equality is the correct thing to do as it catches almost all cases.

Of course you have to move the condition field from the branch to compares.

> It's quite natural for a single comparison (or other) operation to be able to produce
> several results at once, especially as a tradeoff for a considerable multiplication
> of the number of versions of each CC setting instruction. SO if you're going to have
> CCs, having more that one bit is not much harder and has significant advantages.

You don't need extra versions of CC setting instructions. Supporting equality alone gets you 94% of cases compared to setting 4 condition bits. This can be done by adding a few extra encodings for add/sub/mov that set the flag on equal (thus avoiding using a bit on all ALU instructions like most RISCs).

> S/360 takes a fairly workable intermediate approach. It has a two bit CC, which is set various ways by
> different instructions. Instructions using the CC as input (branch, conditional move, etc.), have a four
> bit mask to determine which of the four possible conditions are to be tested for. This does mean that
> S/360 has separate signed and unsigned integer add instructions (sum is zero, negative, positive or overflow,
> in the signed case, and the four combinations of carry and zero in the unsigned case).
>
> OTOH, I think an intelligent selection of compare-and-branch instructions can
> eliminate a lot of CC usage and instruction pairs, and I think most ISAs have
> too many instructions which set the CCs (or not enough that don't).

Indeed. Flag setting ALU instructions are just not very useful in general.

Wilco