By: Wilco (Wilco.Dijkstra.delete@this.ntlworld.com), February 25, 2013 6:19 am
Room: Moderated Discussions
EduardoS (no.delete@this.spam.com) on February 18, 2013 8:18 pm wrote:
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on February 18, 2013 5:33 pm wrote:
> > 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.
> >
> > 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).
> >
> > Indeed. Flag setting ALU instructions are just not very useful in general.
>
> And by looking only at GCC you missed a very specifc and yet important case, arbitrary precision arithmetic.
>
> By the numbers you posted on your other post, Alpha did the right thing.
Yes GCC doesn't use much 64-bit arithmetic, I didn't spot many adc instructions. Arbitrary precision arithmetic could be done with special instructions if it is essential to do it in the integer unit (rather than using SIMD which seems the natural way). My guess is that supporting efficient arithmetic at twice the integer size in the integer unit would be sufficient.
Yes Alpha was right - for compiled code you don't need condition codes. However it was a bit too pure in many aspects, and that is not good either.
Wilco
> Wilco (Wilco.Dijkstra.delete@this.ntlworld.com) on February 18, 2013 5:33 pm wrote:
> > 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.
> >
> > 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).
> >
> > Indeed. Flag setting ALU instructions are just not very useful in general.
>
> And by looking only at GCC you missed a very specifc and yet important case, arbitrary precision arithmetic.
>
> By the numbers you posted on your other post, Alpha did the right thing.
Yes GCC doesn't use much 64-bit arithmetic, I didn't spot many adc instructions. Arbitrary precision arithmetic could be done with special instructions if it is essential to do it in the integer unit (rather than using SIMD which seems the natural way). My guess is that supporting efficient arithmetic at twice the integer size in the integer unit would be sufficient.
Yes Alpha was right - for compiled code you don't need condition codes. However it was a bit too pure in many aspects, and that is not good either.
Wilco