5 ms·

> RISC-V seems like it hasn’t learned anything from CPUs designed after 1991. Never mind what RISC-V says about itself. Here is Dave Jaggar, a key ARM architec

> RISC-V seems like it hasn’t learned anything from CPUs designed after 1991. Never mind what RISC-V says about itself. Here is Dave Jaggar, a key ARM architect, endorsing RISC-V as state of the art in 2019: https://youtu.be/_6sh097Dk5k?t=51m10s https://youtu.be/_6sh097Dk5k?t=51m10s.

detritus 6y ago
Thank you for this, and more specifically for adding the relevant timestamp - and more personally - for Jaggar's answer to the subsequent question regarding complexity in hardware and software stacks, which as a layperson is something I often think about. I'd love to see the result of a concerted ground-up creation of a hardware and software system that starts from scratch and leaves unresolvable legacy considerations to virtual machines or whatever. Anyway, totally Off Topic, but thanks for what I'm assuming will be my watching that entire video!
- cat199 6y ago
  > I'd love to see the result of a concerted ground-up creation of a hardware and software system that starts from scratch and leaves unresolvable legacy considerations to virtual machines or whatever. https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
- Symmetry 6y ago
  Have you seen the Mill videos? Seems to have stalled out but it represents a lot of rethinking of assumptions. https://millcomputing.com/docs/ https://millcomputing.com/docs/
  - alien_ 6y ago
    I'm not a specialist in CPU design but to me RISC-V seems like an incremental evolution, nothing really ground-breaking, when compared to alternatives the main benefit is the openness/licensing/cost. But at the same time think that you can get a $5 raspberry pi and embedded ARM chips cost pennies. The entire effort of supporting it and building the ecosystem will be hard to justify economically at these cost figures. Mill on the other hand has a lot of interesting ground-breaking ideas that can potentially offer a 10x performance/watt improvement. Many people have been recently in awe after experiencing the ARM performance improvements around 40% offered by the Apple silicon and AWS Graviton CPUs. Just imagine something offering a 10x based on a Mill design, I'd love to see it built one day and available on the market.
    - Symmetry 6y ago
      Oh, also this one is maybe a midpoint between the two in interestingness. https://www.forwardcom.info/ https://www.forwardcom.info/
    - vlovich123 6y ago
      40% on existing software & even better performance when emulating old software. Mill is extremely alien with no indication they're able to get any of the same gains. Regardless of their brilliance, they seem to not know how to run an engineering business & their choices show that (our new CPU needs a completely new compiler vs adding a new backend, our new CPU needs a new OS, etc). Their efforts are basically "boil the ocean" levels of engineering without any sales to justify that they're on a path to success.
- dnautics 6y ago
  > I'd love to see the result of a concerted ground-up creation of a hardware and software system that starts from scratch and leaves unresolvable legacy considerations to virtual machines or whatever. This has been tried often. (Thinking Machines, Multiflow, e.g., not to mention Itanium) I would love to see this too; I worked for a startup that tried to do this (vliw, no specex), and taped out with a working chip, after 6 months. Maybe the startup didn't have the right sales team, but they didn't manage to make any meaningful sales, the culture in the buyer's market is too conservative. In the case of the company I worked for I suspect that part of the problem is that conservative buyers will look for excuses to say no, instead of excuses to say yes. One such example is that nobody would accept that you could move specex to the compiler, with the old "sufficiently advanced compiler" joke, despite the fact that they could prove that llvm was "advanced enough".
  - rwallace 6y ago
    They solved the problem of unpredictable load times at compile time? Using just LLVM? How?
    - dnautics 6y ago
      No they used delayed conditionals instead of specex. Common tactict for dsp
      - dnautics 6y ago
        *common tactic for dsp processors, generally unused for gp-cpu designs, because "it's hard to compile with optimization"
innagadadavida 6y ago
Sounds like there will be more fragmentation just like why we have with software and frameworks.
- alpaca128 6y ago
  Which could be a good thing if it causes developers to write more portable code. Or a web-like chaos where you have to add little hacks for every other platform.
amelius 6y ago
Not really. He answered a question about learning about CPU design, and he said that RISC-V is a good thing to look at. Yes, he said "state of the art" but it was in the context of learning about CPU design, so I think the meaning here is not as strong.
- heimatau 6y ago
  > so I think the meaning here is not as strong Your post in interesting. I agree yet disagree. You got the context correct but he explicitly said 'it's the standard now for 32 bit general purpose instruction sets and it's got the 16 bit compressed stuff. Learning from the best still'. Standard =/ state of the art but in this context, he's stating that learning from the best (state of the art CPU designs) is by learning RISC-V. One doesn't say something is a standard and state of the art in one breathe, to somehow believe that they're doing something outdated or from 1991's knowledge base. I think you're interpretation of his message would need to have further explicit statements from him to support your claim (that somehow 'state of the art' doesn't mean for CPU design, instead of just learning CPU design). The listener would be better suited to follow @seedless-sensat's (and my) understanding because there is no evidence to the contrary of what we're stating. The speaker intended both (but if you can find evidence to support your different thesis, I look forward to investigating it further).
