Does ISA Ownership Matter? A Tale of Three ISAs
codasip.com
codasip.com
So, what prevents that association from selling the IP? Reading the articles of that association (https://riscv.org/wp-content/uploads/2020/04/Certified-copy-...), there must be at least 5 board members appointed by different companies and individual members, so that seems good. It also says the general meeting cannot decide to merge into an entity with largely different goals. I don’t see anything forbidding the sale of IP, though (and the board is explicitly in control of that), and couldn’t figure out whether the board can lock out non-members from using the ISA, prevent companies from becoming members, etc.
Also, as is common with these kinds of associations, it is geared towards companies (premier and strategic members each appoint a director in the board, while all individuals combined appoint 2 others)
My (IANAL) overall judgment from cursory reading is that it looks fine, but isn’t 100% bombproof.
(I also noticed that site is using https://sso.linuxfoundation.org/login, but doesn’t seem to mention any link between those organizations. Is there any?)
Nothing is "100% bombproof".
They probably don't want to clog up their articles of association with detailed limitations which might not be needed and which might get in the way of doing useful things in tune with their original purpose. Keeping the association true to its original purpose is really up to people and culture, not legal terms. I'm pretty sure lawyers (which I am not) would advise to keep details out unless they really need to be there, too many detailed rules can just add to legal uncertainty (doubts over exactly what they mean) and risk (lawsuits if someone thinks you've violated them, or if they were accidentally violated due to oversight or difficulty in understanding them, etc).
I’m not sure whether the ownership changes can be attributed as causes or as symptoms of ISA market failure here. My understanding is that somewhere from 2000-2010, the cost of developing a cutting-edge ISA + an associated line of CPUs got too expensive, and companies like SGI were priced out of the market.
In other words, MIPS wasn’t sold off and then it failed. SGI needed to get rid of MIPS because it was too expensive, and without the backing of SGI, MIPS was doomed to a “cheaper, older-generation” CPU niche. There but for the grace of god goes ARM, which happened to find a new niche because it was already optimized for a use case (low power consumption) that people started really caring about in the 2010s.
Like, if you are buying 10,000 x86 processors from Intel, then you tell Intel, “Don’t charge us too much, or we’ll buy POWER systems from IBM instead.” Intel chuckles, since they know you’re not serious, but (1) you buy a few racks of POWER systems and make your engineers build and test everything on POWER to make your negotiation position more credible, and (2) Intel knows they can’t charge you more than IBM does.
The other niche for POWER, as far as I can tell, is that it has various certifications, or it’s used in systems with various certifications that x86 doesn’t have (e.g. certain aerospace / defense applications). For example, the RAD5545 is a rad-hard POWER SoC.
Although I have experienced that the vast, vast majority of problems can be divided to run on multiple cores, assuming you have enough work for the cores. There was a problem where I convinced myself it could not be done without locking and a complicated transaction scheme but I still somehow managed to turn the problem into a data parallel algorithm. The code is extremely counterintuitive, error prone and both hard to write and read.
However, writing a purely parallel application is so much work even for an expert that there is a huge productivity drop in many cases and for non experts a lot of the problems are intractable, so it is only done when absolutely necessary.
So my general strategy has been to significantly relax maximum possible parallelism in exchange for the ability to pretend that your code is single threaded. The general idea is quite simple. Split your data into smaller segments. If a segment accesses another segment merge the two into a big segment. Then process each segment as if it was single threaded but you can process independent segments in parallel.
The big problem with this approach are pathological cases where you get very large segments.
One (fictional) example would be a simulation involving long distance transport. Train stations that are connected with rails form a very huge graph of segments consisting of dozens of train stations. However, airports are not connected so each airport can still be simulated in parallel and if you have multiple rail networks you can simulate each on a separate core.
It's far faster than staying purely single threaded but it means that you will always be bottlenecked by your slowest core and that means current ARM offerings will be behind unless you are doing something extremely multi core intensive like video encoding which will gobble up as many cores as you have.
This is why I wasn’t very excited by Altra Max benchmarks. Eventually we will have ARM suppliers that can churn out motherboards and associated components with the kind of magnitude that can put a dent in x86 usage, but in the meantime, the only company that seems to be doing it is Amazon, who uses their own custom ARM server designs.
Given enough time, suppliers for ARM servers will rise up, if the processors are competitive, but that won’t happen overnight. Certainly not just because of one new CPU.
The whole point is that POWER actually exists (on 7nm etc.)
Earlier than that, the PDA/smartphone market (e.g. https://en.wikipedia.org/wiki/IPAQ ) was ARM a decade before, and the iPhone was in 2007.
I believe MIPS CPUs were in laser printers etc, but out of the mobile market, except for the occasional laptop.