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:
>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?
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.
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!
[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.
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.
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?