HeckFeck 6y ago
I've got the MOVs like Jaggar... Sorry, couldn't resist a well-assembled pun.
- timthorn 6y ago
  By Maroon-V?

detritus 6y ago

Thank you for this, and more specifically for adding the relevant timestamp - and more personally - for Jaggar's answer to the subsequent question regarding complexity in hardware and software stacks, which as a layperson is something I often think about. I'd love to see the result of a concerted ground-up creation of a hardware and software system that starts from scratch and leaves unresolvable legacy considerations to virtual machines or whatever. Anyway, totally Off Topic, but thanks for what I'm assuming will be my watching that entire video!

cat199 6y ago
> I'd love to see the result of a concerted ground-up creation of a hardware and software system that starts from scratch and leaves unresolvable legacy considerations to virtual machines or whatever. https://en.wikipedia.org/wiki/Lisp_machine https://en.wikipedia.org/wiki/Lisp_machine
Symmetry 6y ago
Have you seen the Mill videos? Seems to have stalled out but it represents a lot of rethinking of assumptions. https://millcomputing.com/docs/ https://millcomputing.com/docs/
- alien_ 6y ago
  I'm not a specialist in CPU design but to me RISC-V seems like an incremental evolution, nothing really ground-breaking, when compared to alternatives the main benefit is the openness/licensing/cost. But at the same time think that you can get a $5 raspberry pi and embedded ARM chips cost pennies. The entire effort of supporting it and building the ecosystem will be hard to justify economically at these cost figures. Mill on the other hand has a lot of interesting ground-breaking ideas that can potentially offer a 10x performance/watt improvement. Many people have been recently in awe after experiencing the ARM performance improvements around 40% offered by the Apple silicon and AWS Graviton CPUs. Just imagine something offering a 10x based on a Mill design, I'd love to see it built one day and available on the market.
  - Symmetry 6y ago
    Oh, also this one is maybe a midpoint between the two in interestingness. https://www.forwardcom.info/ https://www.forwardcom.info/
  - vlovich123 6y ago
    40% on existing software & even better performance when emulating old software. Mill is extremely alien with no indication they're able to get any of the same gains. Regardless of their brilliance, they seem to not know how to run an engineering business & their choices show that (our new CPU needs a completely new compiler vs adding a new backend, our new CPU needs a new OS, etc). Their efforts are basically "boil the ocean" levels of engineering without any sales to justify that they're on a path to success.
dnautics 6y ago
> I'd love to see the result of a concerted ground-up creation of a hardware and software system that starts from scratch and leaves unresolvable legacy considerations to virtual machines or whatever. This has been tried often. (Thinking Machines, Multiflow, e.g., not to mention Itanium) I would love to see this too; I worked for a startup that tried to do this (vliw, no specex), and taped out with a working chip, after 6 months. Maybe the startup didn't have the right sales team, but they didn't manage to make any meaningful sales, the culture in the buyer's market is too conservative. In the case of the company I worked for I suspect that part of the problem is that conservative buyers will look for excuses to say no, instead of excuses to say yes. One such example is that nobody would accept that you could move specex to the compiler, with the old "sufficiently advanced compiler" joke, despite the fact that they could prove that llvm was "advanced enough".
- rwallace 6y ago
  They solved the problem of unpredictable load times at compile time? Using just LLVM? How?
  - dnautics 6y ago
    No they used delayed conditionals instead of specex. Common tactict for dsp
    - dnautics 6y ago
      *common tactic for dsp processors, generally unused for gp-cpu designs, because "it's hard to compile with optimization"

innagadadavida 6y ago

Sounds like there will be more fragmentation just like why we have with software and frameworks.

alpaca128 6y ago
Which could be a good thing if it causes developers to write more portable code. Or a web-like chaos where you have to add little hacks for every other platform.

amelius 6y ago

Not really. He answered a question about learning about CPU design, and he said that RISC-V is a good thing to look at. Yes, he said "state of the art" but it was in the context of learning about CPU design, so I think the meaning here is not as strong.

heimatau 6y ago
> so I think the meaning here is not as strong Your post in interesting. I agree yet disagree. You got the context correct but he explicitly said 'it's the standard now for 32 bit general purpose instruction sets and it's got the 16 bit compressed stuff. Learning from the best still'. Standard =/ state of the art but in this context, he's stating that learning from the best (state of the art CPU designs) is by learning RISC-V. One doesn't say something is a standard and state of the art in one breathe, to somehow believe that they're doing something outdated or from 1991's knowledge base. I think you're interpretation of his message would need to have further explicit statements from him to support your claim (that somehow 'state of the art' doesn't mean for CPU design, instead of just learning CPU design). The listener would be better suited to follow @seedless-sensat's (and my) understanding because there is no evidence to the contrary of what we're stating. The speaker intended both (but if you can find evidence to support your different thesis, I look forward to investigating it further).

HeckFeck 6y ago

I've got the MOVs like Jaggar... Sorry, couldn't resist a well-assembled pun.

timthorn 6y ago
By Maroon-V?