5 ms·

> RISC-V is amenable to a wide array of microarchitectural decisions As is ARMv8. Applied Micro, Broadcom, Cavium, Huawei, Nvidia, AMD, Samsung and Apple are a

> RISC-V is amenable to a wide array of microarchitectural decisions As is ARMv8. Applied Micro, Broadcom, Cavium, Huawei, Nvidia, AMD, Samsung and Apple are all architectural licensees with radically different microarchitectural implementations. For example, Nvidia is Transmeta code-morphing style implementation. Also, Intel and AMD continue to innovate in the x86 space. At this date, RISC-V has no fundamental advantage over any of these architectures and then has the fundamental disadvantage of not having access to their IP. You're lining up against Usain Bolt and your advantage is that you're wearing organic cotton. That's just not gonna work.

analognoise 10y ago
" You're lining up against Usain Bolt and your advantage is that you're wearing organic cotton. That's just not gonna work." I'm stealing this as a saying.
yaantc 10y ago
You're right, but key words here are "At this date". What you said could have been said exactly in the same way about Linux against commercial Unices about 15 years ago. It's a long game here, and we're only in the early phase. And it may not take that long, but we'll see. Regarding technology, just as Linux initially the key is not having a technological advantage, but being cheaper and good enough. The improvements can come later, when the ecosystem gets bigger and more resources pours in.
- sweden 10y ago
  RISC-V is thrown around like if it's an already working CPU but it is not. It is just a document describing an ISA, you can't compare it to Linux, it's a completely different thing. There are a lot of costs in implementing an ISA and that includes: design, functional verification, physical implementation and software testing. All those steps together will require hundreds and hundreds of engineers, many expensive tools and thousands of man-hours. And once you are done, you will need to find be careful not to violate any patents while shipping your CPU to the end customer. By paying a license fee to ARM, you get all these steps done for you plus with support. Linux is something that you can download from kernel.org, compile overnight and get it booting right away. RISC-V is something that you need to build yourself.
  - rwmj 10y ago
    When I did a presentation on RISC-V last year I counted 6 real implementations (full custom ASICs). Now granted only one or two of those you can buy, the others are research projects, but they do exist and they did produce real silicon. This year we should see a couple of 64 bit implementations, which is when it'll get really interesting. There are of course multiple FPGA implementations (I have one about 2 feet away from me now), but they are very slow.
    - eggsome 10y ago
      Is your presentation online?
      - rwmj 10y ago
        No it was a private talk about company strategy.
    - sweden 10y ago
      I am aware that they exist but it's not like companies are going to actively invest in devices for the end consumer purely based on RISC-V.
      - sangnoir 10y ago
        From where I'm standing, it looks like you're shifting goalposts: > > RISC-V is thrown around like if it's an already working CPU but it is not (Evidence of existing CPUs provided) > I am aware that they exist but it's not like companies are going to actively invest in devices for the end consumer purely based on RISC-V.
        sweden 10y ago
        My point is, you can't get those existing CPUs for free.
        10y ago
microcolonel 10y ago
NVIDIA's Denver is a feat; I think that if it says anything, it's that ARM's instruction encoding is deficient. AArch64 instruction encoding is less dense than AMD64, and completely lacks compressed instructions (like Thumb). To NVIDIA, it made more sense for them to write a realtime binary translator for an internal ISA which is clearly enabling their microarchitecture more than ARM is. AMD and Intel spend more money on research than you can even imagine, and it's not surprising that they manage to make x86 machines that lead in single-thread performance, but since Intel tried Itanium, you can tell their designers feel x86 is deficient. I mean, just imagine how much of their chips is just decode. Also, not to get too childish, but ironically NVIDIA is one of the vendors who is shipping RISC-V in a lot of products. Soon enough, that Denver-style core is going to be sitting on a die right next to a RISC-V. ;- )
- CalChris 10y ago
  That's a good point about Nvidia adopting RISC-V. I didn't know that but for their application it's a good idea. I'm not a Denver fan and at this point I think we can safely say Code Morphing has been tried. However, I wouldn't conclude that Denver means that ARM's instruction encoding is deficient. The optimizations that Denver provides would be impractical in any ISA. Moreover architectures are meant to be implemented+optimized in many ways. You may not like x86 but planting that flag in the sand allowed Intel to innovate on the microarchitecture side while developers innovated on the application side knowing that x86 would still be there. It's the same value proposition that IBM offered with the original architecture, System 360. Where I like x86 and where I don't like RISC-V is that x86 doesn't try to be perfect but rather to adapt over time. RISC-V tries to be perfect and indeed eschews many of the bad RISC ideas from the past (register windows, branch delay slots, tagged integers, ...) while then pig headedly avoiding an obvious feature shared by both x86 and ARM, condition codes. I've read their argument and found it unconvincing. Original ARM had way too much condition code support. I think ARMv8 strikes a nice balance that RISC-V should have followed. The HP+Intel Itanium effort allowed AMD to propose their AMD64 extensions. That's been quite successful. I wish they'd taken the opportunity to trim more cruft. When ARM went 64b with ARMv8, they took that opportunity and the result is quite clean. I prefer it to RISC-V although I haven't written any RISC-V assembly. ARMv8 tries to be a good instruction set architecture. To me, RISC-V tries to be the platonic ideal RISC ISA. I'll go with good.
