3 ms·

They started before RISC-V existed. The reason why they build their own implementation of an CPU and not used some open Mips or Sparc is that they found that t

They started before RISC-V existed. The reason why they build their own implementation of an CPU and not used some open Mips or Sparc is that they found that those used to much BUS bandwidth for their use case. SuperH was really well designed architecture with really good instruction set density. Instruction set density is not a thing tagged on to a spec which many cores don't implement and if it is implemented you end up having a mess of mixed 32 and 16 bit instructions. SuperH is cleaner in that everything is a 16 bit instruction which helps with making decoder cheaper.

yjftsjthsd-h 6y ago
But that's an even stronger reason for j2 to have taken off and risc-v to never be created, isn't it? So what went wrong?
- monocasa 6y ago
  SH processors are very good contenders in their specific gate count niche, but have a lot of headaches for implementing higher performance cores that RISC-V was attempting to explicitly address. A lot of exposed pipeline kind of stuff. Only specified a soft fill TLB. The ISA is very constrained by being 16-bit only that gets in the way of density when compared to other more modern instruction bandwidth conscious RISCs (although it can't be stated enough how much SH inspired all of the later examples, including Thumb and RV-C). Additionally SH variants with full MMUs would have lost their patent protection after RISC-V was already released and gaining steam.
  - freemint 6y ago
    Very good summary. One example of such an head ache would be the branch delay slot. It works really well if you have the compiler perform an reorder of instructions for you so the chip can do more while waiting for memory. In a modern pipeline CPU with register renaming, out of order execution this ISA level reordering would be at best complicating the implementation. The branch delay slot makes sense where you aim to wait 1-3 cycles for memory loads but becomes a meaningless complication in the face of 10's or 100's of cycles waiting for memory seen on high clocked CPUs today.
- freemint 6y ago
  I never thought about it that way. So let me first answer your question and then expand on the underlying issue. You might say "J-Core failed" because of a lack of privilege and because of scope. J-Core just wasn't pushed by an top university and had multiple big companies invest in it. J-Core was never ment to be an industry standard covering use cases from embedded to server to super computer accelerators with an ISA designed by a comittee (i don't use designed by compute sneeringly here). J-Core was meant as a patent troll proof way for a small company to design an competitive chip for their use case on a "shoe string budget" (as far as CPU design budgets are concerned). The only reason why the wider world here about it, is because people in the company believe in open source and they didn't want anybody to have to redo this work if it fits someone's use case. RISC-V was originally created because some greedy company wanted much money for their CPU architecture to be used in the course of an professor at an prominent university. A CPU architecture is a set of trade offs. RISC-V traded compactness of the instruction set for the flexibility an 32 bit instruction set allowed and to gain back some density by having an optional compact instruction set at the cost of making the encoder slightly more complex. J-Core always has an Multiplier-Accumulator, while this optional for RISC-V. RISC-V traded suitableness for embedded use cases for agreeableness (You don't have to implement some stuff, if you don't need it), flexibility, mass appeal and i think those trade-offs worked out for what they had in mind. If the team behind J-Core took that route they wouldn't have shipped a product and had a half finished obscure standards document instead.

yjftsjthsd-h 6y ago

But that's an even stronger reason for j2 to have taken off and risc-v to never be created, isn't it? So what went wrong?

monocasa 6y ago
SH processors are very good contenders in their specific gate count niche, but have a lot of headaches for implementing higher performance cores that RISC-V was attempting to explicitly address. A lot of exposed pipeline kind of stuff. Only specified a soft fill TLB. The ISA is very constrained by being 16-bit only that gets in the way of density when compared to other more modern instruction bandwidth conscious RISCs (although it can't be stated enough how much SH inspired all of the later examples, including Thumb and RV-C). Additionally SH variants with full MMUs would have lost their patent protection after RISC-V was already released and gaining steam.
- freemint 6y ago
  Very good summary. One example of such an head ache would be the branch delay slot. It works really well if you have the compiler perform an reorder of instructions for you so the chip can do more while waiting for memory. In a modern pipeline CPU with register renaming, out of order execution this ISA level reordering would be at best complicating the implementation. The branch delay slot makes sense where you aim to wait 1-3 cycles for memory loads but becomes a meaningless complication in the face of 10's or 100's of cycles waiting for memory seen on high clocked CPUs today.
freemint 6y ago
I never thought about it that way. So let me first answer your question and then expand on the underlying issue. You might say "J-Core failed" because of a lack of privilege and because of scope. J-Core just wasn't pushed by an top university and had multiple big companies invest in it. J-Core was never ment to be an industry standard covering use cases from embedded to server to super computer accelerators with an ISA designed by a comittee (i don't use designed by compute sneeringly here). J-Core was meant as a patent troll proof way for a small company to design an competitive chip for their use case on a "shoe string budget" (as far as CPU design budgets are concerned). The only reason why the wider world here about it, is because people in the company believe in open source and they didn't want anybody to have to redo this work if it fits someone's use case. RISC-V was originally created because some greedy company wanted much money for their CPU architecture to be used in the course of an professor at an prominent university. A CPU architecture is a set of trade offs. RISC-V traded compactness of the instruction set for the flexibility an 32 bit instruction set allowed and to gain back some density by having an optional compact instruction set at the cost of making the encoder slightly more complex. J-Core always has an Multiplier-Accumulator, while this optional for RISC-V. RISC-V traded suitableness for embedded use cases for agreeableness (You don't have to implement some stuff, if you don't need it), flexibility, mass appeal and i think those trade-offs worked out for what they had in mind. If the team behind J-Core took that route they wouldn't have shipped a product and had a half finished obscure standards document instead.