But still using ARM ISA?
Personal take: it would be the end of them if they weren't.
I'm not sure that's true though..
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...
I can bet $100 on it being wrong. Especially the ARMv8 ( and v9 )
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.
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.
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".
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.
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.
[0] https://riscv.org/technical/specifications/
(start with chapter 1 of the unprivileged spec)
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...
Generally, for RISC-V, look to China it seems?
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.
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.
And using a custom uarch is also a statement to your customers, shareholders, competitors etc. that you mean business rather than just going the well-trodden path with ARM cores.
That's because a consequence of the second paragraph is that it's potentially business-profitable to make a "custom uarch" even if you make no use of the enormous scope for design changes.
The comment you replied to said "with a given ISA, how custom can the uarch be", implying that it would not be very custom.
You replied, in your first paragraph, that on the contrary, it could be pretty custom, with the implication being that it probably would be, because that's the value proposition that Ampere is presumably offering.
So your paragraph 1 is suggesting that the sentence "Ampere will now use a custom uarch" is an argument that Ampere's custom arch might well be pretty highly customized.
ON THE OTHER HAND....
Your second paragraph points out that simply being custom is a social signal (the signal of being, in your words, "that you mean business rather than just going the well-trodden path"). You argue (and I agree) that this social signal might make you more attractive to some customers. I.e. the signal might increase sales. This implies that it would be reasonable for Ampere to spend a certain amount on a barely-custom custom uarch, purely for sales/marketting reasons, as long as it didn't substantially harm performance. You know, because of the implication.
So your paragraph 2 is suggesting that the sentence "Ampere will now use a custom uarch" is NOT an argument that Ampere's custom arch has any particular need to be highly customized.
Well, Apple uses the ARM ISA for their A and M series chips, and but not ARM's microarchitecture, and their chips have significantly higher IPC than comparable parts from Qualcomm or Samsung. Similarly, Intel and AMD both implement the same x86 ISA, but the performance advantage has swung repeatedly between the two. Microarchitecture might be "in large parts" dictated by the ISA, but there's still enough left over for hardware designers to have a significant influence on the overall performance.
This is very much not the case. Just consider that, for example, Intel still supports running the same ISA that ran on 8086. The microarchitecture now running those instructions isn't at all like the 8086 microarchitecture. (Its running a bunch of other instructions too, but the points stands)
An example in the reverse direction, is that a some MIPS chip teams saw that MIPS was dying, and reused their MIPS microarchitectural designs to build ARM processors.
Sure, ISA can be designed assuming some things about microarchitecture, and then it can be inconvenient to change it. But not impossible. And during the transition to ARM64, ARM took the opportunity to remove things that were inconvenient for different microarchitectures (eg, directly accessible PC reg, changes to how condition codes work, etc)
Refer to RISC-V unprivileged spec, chapter one. Not dictating microarchitecture is one of its goals.
I don't think you can patent trivial details of "API" but you can absolutely patent a given function of an ISA.
You probably shouldn't be able to (Alpha vs. MIPS, x86 etc.) but currently you can.