3 ms·

There's nothing particular interesting about RISC-V. It's a simple, clean, boring MIPS-like ISA. A lot of their freedom to keep it simpler and cleaner than old

by wk_end 8y ago

There's nothing particular interesting about RISC-V. It's a simple, clean, boring MIPS-like ISA. A lot of their freedom to keep it simpler and cleaner than older RISC ISAs comes from the fact that they aren't responsible for engineering real implementations; whereas the MIPS and SPARC and ARM folks ended up with delay slots and register windows and conditional execution because it helped them get high speed CPUs out with the processes of the day, the RISC-V people just say "well, those eventually turn out to be bottlenecks for high speed-implementations, so we won't have them" - never mind that these hypothetical high-speed implementations will require enormous engineering efforts and will require piles of money to actually build. We're not quite talking "Sufficiently Smart Compiler", because the technology does exist - but it's not totally far off. People have been comparing it to Linux, but it's just an instruction set, not an implementation of one - so it's really more like POSIX - just a theoretical standard of compatibility that'll allow an ecosystem to build around it. The problem is that, as Someone mentions in this thread, there's lots of officially codified extensions, and no restrictions (as far as I know?) to keep implementors from devising their own. We'll see how this turns out; my guess is, if RISC-V catches on, we're going to end up with mutually incompatible extensions, balkanization, and proprietary extensions becoming accepted "standards" in the "embrace, extend, extinguish" style.

nickik 8y ago
> A lot of their freedom to keep it simpler and cleaner than older RISC ISAs comes from the fact that they aren't responsible for engineering real implementations; So David Patterns doesn't understand anything about implementations? They designed and tapped out many chips including out-of-order cores before they froze the ISA and they are confident that it works for simple and high-performance implementations. You seem to imply that 'delay slots and register windows and conditional execution' might not be needed for high performance but maybe that RISC-V does not have them harms them if they don't have 'high-speed implementations' but that is not correct. RISC-V is competitive or better compared MIPS, SPARC, ARM on the low end.
- wk_end 8y ago
  I don’t mean to suggest that the involved parties don’t know about microarchitectural implementations. Names aside, it’s clear from reading the RISC-V documents that they do. And I don’t mean to imply that they’re wrong about the various “unclean” elements of other RISC ISAs being bottlenecks, either. All I mean to say is: as academic designers of a license-free ISA in the 2010s, to whatever extent they’re incentivized at all, they’re incentivized towards designing a “simple” and “elegant” ISA regardless of the concrete impact on performance or die space in a way that the MIPS, SPARC, and ARM teams in the early 80s - designing for commercial production and profitability using the processes of the time and their limited resources - weren’t. That’s not necessarily a criticism - but the consequences of their decisions on performance and adoption are harder to say. You’re claiming otherwise, but without further evidence and based on my personal understanding of architecture and microarchitecture design I believe that ceteris paribus a low-end RISC-V implementation is likely to perform worse and use more silicon than the corresponding MIPS, ARM, or SPARC implementations. A high-end speculative, out-of-order, modern process, etc RISC-V implementation would likely be able to outperform a similar one for those architectures with less silicon. The question for me is whether we get to the point where the market builds one, and whether those potential performance improvements would (alone or in tandem with RISC-V’s other benefits) justify adoption.
  - nickik 8y ago
    I see your point about intensives. However I have to disagree on your opinion on the hardware. RISC-V was specifically designed to be able to do low end very well. The whole encoding for example is optimized to a tiny amount of space. The overall instruction set again is designed to use minimum amount of space as well. There is a whole project about 'ultra low power processors' at ETH Zürich [1]. They have specifically selected RISC-V because it fit their needs so well and they produce cores that beat available ARM and MIPS cores specially on energy. IBM selected a RISC-V core for their project in 'Next-Generation Edge Computing' [2]. So it seems to me that small and simple really does pay of when going to very tiny cores. [1] https://www.pulp-platform.org/ https://www.pulp-platform.org/ [2] https://content.riscv.org/wp-content/uploads/2018/05/16.10-16.25-Seiji-Munetoh-IBM-Japan.pdf https://content.riscv.org/wp-content/uploads/2018/05/16.10-1...
brandmeyer 8y ago
cough cough, static rounding modes, cough

by wk_end 8y ago

nickik 8y ago

> A lot of their freedom to keep it simpler and cleaner than older RISC ISAs comes from the fact that they aren't responsible for engineering real implementations; So David Patterns doesn't understand anything about implementations? They designed and tapped out many chips including out-of-order cores before they froze the ISA and they are confident that it works for simple and high-performance implementations. You seem to imply that 'delay slots and register windows and conditional execution' might not be needed for high performance but maybe that RISC-V does not have them harms them if they don't have 'high-speed implementations' but that is not correct. RISC-V is competitive or better compared MIPS, SPARC, ARM on the low end.

wk_end 8y ago
I don’t mean to suggest that the involved parties don’t know about microarchitectural implementations. Names aside, it’s clear from reading the RISC-V documents that they do. And I don’t mean to imply that they’re wrong about the various “unclean” elements of other RISC ISAs being bottlenecks, either. All I mean to say is: as academic designers of a license-free ISA in the 2010s, to whatever extent they’re incentivized at all, they’re incentivized towards designing a “simple” and “elegant” ISA regardless of the concrete impact on performance or die space in a way that the MIPS, SPARC, and ARM teams in the early 80s - designing for commercial production and profitability using the processes of the time and their limited resources - weren’t. That’s not necessarily a criticism - but the consequences of their decisions on performance and adoption are harder to say. You’re claiming otherwise, but without further evidence and based on my personal understanding of architecture and microarchitecture design I believe that ceteris paribus a low-end RISC-V implementation is likely to perform worse and use more silicon than the corresponding MIPS, ARM, or SPARC implementations. A high-end speculative, out-of-order, modern process, etc RISC-V implementation would likely be able to outperform a similar one for those architectures with less silicon. The question for me is whether we get to the point where the market builds one, and whether those potential performance improvements would (alone or in tandem with RISC-V’s other benefits) justify adoption.
- nickik 8y ago
  I see your point about intensives. However I have to disagree on your opinion on the hardware. RISC-V was specifically designed to be able to do low end very well. The whole encoding for example is optimized to a tiny amount of space. The overall instruction set again is designed to use minimum amount of space as well. There is a whole project about 'ultra low power processors' at ETH Zürich [1]. They have specifically selected RISC-V because it fit their needs so well and they produce cores that beat available ARM and MIPS cores specially on energy. IBM selected a RISC-V core for their project in 'Next-Generation Edge Computing' [2]. So it seems to me that small and simple really does pay of when going to very tiny cores. [1] https://www.pulp-platform.org/ https://www.pulp-platform.org/ [2] https://content.riscv.org/wp-content/uploads/2018/05/16.10-16.25-Seiji-Munetoh-IBM-Japan.pdf https://content.riscv.org/wp-content/uploads/2018/05/16.10-1...

brandmeyer 8y ago

cough cough, static rounding modes, cough