type0 10y ago
> and your advantage is that you're wearing organic cotton. Open source hardware is not like organic cotton, it's more like having the kitchen, the tools and the ingredients to cook your own awesome meal vs going to a restaurant but never able to make any food yourself.

analognoise 10y ago

" You're lining up against Usain Bolt and your advantage is that you're wearing organic cotton. That's just not gonna work." I'm stealing this as a saying.

yaantc 10y ago

You're right, but key words here are "At this date". What you said could have been said exactly in the same way about Linux against commercial Unices about 15 years ago. It's a long game here, and we're only in the early phase. And it may not take that long, but we'll see. Regarding technology, just as Linux initially the key is not having a technological advantage, but being cheaper and good enough. The improvements can come later, when the ecosystem gets bigger and more resources pours in.

sweden 10y ago
RISC-V is thrown around like if it's an already working CPU but it is not. It is just a document describing an ISA, you can't compare it to Linux, it's a completely different thing. There are a lot of costs in implementing an ISA and that includes: design, functional verification, physical implementation and software testing. All those steps together will require hundreds and hundreds of engineers, many expensive tools and thousands of man-hours. And once you are done, you will need to find be careful not to violate any patents while shipping your CPU to the end customer. By paying a license fee to ARM, you get all these steps done for you plus with support. Linux is something that you can download from kernel.org, compile overnight and get it booting right away. RISC-V is something that you need to build yourself.
- rwmj 10y ago
  When I did a presentation on RISC-V last year I counted 6 real implementations (full custom ASICs). Now granted only one or two of those you can buy, the others are research projects, but they do exist and they did produce real silicon. This year we should see a couple of 64 bit implementations, which is when it'll get really interesting. There are of course multiple FPGA implementations (I have one about 2 feet away from me now), but they are very slow.
  - eggsome 10y ago
    Is your presentation online?
    - rwmj 10y ago
      No it was a private talk about company strategy.
  - sweden 10y ago
    I am aware that they exist but it's not like companies are going to actively invest in devices for the end consumer purely based on RISC-V.
    - sangnoir 10y ago
      From where I'm standing, it looks like you're shifting goalposts: > > RISC-V is thrown around like if it's an already working CPU but it is not (Evidence of existing CPUs provided) > I am aware that they exist but it's not like companies are going to actively invest in devices for the end consumer purely based on RISC-V.
      - sweden 10y ago
        My point is, you can't get those existing CPUs for free.
        10y ago

microcolonel 10y ago

NVIDIA's Denver is a feat; I think that if it says anything, it's that ARM's instruction encoding is deficient. AArch64 instruction encoding is less dense than AMD64, and completely lacks compressed instructions (like Thumb). To NVIDIA, it made more sense for them to write a realtime binary translator for an internal ISA which is clearly enabling their microarchitecture more than ARM is. AMD and Intel spend more money on research than you can even imagine, and it's not surprising that they manage to make x86 machines that lead in single-thread performance, but since Intel tried Itanium, you can tell their designers feel x86 is deficient. I mean, just imagine how much of their chips is just decode. Also, not to get too childish, but ironically NVIDIA is one of the vendors who is shipping RISC-V in a lot of products. Soon enough, that Denver-style core is going to be sitting on a die right next to a RISC-V. ;- )

CalChris 10y ago
That's a good point about Nvidia adopting RISC-V. I didn't know that but for their application it's a good idea. I'm not a Denver fan and at this point I think we can safely say Code Morphing has been tried. However, I wouldn't conclude that Denver means that ARM's instruction encoding is deficient. The optimizations that Denver provides would be impractical in any ISA. Moreover architectures are meant to be implemented+optimized in many ways. You may not like x86 but planting that flag in the sand allowed Intel to innovate on the microarchitecture side while developers innovated on the application side knowing that x86 would still be there. It's the same value proposition that IBM offered with the original architecture, System 360. Where I like x86 and where I don't like RISC-V is that x86 doesn't try to be perfect but rather to adapt over time. RISC-V tries to be perfect and indeed eschews many of the bad RISC ideas from the past (register windows, branch delay slots, tagged integers, ...) while then pig headedly avoiding an obvious feature shared by both x86 and ARM, condition codes. I've read their argument and found it unconvincing. Original ARM had way too much condition code support. I think ARMv8 strikes a nice balance that RISC-V should have followed. The HP+Intel Itanium effort allowed AMD to propose their AMD64 extensions. That's been quite successful. I wish they'd taken the opportunity to trim more cruft. When ARM went 64b with ARMv8, they took that opportunity and the result is quite clean. I prefer it to RISC-V although I haven't written any RISC-V assembly. ARMv8 tries to be a good instruction set architecture. To me, RISC-V tries to be the platonic ideal RISC ISA. I'll go with good.

type0 10y ago

> and your advantage is that you're wearing organic cotton. Open source hardware is not like organic cotton, it's more like having the kitchen, the tools and the ingredients to cook your own awesome meal vs going to a restaurant but never able to make any food yourself.