By: Michael S (already5chosen.delete@this.yahoo.com), November 4, 2019 11:17 am
Room: Moderated Discussions
David Hess (davidwhess.delete@this.gmail.com) on November 4, 2019 10:11 am wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on November 4, 2019 9:59 am wrote:
> > David Hess (davidwhess.delete@this.gmail.com) on November 4, 2019 9:38 am wrote:
> > > Heikki Kultala (heikki.kultala.delete@this.tuni.fi) on November 2, 2019 1:31 am wrote:
> > > >
> > > > It's just "lets fix the worst things from the 1980's RISCs" but nothing more. It's still
> > > > "way too RISC" ignoring most of the things we have learned in the last 30 years.
> > >
> > > It is like RISC-V is the anti-Alpha although Alpha had its own problems.
> >
> > Actually, RISC-V is coming from the same school as Alpha. Both are extremely orthodox followers of
> > MIPS philosophy. Both fix obvious MIPS mistakes like branch delay slots and load delay slots (the
> > later was already fixed by MIPS itself, by time Alpha evolved into shipping product). But both follow
> > 2R1W regime much stricter than MIPS itself (except MIPS Release 6, which is equally strict).
>
> I mean specifically how Alpha was designed to support implementations taking advantage
> of increased integration 20 years later. Or at least was not designed to impede
> taking advantage of increased integration over several generations.
>
Mostly propaganda.
Alpha designers were no batter than anybody else at prediction future needs and constrains.
> > > > And then it just became popular because of the open source hype. I'd much
> > > > rather seen some better open source instruction set to get popular.
> > > >
> > > > Lack of conditional moves is bad.
> > > >
> > > > But lack of any kind of SIMD? Yes, I know that they are multiple proposals for adding SIMD,
> > > > but they are not yet standardized. And then it will be a mess that what is implemented.
> > > > Specifying just opcodes which just cut the carry path from an add and sub and split the
> > > > multiplier would have been VERY CHEAP hardware-wise but they didn't do even that.
> > >
> > > Over on EEVBlog, I made the same observation about the lack of discrete conditional jumps.
> >
> > Do you mean "lack of conditional move" ?
>
> It has been a while so it might have been. What I remember is lack of support for "conditionals"
> leading to documentation showing how they are implemented with multi-instruction sequences.
>
Then it should be about cmoves.
RISC-V conditional branches are among the best in the industry.
> Michael S (already5chosen.delete@this.yahoo.com) on November 4, 2019 9:59 am wrote:
> > David Hess (davidwhess.delete@this.gmail.com) on November 4, 2019 9:38 am wrote:
> > > Heikki Kultala (heikki.kultala.delete@this.tuni.fi) on November 2, 2019 1:31 am wrote:
> > > >
> > > > It's just "lets fix the worst things from the 1980's RISCs" but nothing more. It's still
> > > > "way too RISC" ignoring most of the things we have learned in the last 30 years.
> > >
> > > It is like RISC-V is the anti-Alpha although Alpha had its own problems.
> >
> > Actually, RISC-V is coming from the same school as Alpha. Both are extremely orthodox followers of
> > MIPS philosophy. Both fix obvious MIPS mistakes like branch delay slots and load delay slots (the
> > later was already fixed by MIPS itself, by time Alpha evolved into shipping product). But both follow
> > 2R1W regime much stricter than MIPS itself (except MIPS Release 6, which is equally strict).
>
> I mean specifically how Alpha was designed to support implementations taking advantage
> of increased integration 20 years later. Or at least was not designed to impede
> taking advantage of increased integration over several generations.
>
Mostly propaganda.
Alpha designers were no batter than anybody else at prediction future needs and constrains.
> > > > And then it just became popular because of the open source hype. I'd much
> > > > rather seen some better open source instruction set to get popular.
> > > >
> > > > Lack of conditional moves is bad.
> > > >
> > > > But lack of any kind of SIMD? Yes, I know that they are multiple proposals for adding SIMD,
> > > > but they are not yet standardized. And then it will be a mess that what is implemented.
> > > > Specifying just opcodes which just cut the carry path from an add and sub and split the
> > > > multiplier would have been VERY CHEAP hardware-wise but they didn't do even that.
> > >
> > > Over on EEVBlog, I made the same observation about the lack of discrete conditional jumps.
> >
> > Do you mean "lack of conditional move" ?
>
> It has been a while so it might have been. What I remember is lack of support for "conditionals"
> leading to documentation showing how they are implemented with multi-instruction sequences.
>
Then it should be about cmoves.
RISC-V conditional branches are among the best in the industry.
