Stupid?! The type of reader paying $500/year for the Microprocessor Report (where this response article appeared) already knew. (Similarly if they were motivated to get it free or took time to read it through their university, company, pirate it, etc.) And the ARM response you'll didn't mention RISC-V by name specifically.
The notion of an open source entity building an open or semi-open ecosystem cannibalizing even a low-end player was already happening in phone operating systems (Android/Linux vs Windows); a parallel dynamic wasn't lost on anyone looking at the hardware/ISA side, phone or non-phone.
I don't see this as any more foolish than Bill Gates making the case for software licensing vs free software at the dawn of the PC revolution. You may disagree with one party or the other, but each laying out their case is a marketing must. If you want to compete at the low end, you have to explain your value proposition vs "free".
And 40 years later, after FOSS folks thought to have won, everyone is going with open core, finally realising why businesses don't want anything to do with GPL like licensing.
So anyone that thinks RISC-V isn't going to trail a similar path, is fooling themselves.
I'm not even sure what side he thinks he is on. RISC-V isn't an open core, it's an open specification of the interface (only) between hardware and software. And it's not GPL, it's CC-BY-4.0 (BSD/MIT-like).
--4th Workshop on Computer Architecture Research Directions,
https://ieeexplore.ieee.org/document/7542457
Mark D. Hill; Dave Christie; David Patterson; Joshua J. Yi; Derek Chiou; Resit Sendag
And 2015 full video recording of the debate between Patterson and Christie: "CARD 2015 Mini-Panel #1: Open Source versus Proprietary ISAs"
https://www.youtube.com/watch?v=novCbl4Wq3I
The company was founded in November 1990 as Advanced RISC Machines Ltd
and structured as a joint venture between Acorn Computers, Apple,
and VLSI Technology.
The comment implies, though, that they get a special deal because they are a founder. Neither Wikipedia nor the linked articles say that.
There won't be a source because the details of the current commercial contract between Apple and Arm will be highly confidential.
In any event, it's vanishingly unlikely that Apple gets some special unique rights to IP created in the 2000s as a result of having a big shareholding in Arm in 1991 which they sold completely in the 1990s.
Yes, Apple probably gets a great deal but because they are a huge, enormously high-profile customer who has worked closely with Arm on the development of their latest IP.
Also this deal until 2040 (signed nine months ago) is crazy. I can't imagine why Apple would sign such a thing unless they got really phenomenal terms.
And why would Arm give such amazing terms?
Not because Apple was an Arm founder 35 years ago.
It's probably because Apple showed Arm a prototype of a Mac or iPhone running on "Apple Silicon gen 2" aka RISC-V.
I think your analysis sounds good: Apple certainly gets special deals, but those deals don't have anything to do with having been a major share-holder of ARM some 30 years ago.
Thanks for your comment on the analysis. I see this all the time, often in even more extreme form, such as Apple gets it all for free! You can look at Arm's accounts in the 1990s and prove that Apple never got it for free.
> ... we have entered into a new long-term agreement with Apple that extends beyond 2040, continuing our longstanding relationship of collaboration with Apple and Apple’s access to the Arm architecture.
That's not even a contract but a public statement. A lawyer would wipe her ass with it.
We do not get to see the actual agreement, and this "access" could very well mean the RAND I mentioned, i.e. that they won't be arbitrarily denied a license.
Incidentally, the key word "license" is remarkably not included in the language used.
It's such an obvious hit piece by a competitor where many of the arguments boil down to essentially "they did it differently to us and hence they're wrong".
Instruction set baselines should ideally be well-regulated open standards. They should also be good, and not moronic academic projects running of 32B opcode space because of religious dedication to silly extensions and the uniformity of an ISA for saving pennies on microcontrollers to high performance CPUs.
RISC-V in principle is a great idea. Hopefully we’ll get something that’s at the caliber of a well-oiled machine backed by real experience and practical high performance use like Arm V8 and V9 someday that’s a bit more open, but as of right now RISC-V not only isn’t that on a technical level but is fighting some serious fragmentation.
I don't see why "moronic" was needed there. Also Risc-V has profiles that group multiple extensions together for specific use cases. For example RVA23[0] which requires 64 bit and vector extension among many others. Operating systems like android can (and most likely will) specify that they only support certain profiles.[1] Lastly, ARM is also fragmented between Armv8 and Armv7 which android developers are still supporting.
>RISC-V not only isn’t that on a technical level but is fighting some serious fragmentation.
Do you have any evidence to support this? Seems like RVA23 will be the first majorly supported extension. All the "high performance CPUs" right now are just dev kits, so I don't see how there can be fragmentation in a market that does not yet even exist.
>All the "high performance CPUs" right now are just dev kits, so I don't see how there can be fragmentation in a market that does not yet even exist.
It comes straight from the "RISC-V know the facts" FUD campaign ARM infamously ran.
Yet, not even these dev kits suffer from "fragmentation". Basically:
- Previous wave implements RVA20, some of them with custom extensions, such as a harmless pre-ratification V extension.
- The open software ecosystem is built for RVA20, which the hardware supports. Vendors run their experiments within custom extension space, no harm is done.
- Current wave implements RVA22 with the ratified V extension, some of them with harmless custom extensions. As newer RVA profiles build on older RVA profiles, these chips run RVA20 code no worse than the previous wave.
I think David Chisnall's article is very good. However I don't think you should oversell the few issues with RISC-V. There are definitely some design mistakes, but overall it is good. I would say as good as ARM (but not as mature yet).
Also... consider how successful an insane instruction set like x86 is! The ISA definitely matters for performance, but it clearly doesn't matter that much.
Also the uniformity of the ISA is very nice for compilers. Sure in practice you're only ever going to use x1 or x5 for your return address but adding the hard constraint that you can only use those is definitely going to complicate some software.
I'm not sure what you mean about fighting fragmentation. I used to think that but I didn't know about the RVA profiles.
Indeed, I think he's repeating something that is today outdated information. With RVA profiles, we know what desktop-class RISC-V looks like, and that's what people might compare against ARM.
> Avoiding flags also has some interesting effects on encoding density.
That's one thing I liked about the Mill CPU was the belt, but I thought it was misplaced for data, and would be a great way to just carry the FLAGS register instead.
This would make conditional testing much easier and would mean you don't have to be as concerned about intermediate instructions updating flags before you use them.
I never had time to deeply think about it. Does someone want to tell me why this is actually a bad idea?
There was a reimplementation of SuperH as https://j-core.org some years ago and AFAIK it didn't really go anywhere, sadly.
One of the things you get when dealing with OEMs, and IP licensors like Arm, is a huge amount of paperwork about patents, and I used to believe this was annoying, but have come to believe it is vital. The alternative "open" "free" approach leads to something like the cloud world, where in practice it's AWS/GCS/Azure and some others in lower tiers, because of the complexities around the open/free stacks and IP tarpits that result. Just look at how AWS behave. We must be able to pay to develop and license these pieces, or you will end up with all IP being trade secrets and the vertical monopolies will get utterly entrenched.
There are definitely patent trolls around but the free case would be much stronger if financially viable open source software development were a thing.
So rather than getting stuck in potential future tarpit of AWS or GCS or Azure, or probably a dozen other companies, we should voluntarily put ourselves into the IP tarpit developed by ARM? How exactly is that a win?
Over the last two decades ARM has developed a stranglehold on the non-x86 world, and they have already considered abusing this position to increase their profit margin[0]. As a chipmaker you're essentially stuck with ARM, as getting rid of them means you not only need to redesign your chips, but you also need to completely overhaul the entire downstream ecosystem.
With RISC-V there's at least the possibility of switching to a different IP vendor. That might not practically happen with bleeding-edge SoCs, but that kind of flexibility is quite important for the far larger dime-a-dozen MCU market. It's exactly why companies like Western Digital are investing in RISC-V and even developing open-source implementations[1]. Compute is essentially a commodity already, so why not tear down the walled gardens and force it to be one?
Arm didn't develop the IP tarpit, they're one of the few players that learned how to operate in it.
The SuperH example is relevant because what Arm did was "that's neat, let's license it" for some of the Hitachi innovations, and then licensed it to other people too. This is a positive development, and how trade and innovation has worked through the most successful periods in history.
There is a respect in which they are more comparable to the MPEG-LA than a conventional company, but they do not have a reputation for shady antics, unlike some of their customers!
MPEG-LA is a very bad example. For starters, it's not MPEG; and furthermore there isn't a single MPEG patent pool anymore. There's like three of them, plus patent holders that haven't actually joined a pool, and that's made H.265 licensing a living nightmare.
Don't take my innovating-hating Stallmanite commie ass's word for it. Leonardo Chiariglione himself - a man who is adamantly opposed to royalty free formats being the superior standard[0] - has pointed out significant problems with the ISO MPEG licensing model of "we use whatever's best and let the patent pools sort it out". See: https://blog.chiariglione.org/a-crisis-the-causes-and-a-solu...
Since he posted that article, ISO cut MPEG into a bunch of tiny pieces and Leonardo was pushed out of the organization he founded, presumably as retaliation for airing the dirty laundry. He now runs a competing organization (MPAI) with very specific licensing requirements specifically to ensure patent pools don't go nuts screwing over users of patents.
[0] To be clear, he doesn't hate royalty free, he just wants it to be deliberately inferior so that research labs can make money off the patent royalties to fund more research.
Amazon also, of course, designs ARM cores. But they do seem a tad less “locked in via complexity” than their cloud stuff. I wonder if that is a result of the license situation. Alternatively, Amazon may just not be very good at coming up with hardware extensions, and also trying to commoditize their complement.
Google v. Oracle was not about interoperability: as the decision presents it, Google copied the APIs for Android specifically because they didn't want false interoperability with desktop Java. Instead, the court found that the use was transformative (bringing Java to a new, distinct platform), insubstantial (the declarations being non-central to the overall implementation), and with little market effect (Sun/Oracle having failed to make its own mobile Java viable).
In contrast, reimplementing a copyrighted ISA would quite clearly be substantial and could easily have large market effects. So you'd have to lean heavily into the idea of interoperability to overwhelm the lack of these other factors, or argue that the ISA is not copyrightable per se.
Also, even if an ISA isn't copyrightable, you have to watch out for patent rights the owner might have over any part of the ISA.
The vast majority of ARM licensees aren't doing anything transformative, that's for sure. But would something like the M1 - bringing ARM to the desktop when all past attempts have failed - have been considered transformative?
The question of what constitutes a "large market effect" is a big one...if I make a chip to serve as a controller in my brand of hard drives, is that a large market effect? ARM loses out on a few pennies per drive or something.
And I'd dispute the characterization of micro-architecture design as "insubstantial". Not accusing you of this, but this really has been the most frustrating thing about RISC-V - software engineers who don't know anything about CPU design comparing it to Linux when really it's more like POSIX or, yes, the Java class library. The insides of microcomputer CPUs haven't really resembled their interfaces very much since the early 80s - even the 68000, a consumer-grade CPU that's 45 years old (!) was designed so that the microcode engine that drove it could be used to implement an array of instruction sets. Any useful implementation of a CPU has an enormous number of internal details that aren't implied by the ISA.
> Any useful implementation of a CPU has an enormous number of internal details that aren't implied by the ISA.
If anything, I'd say that it's precisely because of this independence that an ISA can be seen as a separate work from any of its existing implementations. So what I'm trying to get at, is that if an ISA is copyrightable at all, in whole or in part, then any complete re-implementation will be copying most of the ISA's own substance, regardless of differing internal details. (Where by 'ISA' I specifically mean the external interface that software can access.)
The case Amdahl brought against IBM tackles this question directly. It may have settled, though. (I was a CPU logic designer at Amdahl for a while. Some people had access to info from IBM under the terms of the settlement. They could read and make plans. Then one day they could walk down the hall and tell me about new tasks on my to-do list. )
It would in light of decades of case law prior to Google v. Oracle. An instruction set itself is not protectable IP, only descriptions and implementations are.
What restricts new implementations are:
1. Existing legal agreements, eg if you agree in a contract that you will treat an instruction set as protectable IP, you’d be violating the contract. (Assuming the contract is valid.)
2. Patents, if you need to violate a patent to implement an instruction set then you need to license or wait out the patent, or figure out a way to work around it.
I believe both of these were at issue in Intel v. AMD, since AMD was initially a licensed second source, and Intel thought you couldn’t implement the Pentium instruction set without violating its patents.
Most likely yes. In Google v. Oracle, the Supreme Court ignored whether software APIs are copyrightable and instead performed a fair use test. Oracle's Java APIs remain under copyright, but Google's use of the APIs were fair use.
I rephrased the question. The instruction set may be copyrightable, but as in Google v. Oracle, we don't have to answer that question. Even if an instruction set is copyrightable, then under Google, it is probably fair use to copy it for interoperability purposes (e.g., making a compatible processor or emulator). For the actual binary encoding of instructions, there is even less of an argument for copyright protection because the encoding is purely functional.
You can patent an ISA. And then everyone who implements that ISA, in hardware or emulation, is infringing. Intel actually threatened lawsuits against Microsoft for implementing emulation of recent x86 instructions on ARM Windows.
You cannot patent an instruction set architecture, but you can patent mechanisms used in the implementation of the instruction set architecture. This is an extremely important distinction.
Usually these patents are written such that it’s difficult or impossible to implement the covered portions of the instruction set without violating the patent, but that’s by no means guaranteed.
arm thumb-2 is over 20 years old now, so any patents that cover necessary techniques to implement it are expired by now (unless they are lemelson-style submarine patents from much longer ago that issued very recently)
I fully support the idea of open instruction sets. I am not as much sold on the idea of cookie-cutter one-size-fits-all instruction sets. RISC-V is very nice for teaching CPU basics, and it is a great fit for tiny cores or specialized microcontrollers. Unfortunately, since it has been designed for simplicity it appears that it makes it harder building high-performance cores. RISC-V philosophy for high-performance OoO cores relies on instruction fusion, and thus would require the compiler to emit fusion-friendly sequences for best performance - and these sequences might differ from CPU to CPU. To me this seems to go against the very idea of common open ISA. We already see quite a lot of fragmentation and I fear it will only get worse as time goes on. More complex instructions that combine multiple processing steps would help, it seems that the core RISC-V community is opposed to that idea out of purely ideological reasons.
> More complex instructions that combine multiple processing steps would help, it seems that the core RISC-V community is opposed to that idea out of purely ideological reasons
Thats not true, the Scalar Efficiency SIG is currently working on such an extension.
I remember last year (?) Quancomm proposing an ISA extension that brings ARM-like addressing modes and paired stores to RISC-V, and the community reaction being very negative. Happy to hear that there are now initiatives to streamline these proposals and make RISC-V a better fit for high-performance CPUs. I am looking forward to future developments!
The negative responses were, because Qualcomm wanted to remove the C extension from the application profiles.
Qualcomm prefered a strict 32-bit instruction set, with potentially 64 bit naturally aligned instructions. RISC-V is designed for 16, 32, 48, 64 bit instructions that are 16 bit aligned, and retroactively changing that wouldn't have been a good decision. Both sides of the argument agreed that both options are resonable and don't hinder high performance designs.
Qualcomm seems to have accepted this now, as they e.g. proposes 48 bit instructions with larger immediats.
Apple was a co-founder of Arm [0]. "Arm was officially founded as a company in November 1990 as Advanced RISC Machines Ltd, which was a joint venture between Acorn Computers, Apple Computer (now Apple Inc.), and VLSI Technology (now NXP Semiconductors N.V)."
I'm not sure of their exact licensing terms, but I'm sure as a co-founder they're favourable.
Ah. In that case, I'm not sure what the difference is. Both Rosetta 2, and WoW are translating blocks of code to native, not doing a CPU emulation...
I'm wondering if Apple actually has some sort of license to do the translation. Rosetta 2 isn't installed by default. On the PS3, Sony had a pile of media codecs available, and you had to enable each one manually to generate a license key... which I'm sure was to avoid paying for codecs that people aren't using. Rosetta requiring an installation could just be space saving, or could be a sign they're paying a license per install, and avoiding the cost when it's not needed.
RISC-V currently has an installed base of around 15 billion CPUs, increasing at a current rate of maybe 4 billion a year.
The first half a dozen relatively low performance [1] brands and models of laptops and tablets have come out in the last year, as has a workstation with 64 OoO cores running at 2.0 GHz, 64 MB L3 cache, 128 GB RAM.
By the end of the year RISC-V SoCs will be shipping with 2x the IPC they had at the start of the year, and also significantly higher clock speed. 8 or 16 cores will be the norm, vs 4 at the start of the year.
You're going to see RISC-V smart phones by around 2026 or 2027.
[1] something like late Pentium III per core, but quad core.
free instruction sets: this "langauge" should be spoken by all! a public ISA
private instruction sets: this is a private matter, restricted to a need-to-know basis. private ISA
the main difference is the private one can sneak in magic backdoor instructions, lost in the vastness of a 2^bit_depth space
which is better for a languge? to be spoken used and known by many? or to be unkown and obscure? the funky business is that ISAs pictured as "languages" are spoken by microcontrollers; which scrambles the private/public issue
It seems like, if someone has the ability to slip an evil instruction into a proprietary ISA, they could also slip an evil instruction into their implementation of an open ISA and just not document it. RISC-V leaves room for proprietary extensions, right? Why not use that?
I think RISC-V is very cool and the future, but I don’t really see how it helps here.
It doesn't help at all. That issue is entirely orthogonal to "open vs proprietary" ISA. The ways a compromise can be implemented are effectively infinite and need not be anything as obvious as an undocumented instruction. A predictor, for instance, can detect a specific sequence of instructions and fill the pipeline with whatever it wants: no undocumented instructions involved at all.
I imagine, with knowledge of the ISA, can help one can define a verification algorithm, in which, the CPU is probed with some known inputs to gain confidence that there is no backdoor.
> in which, the CPU is probed with some known inputs to gain confidence that there is no backdoor.
There are 2^64 possible values for a single register. It's not possible to probe all possible combinations of values for the over 60 user-accessible registers, to find the single combination which, when calling a specific one of the more than 2^30 possible instructions, silently flips a secret "disable all permissions checking" bit.
I did a 5 minutes search. There seems to be a lot of work in detecting hardware trojans. Sec 3.12 here [1] discusses some of these approaches. One line is one of the things I was thinking of when I commented. Basically, there are tradeoffs of how logically hidden the trojan is against how physically exposed it is.
> Using this defense method, any Trojan that can analyze the entire configurable structure must use complicated logic functions and take up a large silicon area, which greatly increases the possibility of being detected by security tools.
There are live methods of detecting trojans as well, where you have an additional chip checking what the CPU is doing at all times [2].
One of the main thing I have learned in my life is to not underestimate the ingenuity of cryptographers.
It is, however, in principle possible to prove that a processor implements the spec and only the spec; seach for "formal verification risc v" to find out more.
Of course if someone can sneak a backdoor into the spec, all bets are off.
You would also need to prove that the physical processor in your hands was actually manufactured according to the verified design, and not a slightly different design with a back door added. Which is infeasible for all processors manufactured in the last 30 years.
And even if you did this, which may in principle be possible, you still wouldn’t be able to prove that there aren’t any backdoors leveraging unexpected physical interactions between components.
For example, even if everything was provably manufactured to spec, it could be laid out in a way that exposes side channels, enables rowhammer-like attacks, and so on.
The value of the public ISA then is that you can implement your own conformant version if you're super paranoid.
If the US is terrified that Chinese RISC-V processors have backdoors, they're free to manufacture their own version with their preferred assortment of bavkdoors instead. The software should remain compatible.
No one said they shouldn't be. I mean, its not like there are laws saying they cannot be free. Patternson has always used too much hyperbole and marketing himself as a crusader. RISC-V is great, let the technology speak for itself.
With market forces being the way they are, the quality of technology is becoming increasingly irrelevant. What counts is having a dominant position so you can shove down your "product" right through everybody's throat.
Well not only that but choices about these kinds of things are often made by people that don’t necessarily know what options they have. Marketing is a big part of what choices people make because they don’t know what they don’t know
https://web.archive.org/web/20140926222155/http://www.linley...