Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)(www2.eecs.berkeley.edu) |
Instruction Sets Should Be Free: The Case for RISC-V [pdf] (2014)(www2.eecs.berkeley.edu) |
https://web.archive.org/web/20140926222155/http://www.linley...
Back then, RISC-V was not anywhere as well-known as it is today.
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".
"Proprietary versus Open Instruction Sets" https://www.ele.uri.edu/faculty/sendag/papers/micro2016_2.pd... (pdf)
--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
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.
https://www.theregister.com/2024/05/29/riscv_messsaging_stru...
And here’s David Chisnall on ISAs, which do matter:
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.
[0] https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf
[1] https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
Edit: Changed phrasing of question. Also, to be clear I think the answer is probably yes.
Thats not true, the Scalar Efficiency SIG is currently working on such an extension.
See this spreadsheet of discussed instructions: https://docs.google.com/spreadsheets/u/0/d/1dQYU7QQ-SnIoXp9v... and charter: https://github.com/riscv-admin/riscv-scalar-efficiency/blob/...
I'm not sure of their exact licensing terms, but I'm sure as a co-founder they're favourable.
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.
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
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.
There's nothing keeping an implementation of a public ISA from adding backdoors.
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.
What are you even talking about?
>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.
[0] https://github.com/riscv/riscv-profiles/blob/main/src/rva23-...
[1] https://opensource.googleblog.com/2023/10/android-and-risc-v... (note: the blog mentions RVA22 but this has most likely been switched to RVA23 before full Risc-V support lands in Android).
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.
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.
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?
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?
[0]: https://www.techpowerup.com/300385/arm-could-change-licensin...
[1]: https://blog.westerndigital.com/risc-v-swerv-core-open-sourc...
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!
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.
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.
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.
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.
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.
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.)
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.
So anyone that thinks RISC-V isn't going to trail a similar path, is fooling themselves.
For some definition of everyone.
What clearly is subject to copyright is the documentation describing the instruction set and its semantics.
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.
> 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.
[1] https://arxiv.org/pdf/2107.04175
[2] https://re.public.polimi.it/bitstream/11311/1204477/1/DFTS_2...
Of course if someone can sneak a backdoor into the spec, all bets are off.
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 company was founded in November 1990 as Advanced RISC Machines Ltd
and structured as a joint venture between Acorn Computers, Apple,
and VLSI Technology.
There's some claims in this article and in the routers article they use as source, but they're unrelated.
> ... 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.
Arm's IPO F-1/A.
https://www.sec.gov/Archives/edgar/data/1973239/000119312523...
Which was linked in the MacRumors link.
>agreement
and
>access to the Arm architecture.
Is vague language that could mean about anything.
E.g. it could mean RAND ("reasonable" and "non-discriminatory").
Namely, the parent specifically claimed:
>Apple has a licensing deal with ARM through 2040
The vague language is insufficient to support the claim.
> we have entered into a new long-term agreement with Apple that extends beyond 2040, continuing … Apple’s access to the Arm architecture.
Clearly says that the agreement continues Apple’s access to the Arm architecture beyond 2040. That’s what a licensing deal is.
This is an important disclosure. Any attempt to pass something less than a licensing deal with this wording wouldn’t get pass the lawyers.
Do you have a source or not?
https://appleinsider.com/articles/20/06/09/how-arm-has-alrea...
https://appleinsider.com/articles/08/07/30/arm_reports_finge...
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.
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.
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.