4 ms·

MIPS had their chance with MIPS Open and bungled it. If they hadn't, then there wouldn't have been the same need for RISC-V. It's a shame because MIPS had a pe

MIPS had their chance with MIPS Open and bungled it. If they hadn't, then there wouldn't have been the same need for RISC-V. It's a shame because MIPS had a perfectly usable architecture with 64-bit support and a well supported toolchain. It's sad to see it abandoned because it was historically one of the first successful RISC architectures that was used in everything from the DECstation to the PlayStation.

yjftsjthsd-h 5y ago
> MIPS had their chance with MIPS Open and bungled it. If they hadn't, then there wouldn't have been the same need for RISC-V. I would, someday, like to hear a history of how we did get to RISC-V being needed. MIPS never actually made it to being open source, but I thought SPARC[0] and POWER[1] both did make it, quite a long time ago now, j-core is a thing[2] although that may have happened too late, OpenRISC[3] is apparently decades old now but just... never went anywhere? I'm probably missing context, but it seems like we should have had at least 2 and possibly as many as 5 open source processor designs by the time RISC-V took off. And now it has taken off, and the ecosystem has latched onto it and it will almost certainly come to dominate, but I still don't understand why it was needed at all or why it succeeded when everything else failed. [0] https://en.wikipedia.org/wiki/OpenSPARC https://en.wikipedia.org/wiki/OpenSPARC [1] https://en.wikipedia.org/wiki/OpenPOWER_Foundation https://en.wikipedia.org/wiki/OpenPOWER_Foundation - possibly not actually FOSS like RISC-V; unclear to me whether IBM is just using "open" to mean "we share with other companies who are working with us" [2] "J-core is a clean-room open source processor and SOC design using the SuperH instruction set, implemented in VHDL and available royalty and patent free under a BSD license." https://j-core.org/ https://j-core.org/ [3] https://en.wikipedia.org/wiki/OpenRISC https://en.wikipedia.org/wiki/OpenRISC
- chasil 5y ago
  SPARC and MIPS have some architectural oddities that were designed for their original pipelines that make them awkward. https://www.jwhitham.org//2016/02/risc-instruction-sets-i-have-known-and.html https://www.jwhitham.org//2016/02/risc-instruction-sets-i-ha... https://news.ycombinator.com/item?id=11607119 https://news.ycombinator.com/item?id=11607119
  - musicale 5y ago
    I'm not a huge fan of register windows (an original SPARC – and Berkeley RISC I – feature) but IIRC MIPS does in fact have hardware interlocks. Branch delay slots aren't a big deal. I don't see a huge technical need for RISC-V. As I understand it the main motivations were 1) it was supposed to be open/IP free 2) it was supposed to be small/modular and 3) it allowed Berkeley to do ISA research. I consider MIPS to be simple enough for grad students to implement and fairly modular as well, with the added advantage that it was relatively complete and mature at the time. It could have continued to be improved as well. The main benefits I see to RISC-V are non-technical: IP licensing and current popularity/trendiness/support in both research and industry. (As a side note: for extreme simplicity and pedagogic suitability, I rather like Niklaus Wirth's (very) similarly-named RISC5.)
    - chasil 5y ago
      The author of my linked article also really didn't care for branch delay slots, which I am assuming was a carryover from the original pipeline that is long gone from modern designs. I know that ARM removed many performance-adverse aspects in their 64-bit conversion (conditional execution, direct moves into the program counter), and I wonder how much was done for the 64-bit MIPS and SPARC instruction sets to make them more practical and less of a historical anachronism.
    - kijiki 5y ago
      > Branch delay slots aren't a big deal. Fair enough, but if the claim to fame over the current dominant ISA is that there isn't weird baggage (big deal or not), there is an opportunity for another new ISA without that baggage (important or not)...
      - chasil 5y ago
        I've often wondered if hard-coding a register R0 to zero/null is a wise use of the register file. xor r0,r0 seems a small price to pay.
        5y ago
- panick21_ 5y ago
  SPARC was a open standard but only one 32 bit version and later 64 bit updates were already available. And at that point interest in Open Source and Open Hardware simply didn't exist to the same degree. In the 'modern' period, nobody has interest in working with something Oracle controls. Power was always 'fake open' it was basically a marketing vehicle and there were not actually open chips being built with it. Only in response to RISC-V did some of that change. SuperH was under patent when RISC-V started and it was simple much less known about as well. Once it was actually going RISC-V was already happening and had far more momentum and RISC-V was 64 bit from the beginning. As with so many thing Sun could have changed the world much more fundamentally had they understood open source better. There was OpenRisc but that was really more a chip design and the ISA and it was also only 32 bit. OpenRISC was basically some students starting to implementing a design from David Patterson textbook. It was also a license that they didn't like. So really you needed a ISA that was designed for architecture independent with 32 bit and 64 bit and that was 'future prove' in terms of license, design and so on and importantly some actually working chip and softcore being available for people to tinker with. Berkley did that and they taped out many chips while designing RISC-V. Other universities jumped on board and ETH was producing and taping out cores. From that point is snowballed. One could imagine an alternative future where Super-H takes off and universities adopting and Berkley does a 62 bit Super-H or something like that.
