By: Michael S (already5chosen.delete@this.yahoo.com), November 7, 2019 1:58 am
Room: Moderated Discussions
Ronald Maas (ronaldjmaas.delete@this.gmail.com) on November 6, 2019 11:53 pm wrote:
> anon.1 (abc.delete@this.def.com) on November 6, 2019 9:36 pm wrote:
> > Doug S (foo.delete@this.bar.bar) on November 6, 2019 11:47 am wrote:
> > > anon.1 (abc.delete@this.def.com) on November 6, 2019 11:19 am wrote:
> > > > The whole point of RISC was to make
> > > > decode simple. Now they want to add complexity in decode because, well, the ISA is oversimplified.
> > >
> > >
> > > The RISC concept was created 40 years ago. Things have changed, designers have a transistor
> > > budget orders of magnitude larger today so what was appropriate for a decoder in 1980
> > > shouldn't be a limitation on what is appropriate for a decoder in 2020.
> >
> > Pretty damning then that an ISA produced in this decade is
> > based on design principles aimed at solving problems
> > dating back 40 years. Seems like the memo didn’t travel into the academic ivory towers. Also, note that
> > RISC was concerned with pipelining for frequency. They wanted minimum gates in the critical paths. Area
> > is somewhat of a contributor to it but not the main one. ISA decode complexity is. The more encodings you
> > have, the more information you store per instruction and the more work you have to do in decode.
>
> 5000 year ago we used wheels for transportation. And today we still use wheels
> for transportation. Does not necessarily means every old idea is bad.
>
> Once implementation complexity exceeds a certain level and RISC-V implementations start to
> implement a full spectrum of extensions, caches, branch prediction, etc. the differences between
> ARMv8 vs RISC-V start to become less relevant from a technology perspective. Performance,
> energy efficiency, die area, design and validation efforts for processor implementations targeting
> higher transistor budgets will be closely matched regardless of the ISA.
>
> Because of that, claiming that ARM is superior compared to RISC-V or vice versa, is meaningless.
> Both are excellent ISAs. It will be the other factors that will drive the implementation choice.
> Such as licensing terms, maturity of the eco-system, familiarity with certain ISAs, etc. etc.
>
> Ronald
RISC-V is not an obviously bad ISA. But excellent? My idea of technical excellence is "getting close to maximum out of given resource". RISC-V is not here and does not even try.
If one looks for excellent ISA in RISC-V (RVC) own class of "relatively simple" I'd rather think about nanoMIPS. I was *very* impressed by it, at least from code density perspective.
> anon.1 (abc.delete@this.def.com) on November 6, 2019 9:36 pm wrote:
> > Doug S (foo.delete@this.bar.bar) on November 6, 2019 11:47 am wrote:
> > > anon.1 (abc.delete@this.def.com) on November 6, 2019 11:19 am wrote:
> > > > The whole point of RISC was to make
> > > > decode simple. Now they want to add complexity in decode because, well, the ISA is oversimplified.
> > >
> > >
> > > The RISC concept was created 40 years ago. Things have changed, designers have a transistor
> > > budget orders of magnitude larger today so what was appropriate for a decoder in 1980
> > > shouldn't be a limitation on what is appropriate for a decoder in 2020.
> >
> > Pretty damning then that an ISA produced in this decade is
> > based on design principles aimed at solving problems
> > dating back 40 years. Seems like the memo didn’t travel into the academic ivory towers. Also, note that
> > RISC was concerned with pipelining for frequency. They wanted minimum gates in the critical paths. Area
> > is somewhat of a contributor to it but not the main one. ISA decode complexity is. The more encodings you
> > have, the more information you store per instruction and the more work you have to do in decode.
>
> 5000 year ago we used wheels for transportation. And today we still use wheels
> for transportation. Does not necessarily means every old idea is bad.
>
> Once implementation complexity exceeds a certain level and RISC-V implementations start to
> implement a full spectrum of extensions, caches, branch prediction, etc. the differences between
> ARMv8 vs RISC-V start to become less relevant from a technology perspective. Performance,
> energy efficiency, die area, design and validation efforts for processor implementations targeting
> higher transistor budgets will be closely matched regardless of the ISA.
>
> Because of that, claiming that ARM is superior compared to RISC-V or vice versa, is meaningless.
> Both are excellent ISAs. It will be the other factors that will drive the implementation choice.
> Such as licensing terms, maturity of the eco-system, familiarity with certain ISAs, etc. etc.
>
> Ronald
RISC-V is not an obviously bad ISA. But excellent? My idea of technical excellence is "getting close to maximum out of given resource". RISC-V is not here and does not even try.
If one looks for excellent ISA in RISC-V (RVC) own class of "relatively simple" I'd rather think about nanoMIPS. I was *very* impressed by it, at least from code density perspective.