SiFive U8-Series To Offer Much Greater RISC-V Performance

[blargh4]

Hypothetically if Intel wanted to port their Ice Lake microarchitecture to the RISC-V instruction set, could they do it? Would it be feasible to port an microarchitecture from one instruction set architecture to another?

Well, the execution unit is pretty loosely coupled to the ISA, so I'm sure a lot of the design could be reused, but the front end would have to change enough that you could hardly call it the same microarchitecture... but why on earth would Intel want to break compatibility with one of the most commercially important (I'd say the most important, but I suppose ARM64 is nothing to sneeze at these days either) and deeply entrenched ISAs on the market?

[9Strike]

In my dreams they would collaborate with the Raspberry foundation to make a Raspberry Pi Model C, mass producted so it's less then hundret bucks (but Model B prices are just too unrealistic).

[blargh4]

Downplaying this performance sounds to me, like the people downplaying tesla in the early years.

Sorry, but what is so interesting about it? It's a Cortex-A72 class design performance-wise - neat, but nothing astonishing (and no SIMD, yet). It's (AFAIK) a proprietary design, so it's not interesting as a contribution to the world of FOSS hardware. The major CPU core vendors are already miles ahead of it.

[uid313]

Well, the execution unit is pretty loosely coupled to the ISA, so I'm sure a lot of the design could be reused, but the front end would have to change enough that you could hardly call it the same microarchitecture... but why on earth would Intel want to break compatibility with one of the most commercially important (I'd say the most important, but I suppose ARM64 is nothing to sneeze at these days either) and deeply entrenched ISAs on the market?

They wouldn't which is why I posed the question as a hypothetical question. It is interesting as a fantasy, like what if Intel decided to continue with their x86 architecture, but port their Ice Lake architecture over and RISC-V, I wouldn't know how much effort that would take, but it would be interesting if they did, and offered it on the side.
I don't know how long they can keep up with the x86 architecture, because it is starting to look less appealing next to ARMv8 which has processors with really good IPC. Apple could be ditching x86 and go for ARM on their MacBooks. Microsoft is eyeing ARM on their Surface, and so is Samsung.
Intel lost in their effort to establish themselves on the smartphone and tablets. I am not sure how well they are going in the IoT sphere. Next, they're about to lose it on the laptop side?
Then the only thing they have left is PC gaming, non-Apple workstations, and the cloud. In the cloud everything is virtualized and much run on a virtual machine like CLR or JVM, so they're not all that safe there either.

[zxy_thf]

Either
a) you didn't read the SiFive's announcement,
b) you read it carelessly, or
c) you didn't understand it.

or
d) you're a salesman paid by SiFive and totally ignoring the fact they are not making a fair comparison.
Their announcement has no more details beyond your post.

[abott]

Someone needs to open source some pipeline hardware design docs and have the community implement them in the open together. Having everyone implement this ISA is basically ignoring the reason you've had success in the first place.

Focus on one high performance part that is better than anything else anyone else will slap together.

[Cape]

Meh... I'm not interested in RISC-V any longer ¯\_(ツ)_/¯

It seems to be just a bunch of buzzwords put together. In the end: there is no real world CPU, there is no more freedom and there is no software support.

Also I've heard that the architecture is very flawed compared to others

[pkese]

Meh... I'm not interested in RISC-V any longer ¯\_(ツ)_/¯

It seems to be just a bunch of buzzwords put together. In the end: there is no real world CPU, there is no more freedom and there is no software support.

Can any company make and sell an ARM CPU without paying hefty royalties to ARM?
Can any company besides Intel and AMD even make X86 CPUs?

Also I've heard that the architecture is very flawed compared to others

This is highly interesting:
how is RISC-V architecture flawed compared to others when all that RISC-V is is an instruction set?

[cipri]

Sorry, but what is so interesting about it? It's a Cortex-A72 class design performance-wise - neat, but nothing astonishing (and no SIMD, yet). It's (AFAIK) a proprietary design, so it's not interesting as a contribution to the world of FOSS hardware. The major CPU core vendors are already miles ahead of it.

They are now having a design that can be used for the needs of most people/developers. There is a chance that we have real hardware that can be also useful. Once real and performance hardware is available, risc-v adoptionperformant and development will accelerate even more. It is an important sign to show: look, risc-v can be performant, saver than the competition, power efficient. This is an important step in the master plan. Once you have real hardware for testing and developing, its development will accelerate and trusting in the risc-v future. It is is power-efficient, and has enough performance, and a stable port to linux, it is become nearly instantly a great choice for a server.
I have bought already risc-v microcontrollers, and they are have great performance/price ratio. Maybe later in time, sifive, or others, will release a complete open source royalty free cpu. With risc-v it's possible, with arm not, even if they producer (let's say apple) wanted to donate it to the world.
And secondly, to me, any 7x improvement is very impressive.
I would love to see a risc-v smartphone or laptop by huawei!

[pkese]

or
d) you're a salesman paid by SiFive and totally ignoring the fact they are not making a fair comparison.
Their announcement has no more details beyond your post.

There's a footnote quoting "using iso-process & iso-frequency methodology" - but I may have read it carelessly myself, because there were two footnotes and unlike ARM's one, this one was when comparing to their own U7. Their methodology for ARM was not explicitly revealed, so you may be right, or you may be not.

Regarding me being the salesman - I'll leave the guessing to you.

The reason I get excited about RISC-V is that all other instruction sets were designed in the era when numbers of transistors per chip was counted in thousands and the intent of instruction sets was to improve performance relative to that era technology (X86 was in the 'microcoded' era, ARM was in 'single issue pipeline and no cache' era).

In the meanwhile technology had advanced, we re counting transistors in millions and billions, there's superscalar pipelines, out-of-order speculative execution, register renaming and other stuff in modern CPUs. For 90% of the ISA this doesn't matter a lot, but in edge cases, there's a lot of extra cruft in the implementation of a CPU there simply due to needing emulate quirks of archaic ISAs. And these are often things that are hindering the whole architecture of the CPU (think of ARM32 conditional instructions - maybe a good idea for 1985 to save a few transistors, but definitely a great pain for implementations in 2019; yes they have dropped them in ARM64 ISA, but all modern CPUs still implement them for backward compatibility reasons).

RISC-V was designed to match state of the art HW of 2010s rather than 1970-1980ies. This is why they don't need extra pipeline stages for decoding X86 instructions into internal core uOPs (and consequenially they have shorter pipeline stalls at branch mispredictions). They don't need uOP caches. Instruction fusing is simpler etc.

RISC-V processors have been shown to match performance levels of other ISA CPUs with RISC-V having considerably less transistors (and consuming less power). A lot of that is due to not having to deal with backward compatibility (X86-32, ARM-32 are both extremely complex and most 64-bit CPUs still implement them), but a large part is simply that a modern ISA is easier to implement efficiently.