snvzz 5y ago
No hard feelings. RISC-V is better, and this is for the best.
- musicale 5y ago
  As I see it, it's not the best outcome for the computing world; evolving MIPS and SPARC and making them open seems to me like it would have been a better outcome. MIPS is still in widespread use after all. The way I take Dave Patterson's point (ISAs should be open) is that it would be nice if ARM and x86 were open as well.

yjftsjthsd-h 5y ago

> MIPS had their chance with MIPS Open and bungled it. If they hadn't, then there wouldn't have been the same need for RISC-V. I would, someday, like to hear a history of how we did get to RISC-V being needed. MIPS never actually made it to being open source, but I thought SPARC[0] and POWER[1] both did make it, quite a long time ago now, j-core is a thing[2] although that may have happened too late, OpenRISC[3] is apparently decades old now but just... never went anywhere? I'm probably missing context, but it seems like we should have had at least 2 and possibly as many as 5 open source processor designs by the time RISC-V took off. And now it has taken off, and the ecosystem has latched onto it and it will almost certainly come to dominate, but I still don't understand why it was needed at all or why it succeeded when everything else failed. [0] https://en.wikipedia.org/wiki/OpenSPARC https://en.wikipedia.org/wiki/OpenSPARC [1] https://en.wikipedia.org/wiki/OpenPOWER_Foundation https://en.wikipedia.org/wiki/OpenPOWER_Foundation - possibly not actually FOSS like RISC-V; unclear to me whether IBM is just using "open" to mean "we share with other companies who are working with us" [2] "J-core is a clean-room open source processor and SOC design using the SuperH instruction set, implemented in VHDL and available royalty and patent free under a BSD license." https://j-core.org/ https://j-core.org/ [3] https://en.wikipedia.org/wiki/OpenRISC https://en.wikipedia.org/wiki/OpenRISC

chasil 5y ago
SPARC and MIPS have some architectural oddities that were designed for their original pipelines that make them awkward. https://www.jwhitham.org//2016/02/risc-instruction-sets-i-have-known-and.html https://www.jwhitham.org//2016/02/risc-instruction-sets-i-ha... https://news.ycombinator.com/item?id=11607119 https://news.ycombinator.com/item?id=11607119
- musicale 5y ago
  I'm not a huge fan of register windows (an original SPARC – and Berkeley RISC I – feature) but IIRC MIPS does in fact have hardware interlocks. Branch delay slots aren't a big deal. I don't see a huge technical need for RISC-V. As I understand it the main motivations were 1) it was supposed to be open/IP free 2) it was supposed to be small/modular and 3) it allowed Berkeley to do ISA research. I consider MIPS to be simple enough for grad students to implement and fairly modular as well, with the added advantage that it was relatively complete and mature at the time. It could have continued to be improved as well. The main benefits I see to RISC-V are non-technical: IP licensing and current popularity/trendiness/support in both research and industry. (As a side note: for extreme simplicity and pedagogic suitability, I rather like Niklaus Wirth's (very) similarly-named RISC5.)
  - chasil 5y ago
    The author of my linked article also really didn't care for branch delay slots, which I am assuming was a carryover from the original pipeline that is long gone from modern designs. I know that ARM removed many performance-adverse aspects in their 64-bit conversion (conditional execution, direct moves into the program counter), and I wonder how much was done for the 64-bit MIPS and SPARC instruction sets to make them more practical and less of a historical anachronism.
  - kijiki 5y ago
    > Branch delay slots aren't a big deal. Fair enough, but if the claim to fame over the current dominant ISA is that there isn't weird baggage (big deal or not), there is an opportunity for another new ISA without that baggage (important or not)...
    - chasil 5y ago
      I've often wondered if hard-coding a register R0 to zero/null is a wise use of the register file. xor r0,r0 seems a small price to pay.
      - 5y ago
panick21_ 5y ago
SPARC was a open standard but only one 32 bit version and later 64 bit updates were already available. And at that point interest in Open Source and Open Hardware simply didn't exist to the same degree. In the 'modern' period, nobody has interest in working with something Oracle controls. Power was always 'fake open' it was basically a marketing vehicle and there were not actually open chips being built with it. Only in response to RISC-V did some of that change. SuperH was under patent when RISC-V started and it was simple much less known about as well. Once it was actually going RISC-V was already happening and had far more momentum and RISC-V was 64 bit from the beginning. As with so many thing Sun could have changed the world much more fundamentally had they understood open source better. There was OpenRisc but that was really more a chip design and the ISA and it was also only 32 bit. OpenRISC was basically some students starting to implementing a design from David Patterson textbook. It was also a license that they didn't like. So really you needed a ISA that was designed for architecture independent with 32 bit and 64 bit and that was 'future prove' in terms of license, design and so on and importantly some actually working chip and softcore being available for people to tinker with. Berkley did that and they taped out many chips while designing RISC-V. Other universities jumped on board and ETH was producing and taping out cores. From that point is snowballed. One could imagine an alternative future where Super-H takes off and universities adopting and Berkley does a 62 bit Super-H or something like that.

snvzz 5y ago

No hard feelings. RISC-V is better, and this is for the best.

musicale 5y ago
As I see it, it's not the best outcome for the computing world; evolving MIPS and SPARC and making them open seems to me like it would have been a better outcome. MIPS is still in widespread use after all. The way I take Dave Patterson's point (ISAs should be open) is that it would be nice if ARM and x86 were open as well.