By: Michael S (already5chosen.delete@this.yahoo.com), February 4, 2013 1:50 am
Room: Moderated Discussions
rwessel (robertwessel.delete@this.yahoo.com) on February 4, 2013 12:37 am wrote:
> anon (anon.delete@this.anon.com) on February 3, 2013 10:06 pm wrote:
> > Patrick Chase (patrickjchase.delete@this.gmail.com) on February 3, 2013 7:40 pm wrote:
> > > anon (anon.delete@this.anon.com) on February 3, 2013 6:11 pm wrote:
> > > > Patrick Chase (patrickjchase.delete@this.gmail.com) on February 3, 2013 4:29 pm wrote:
> > > > > Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 2, 2013 11:10 am wrote:
> > > >
> > > > > > A clean RISC like Alpha (or--from what I have read--AArch64) would be much more friendly to fast bring-up
> > > > > > of a decent microarchitecture. (Classic ARM seems to be somewhere in the middle--not as complex as x86 but
> > > > > > not as simple as Alpha--, but even with Thumb2+classic ARM it might be closer to Alpha than to x86.)
> > > > >
> > > > > AArch64 is indeed a nice, classic RISC architecture. In particular they fixed the biggest
> > > > > single limitation of classic ARM (spending instruction encoding bits on condition-based
> > > > > predication at the expense of GPRs). I'd put it somewhere between MIPS and Alpha on
> > > > > the "architectural purity scale", and that's a pretty good place to be.
> > > >
> > > > What are some aspects of the ISA that make it less clean than Alpha, would you say?
> >
> > Thanks for the answer.
> >
> > >
> > > Continued reliance on condition flags.
> >
> > What is cleaner? GPR for comparison/branch?
>
>
> I think most people would say yes. If nothing else, it lets
> you omit a whole rename mechanism for the flags register.
>
Which (additional rename mechanism) can be considered opportunity rather than limitation.
Several specialized renamers can be easier (or not) to build than one wide renamer of the same effective width. The same, but with higher certainty, applies to several specialized register files vs unified register file with the same effective number of read/write ports.
Also, I'd think that useful uArch tricks like Intel's compare+branch macroOp fusion are easier with a single software-visible set of flags than with either register-based branches or multiple sets of arithmetic flags.
> That being said there are better and worse ways to do that, and perhaps an even better alterative is a
> compare-and-branch instruction (although I wouldn’t want that as the only comparison instruction).
>
IIRC, MIPS has compare-and-branch-on-equal/nonequal
Altera Nios2, which is in many other aspects almost carbon copy of MIPS, have complete set of 2-reg compare-and-branch instructions.
> anon (anon.delete@this.anon.com) on February 3, 2013 10:06 pm wrote:
> > Patrick Chase (patrickjchase.delete@this.gmail.com) on February 3, 2013 7:40 pm wrote:
> > > anon (anon.delete@this.anon.com) on February 3, 2013 6:11 pm wrote:
> > > > Patrick Chase (patrickjchase.delete@this.gmail.com) on February 3, 2013 4:29 pm wrote:
> > > > > Paul A. Clayton (paaronclayton.delete@this.gmail.com) on February 2, 2013 11:10 am wrote:
> > > >
> > > > > > A clean RISC like Alpha (or--from what I have read--AArch64) would be much more friendly to fast bring-up
> > > > > > of a decent microarchitecture. (Classic ARM seems to be somewhere in the middle--not as complex as x86 but
> > > > > > not as simple as Alpha--, but even with Thumb2+classic ARM it might be closer to Alpha than to x86.)
> > > > >
> > > > > AArch64 is indeed a nice, classic RISC architecture. In particular they fixed the biggest
> > > > > single limitation of classic ARM (spending instruction encoding bits on condition-based
> > > > > predication at the expense of GPRs). I'd put it somewhere between MIPS and Alpha on
> > > > > the "architectural purity scale", and that's a pretty good place to be.
> > > >
> > > > What are some aspects of the ISA that make it less clean than Alpha, would you say?
> >
> > Thanks for the answer.
> >
> > >
> > > Continued reliance on condition flags.
> >
> > What is cleaner? GPR for comparison/branch?
>
>
> I think most people would say yes. If nothing else, it lets
> you omit a whole rename mechanism for the flags register.
>
Which (additional rename mechanism) can be considered opportunity rather than limitation.
Several specialized renamers can be easier (or not) to build than one wide renamer of the same effective width. The same, but with higher certainty, applies to several specialized register files vs unified register file with the same effective number of read/write ports.
Also, I'd think that useful uArch tricks like Intel's compare+branch macroOp fusion are easier with a single software-visible set of flags than with either register-based branches or multiple sets of arithmetic flags.
> That being said there are better and worse ways to do that, and perhaps an even better alterative is a
> compare-and-branch instruction (although I wouldn’t want that as the only comparison instruction).
>
IIRC, MIPS has compare-and-branch-on-equal/nonequal
Altera Nios2, which is in many other aspects almost carbon copy of MIPS, have complete set of 2-reg compare-and-branch instructions.