So much for RISC-V then.
I'm not sure that's true though..
I can bet $100 on it being wrong. Especially the ARMv8 ( and v9 )
With the way Apple operates, we have ten years before we can reasonably assume that they would change their architecture. Is RISC-V really going to be worth all the headaches of a transition in ten years?
"The company was founded in November 1990 as Advanced RISC Machines Ltd and structured as a joint venture between Acorn Computers, Apple Computer (now Apple Inc.) and VLSI Technology."
https://en.wikipedia.org/wiki/Arm_Ltd.#Founding
More details about ARM licensing:
"Finally at the top of the pyramid is an ARM architecture license. Marvell, Apple and Qualcomm are some examples of the 15 companies that have this license."
https://www.anandtech.com/show/7112/the-arm-diaries-part-1-h...
Long story short, it's probably not terribly utilitarian to have strong opinions about the subject when participating in an international forum such as this one.
It's good news for open source hardware development. But bad news for USA and for people with security concerns. I don't know how comfortable I'd be with a Chinese designed CPU, Chinese compilers, and a Chinese kernel ... even if they were all open source.
The US Empire is corrupt, but its processes of decision making and power are relatively transparent (open elections, senate trials, etc.). The Chinese system is entirely opaque. In a sense, all citizens in China are ultimately completely vulnerable to the whims of the state ... there is no recourse for arbitrary detention, seizure of property, etc. This is a model China seeks to export in the long run ... either directly, or through affiliates.
America sucks ... but as people often say about Democracy, its the worst system of governance except all the rest.
I’ve studied Chinese politics and have reached the opposite conclusion to you.
Abu Ghraib wasn’t made public through courts at all.
How many other such places exist and still kept secret for now? The past would suggest there are at least several.
If you lived in America, you would see the huge amount of protests on the streets against the Iraq war and other international adventures. Also, US politicians with significant power regularly speak out against such adventures.
This is America's internal control mechanisms. There are no such mechanisms in China.
Anyway, there's no point discussing this further. Either you understand this level of nuance, your you inherently believe in the notion that "all countries are equally bad" type philosophy with no regard to how information is brought to light and how a country is constrained.
Guantanamo bay is still open, despite what happens there being illegal under Cuban, US and international law. Julian Assange and Chelsea Manning are still persecuted.
You either understand that your country is oppressing the entire world or you blindly believe everything your ruling class tells you.
However, RISC-V is so minimal that it might be possible to add it as a second ISA to a chip without much effort. On the other hand, it's so minimal that a JIT translator from RISC-V to the native ISA can be a valid alternative (see for instance https://carrv.github.io/2017/papers/clark-rv8-carrv2017.pdf).
Of course, it helps if the ISAs are at least broadly similar in terms of register space and available operations and memory ordering specifications. And the performance is in the details.
Generally, for RISC-V, look to China it seems?
I don't agree with that. The base ISA is highly optimised for high performance. Many of the decisions made are precisely because it makes it easier to design very wide superscalar CPUs. The vector extension is also looking like it'll be more efficient than ARMs.
What's missing, is instruction set extensions that makes it comparable to ARM/x86 across all workloads. And obviously it's far less mature in general.
RISC-V has been optimized for a single-purpose, being as simple as possible to be easily taught to students and implemented by them in a limited time.
It lacks many features required for high performance without hardware of excessive complexity, the most obvious being that RISC-V does not have decent addressing modes, so that the highest performance implementation reported until now (by Alibaba at the 2020 Hot Chips Conference) had to add a non-standard ISA extension to correct this.
Nobody remotely competent chooses RISC-V for "high performance" in any definition of that term.
RISC-V can be the right choice in many cases because:
1. No costs for using the RISC-V ISA
2. Easy customization with non-standard extensions
3. An already existing complete software development environment, with compilers, debuggers etc.
4. Acceptable performance at a given implementation cost
There is no need to invent extra fictitious advantages, like "high performance".
Do you have any proof that additional addressing modes would increase performance? What I remember from college and papers I've read is that more modes are generally a detriment to pipelining.
Maybe you're talking about "needing more instructions". You'd be wrong in this case. Using the compact instruction set gives an average of 15% more dense code compared to x86 and somewhere around 25-35% more dense compared to aarch64 (about equivalent density to thumb, but without the switching overhead that makes thumb slow).
"Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension"
From "VIII. NON-STANDARD INSTRUCTION SET EXTENSION"
Targeting at various industrial applications, XT-910 enables a set of custom non-standard instructions, additional to the standard RISC-V instructions. The non-standard instruction extension can be categorized into two groups based on the purposes - memory access enhancement, and basic arithmetic operation enhancement.
A. Memory access enhancement
Memory access instructions usually account for a high proportion in the total number of instructions, so enhancing memory access instructions can directly benefit the overall performance. By analyzing the mainstream applications running on RISC-V, we observed that for the basic RISC-V instructions there is still quite some room for improvement in memory access related instructions.
First, we support register + register addressing mode, and support indexed load and store instructions. This type of instruction extension reduces the usage of the registers for calculation and reduces the number of instructions for address generation, thereby effectively accelerating the data access of a loop body. Second, unsigned extension during address generation is supported. Otherwise, the basic instruction set does not support direct unsigned extension from 32-bit data to 64-bit data, resulting in too many shift instructions.
I'm not certain if they break out the results by individual optimization, but in Fig. 20 in the paper it looks like all their tweaks add up to a 20% boost over the standard RISC-V ISA. Pretty huge.
>I'm not certain if they break out the results by individual optimization
They don't, so it's not clear where the 20% comes from. They're using a compiler that optimizes for their microarchitecture, which might account for a lot of that. As for the mention of "extensions", it's not even clear to me whether they mean official RISC-V extensions such as IMAFD or custom extensions.
It is actually a replacement for MIPS in a more literal sense: The company owning MIPS has recently renamed itself to MIPS, and it abandoned MIPS ISA in favor of RISC-V ISA.
As a practical counterexample to that FUD, it is also the ISA chosen by the Barcelona Super-computing Center EuroHPC[1] to design a new high performance CPU for future supercomputers.
[0]https://riscv.org/technical/specifications/
[1]https://www.bsc.es/news/bsc-news/bsc-working-towards-the-fir...
I know virtually nothing about the internals, but that‘s also what people said about ARM.
> If X86 still competes I see no reason why RISC-V can't also
First RISC-V needs to catch up with the 40 years of x86 improvements that kicked out SPARC, Cray, SGI and others from high-end performace systems.
I'd suspect an ISA designed in the last few years with performance in mind (even if not a priority), wouldn't take as long to get to where the industry is now, but it's still a lot of years of focused effort required, and we'll see.
I don't have a horse in the race, except that I do like my experience to not evaporate; and I sincerly hope real mode segmented address edge cases aren't something I'd need to relearn on another ISA even though they're still (barely) relevant on x86 in early boot.
Saying X86 is 40 years work is also kind of stupid, as a huge amount of the ISA dead weight, and high performance implementations have their roots much earlier than that (e.g. Intel have tried to move on at least once and ended up coming back to the OOO superscalar paradigm).
1. Already ported.
2. Not dependent on modern performance, and thus well served by emulation.
Just shows the power of an establed ISA (all the software that runs on top of it) and how solid ARM's business model is.
The ISA is an interface, and as such may not be copyrightable or even patentable. Even if it was, we've had various interoperability exceptions, and one does need an ARM ISA to run a program compiled for ARM.
Besides, as far as I know ARM doesn't just license the ISA. It licenses cores. There's a good chance that if you make your own cores to implement an ARM ISA, you wouldn't have to pay any fee. You may however have to get around trademark, and not call your CPUs "ARM CPUs". Though I suspect "ARM compatible" would work perfectly (just like "IBM compatible" worked with third party PC vendors).
The terms are secret, but basically yes, AMD had access to 386? designs and what not as part of IBMs second source requirements with Intel, but Amd486 and up designs were AMD original with instruction sets under license from Intel, although the licenses were set up after release under litigation.
> Does Intel pay AMD a fee for using their 64 bit extensions?
Yes / sort of. Use of the AMD64 extentions was negotiated under the broad cross licensing between the two companies.
> Does anybody pay the inventor of the SSE and AVX instruction sets?
Do the persons involved get royalties? I'd guess not, but who knows. Would you have to pay more to get a license for them, almost certainly.
You'll note there's been a lot fewer x86 processor designs not from the big two over the past many years than there were in the late 90s. Some of that is because 'RISC is going to change everything', but a lot of it is becsause nobody can get an x86 license.
> Does anybody pays Nintendo for deploying emulators?
I don't think so. Patents are too old, and there's not a whole lot of non-Nintendo emulation in the commercial market (but I know Capcom has released some collections, of Megaman games, etc). If those types of releases started including systems with system roms, then you would start having copyright claims.
Nintendo has never seriously impeded system emulation; there's just no case to be made. ROM distribution is clear copyright violation though, of course.
[0] https://riscv.org/technical/specifications/
(start with chapter 1 of the unprivileged spec)