Chips that pass in the night: How risky is RISC-V to Arm, Intel and the others? Very How well does Intel sleep? It's just rounded off a record year with a record quarter, turning silicon into greenbacks more efficiently than ever, redeeming recent wobbles in the data centre market and missteps in fabrication with double-digit growth. The company should be slumbering with all the unworried ease of Scrooge …
For now market forces are not corroborating this though. For the 10 years it's been heralded as the saviour of open computing it's still very marginal, sadly.
One thing that could be an issue IMO is the extendability itself. Customised instruction sets means customised software, customised compilers to make the most of it, custom drivers, and basically a lot less reuse on the software side. So there has to be a really strong benefit to invest the time and money into this. The same reason that everyone is now using Linux instead of rolling their own OS: It's not always a great fit but it's just not worth the trouble to roll your own.
Arm and intel are pretty good at introducing new features to support new trends, like their encryption and virtualisation extensions that are now commonplace and really beneficial. Yes, they make mistakes too, but as a smaller company, can you really do better?
I would really like to see RISC-V take off but I have a feeling that its biggest benefits are also its biggest obstacles.
"but as a smaller company, can you really do better?"
RISC-V itself isn't a company, it's a group of companies cooperating. It might be chancy for a single vendor to make its own extensions but it could be quite feasible for some or all of the group to decide on the need for a given set of extensions and cooperate on those as well.
In addition to being a dubious value to companies with working systems, RISC-V has a problem with the installed base - there are not that many examples of real world success. It's the opposite of Intel's problem where X86 was so successful that they couldn't make a next generation. RISC has been an interesting concept since at least IBM's Power days but it's never taken hold.
Intel moved to a RISC core ages ago. It makes sense. The x86 architecture, based (sort of) the VAX architecture is successful because of the RISC simplicity. They also have had a lot of expertise in build RISC processors: the 80960 was a processor I worked on.
And as someone pointed out: more ARM processors get shipped than x86 chips.
If you ever have to use AWS, you will see ARM processors as options. I have seen this story before: IBM had to lose market share on the lower end (they were EVERYWHERE) to DEC PDP/VAX which gave way to Sun Sparcs, which gave way to Intel, which gave way to ARM.All of this was happening at the lower end. And soon, the scale of the invasion overwhelms the entrenched processors.
I'm not sure that the x86 instruction set is in any way similar to the VAX instruction set.
the 8086 is actually a linear development of the 8085 processor (itself a development of the 8080 and 8008) with some of the *Ziliog* Z80 concepts added.
The VAX instruction set was a 32 bit development of the 16 bit PDP11, which was a very regular and orthogonal set, so much so that many of the register and memory addressing modes were implemented using the same mechanisms (for example, the Program Counter was manipulated using the same instructions such as auto-decrement as the other registers).
Use of the registers were more generalized in the 8086 than the 8085, but they were still more specific than the VAX.
Any resemblance is at the conceptual level.
"RISC has been an interesting concept since at least IBM's Power days but it's never taken hold."
x86 is closer to a RISC architecture than a CISC architecture.
All modern RISC architectures that include SIMD/crypto functionality (i.e. specific instructions for specific functions) move away from the philosophy of only using general purpose, single clock cycle instructions to simplify instruction sets.
The reality is that RISC-like architectures won the CISC vs RISC war, with all architectures moving to that philosophy with exceptions where more complex instructions make sense. Saying ARM/PowerPC/RISC-V/MIPS is better than x86 because it is RISC is a failure to understand the underlying x86 architecture.
If you want a nice, simple soundbite, go with "everything is better than VLIW"
VLIW was awesome as fuck (to rip off Green Day) -- but COMPILERS? That was the hard part, and still is.
So too will compilers be a problem for RISC-V, because adding to the instruction set means adding compiler, and library, support for your new zippy-skippy instruction(s).
RISC is all about the compiler everyone. Once you have that, you can start compiling operating systems, RTOSs, and when you get Linux ported and singing a happy tune, you can try to port the browsers - and after all, JavaScript, JS frameworks (think React, Angular, and Vue, not to mention node.js), and the ubiquitous python allow for execution of enterprise applications (and, in the case of python, embedded code, too).
I worked on Windows NT for PowerPC, for Motorola back in the late Pleistocene. Some of my friends worked on DEC Alpha. I have experience with over 60 architectures (many of them DSP's, most of them dead as doornails). RISC-V is attractive because it's royalty-free, and as the late Harvard Business professor Dr. Clayton Christensen taught us, free and shitty eventually beats costly-but-awesome.
A shout out to Imperas Software, who is doing God's Work in providing software tools, simulators, and other fun and useful bits for the RISC-V world. I have no connection to them other than admiration.
Now, if Motorola had ever listened to Robin Saxby back in the day .... or built MCore better and had a better licensing scheme .... <sigh>.
Shout out to Lou Perazzoli and Dave Cutler, too, for Windows NT being sort of VAX VMS-like.
I'm getting freakin' old ....
>RISC-V has a problem with the installed base...
RISC-V may be relatively unknown but the general architecture is well known and widely used. Its similar to the MIPS or the soft processors like the Microblaze that is an IP option for a Xilinx FPGA. I've built numerous things with them and they work fine; the first place I'm likely to come across a RISC-V would be a replacement for the Micos-II in a Lattice FPGA as manufacturers coalesce around standard, open, designs.
We get bombarded by everything having to be the latest and fastest that we tend to forget that there are a lot of workhorse processors out there. This is actually how the ARM got traction -- it was initially a low power processor that's main claim to fame being it had a tiny footprint and modest software needs so could easily be incorporated into a ASIC design to do things like manage front panels and communications that were efficient to implement in hardware. Current ARMs tend to be as complex as an x86 which leaves a niche for a reasonable performance, low power and small footprint processor.
Just to remind you, ARM-1 and 2, SPARC and MIPS RISC processors were available before POWER (the original designation for the RIOS chipset, Performance Optimization With Enhanced RISC). IBM also had the ROMP (801) processor before POWER as well.
IBM POWER was only marginally a RISC processor, as it's instruction set had a lot more instructions and addressing modes than other more traditional Reduced Instruction Set Computer implementations (and quite a few CISC processors). In addition it's initial implementation was a 5 or 7 chip set (as was the multiple chip HP PRISM processor) rather than a microprocessor.
And in fact the Intel x86 processors from probably about the 486 have embraced RISC, with the processor being a micro-coded RISC engine that executes x86 instructions on the surface, but actually JIT compiles them into micro-instructions.
Power, this, Power that .... PowerPC was awesome until IBM didn't want to stay in their swim lane, started building PowerPC chips for the merchant market, and out-fabbed Motorola. Until the 970, which was hotter than hell and no, 200 instructions in flight at any one time didn't cut the mustard cause it ran too damn hot.
China went all-in with MIPS years ago. That didn't get them far. I could make a list of all the similar Chinese tech initiatives that never went anywhere... They are big, but not big enough to overcome economies of scale and focused R&D of the entire rest of the world.
An open architecture won't save them, either. Somebody needs to fab the chips, and Taiwan isn't guaranteed to remain on friendly terms. China can't keep-up on fabs, so they'll have to burn an awful lot of money just to stay a couple die shrinks behind the rest of the world and at a constant competitive disadvantage.
I'm sure they'll do it, if it actually comes to it rather than be entirely cut-off, but doing so would put them at several additional disadvantages to western technology companies. Really, China is just using it as another big bluff to get better terms in the negotiations, as they've done several times before. China want to scare western businesses into continuing to sell them the rope needed for their own future noose...
China doesn't need to get far. I suspect they just want strategic independence.
Beating "the rest of the world" is basically ARM, Intel and AMD - maybe add in nvidia if you're looking at GPUs. Add some already-tested switching tech and off you go. The whole scale-out/cloud push behind linux is going to mean that the infrastructure architectures will apply to x86 or arm or mips. I'd see MIPS doing best as a network-device cpu. IPv6 hardware switching anyone? "Slow" is relative these days. 400mb/s is slow but more than enough for mid-range enterprises' internet link routers. Want to do SDN? Make sure AES is done in hardware and you just need a management interface.
Extending the instruction set doesn't have to be that complex, just enough to mean you can sell fast routers with only a little bit of IP added on. It may not be as power-efficient as ARM, but if it means circumventing Trump's IP ban and being able to sell as much as you want, that's probably not an issue. Worse for the US, homegrown tech deprives the US of the growing market.
For context, Crossbeam were running blade-based backplanes with 120gig throughput based on MIPS years ago.
What happens when all those cheap little 5 port switches from tplink suddenly do 10G with transceivers and have a routing backplane? Or a 48-port switch with a 100Mb/s router - that should be more than enough for many businesses with internet connections.
Cheap normally wins. ARM has done well in unit terms by being cheap. If ARM is excluded from cheap Chinese manufacturing, MIPS has more than a chance to gain some ground because the cost of ARM has basically risen to infinity.
It doesn't matter that China is a bitbehind on tech. If China starts producing RISC phones with no-Google-playstore, it doesn't matter too much if the battery life is less than an iphone 11 pro max. Once the ecosystem is built, it will be tough for the West to make inroads.
The whole consolidation of data-centres is a western commercial thing based on the cost of DC space, electricity, licensing and the employee cost of IT management. I'm not sure those things are a concern in China.
You're talking about domestic consumption... I'm talking about China's export market. Huawei doesn't want to just own the Chinese market... that part is easy enough. What they (and the government) want is the world. There their products have to be good enough to be able to compete with non-embargoed competitors.
There are several ways to fight. You can either have a pitched battle (World War I) or drive around the Maginot wall. We chose the direct frontal attack. It has its advantages, especially when you have overwhelming superiority. I guess we don't have the financial clout any more. China can do as it pleases.
A more subtle approach escapes the general US public's view of the world, however. Sometimes I am ashamed and sometime I think it is our strength. This time it is not the best thing we could have done.
It was the direct frontal approach that nearly lost WW2 for the Soviet Union. Both they and the Chinese have learned from that.
Taiwan is an interesting point. The US says China will never get Taiwan back. I am not sure I would count on that in the long term, because the stakes are so high.
If you try and prevent access to some tech, then those that you are trying to prevent will develop their own tech and China has the ability to surpass.
For years, apartheid South Africa was embargoed and under sanctions. Then when the British Army needed an attack helicopter, South African Denel was one of the bidders with their rather excellent Rooivalk.
But SA was not entirely isolated. The US was VERY tardy in exiting Apartheid SA and Israel never did. Israel and SA were very tightly entwined especially on defence/nuclear terms. SA was looking seriously at obtaining nukes and going armed hermit kingdom.
A single guy in NZ designed and made a stealth helicopter. He made a big mistake though, he made it remote controllable and it then got classed as a cruise missile instead of a helicopter. He lost all his IP to his investors when it all want south. But the point is clever people in small countries can always to things.
Remember the Hamilton jet engine for boats was pefected by two brothers who wanted to mess around on the shallow, gravel bottommed braided rivers in Canterbury, New Zealand, you can't put an outboard in or have a propeller. Hamilton Marine are still going, you may have heard of them.
It spawned a motorsport which has now developed to custom built courses instead of using a digger to create them in the river bed. It's gone trans Tasman with legs in Australia. Small boats which can turn on a sixpence at speed with a crowd pleasing spray of water.
People said that about Japan up until the late 70s (and some still think that)
Same said about Korea till the early 2010s (80s and 90s Korean cars were competent but generally clones of other cars and old tech)
China is catching up and rapidly, for years they sent people to universities all over the world to learn (and people willingly went, 2 chinese guys I went to uni with explained why "either go to university overseas or join army, joining army not good" whilst looking around to make sure no one was listening in, his friend concurred with a very scared look at the mention of "army")
The people who said that about Japan were people who didn't understand that Japanese innovation lay in making things better. There were mopeds before the Honda 50, there were small motorbikes before the Benly, there were cassette tape recorders before the Walkman, they were all pretty much crap.
Huawei is in dead trouble with the US not because their 5G gear is a copy of the US stuff but because it is ahead of it. At least our Brexiters have openly come out and admitted they want the UK to be the poorest state of the US for fun and profit - their fun and the profit of their backers.
I'm not sure how much the ARM decision is important, at least in the short term.
ARM are not the producers of ANY chips (at least not in production quantities). ARM chips in Chinese products all come from other companies, and I'm sure that some of these will be influenced by the US trade restrictions, but I'm also sure that some of them aren't.
So there is probably still a route to getting ARM processors fabbed outside of China for products.
But I know that there are fab's in China. Bearing in mind that it is probably not easy to rescind an ARM development license (and also taking into account China's track record of abiding by rest-of-world patent law), I would expect that Chinese ARM and other microcontrollers will still be available.
For example, the Kirin range of processors are a Chinese design fab'd by TMSC.
"For the 10 years it's been heralded as the saviour of open computing it's still very marginal, sadly."
That's what exponential growth looks like -- not worthy of notice for a long time, and then suddenly it's everywhere.
Look at the number of hospitals recently saying "we'll worry about coronavirus when we see a case" and then one or two weeks later they're "Our ICU is filled to overflowing and we're having to decide who we just let die, we're running out of beds with oxygen, 10% of our doctors have caught it and the rest are working 18 hour days and aren't allowed to see their families".
If you haven't noticed:
- Samsung has said the new Galaxy S20 has one RISC-V core controlling the camera and another controlling the 5G radio.
- Qualcomm has said every SoC they ship from now will have RISC-V in it somewhere.
- Espressif have said the new version of the ubiquitous ESP32 wifi/Bluetooth chip with main CPU core still Xtensa but an ultra low power RISC-V management core has gone to volume production.
- Microchip / MicroSemi has said the version of their avionics / military-qualified FPGA with embedded penta-core RISC-V FU540 is available to qualified customers for development now, available in volume Q3.
- Western Digital / Sandisk should be shipping their first disks and flash drives with RISC-V in them later this year.
It takes companies like these four or five years to go from "Hey, that looks interesting" to volume production. All those companies started working on RISC-V products years ago -- and it wasn't really available to people outside Berkeley until 2015 -- and you can be sure many many others have started the process in the last couple of years.
As for extensibility. The vast majority of custom instructions I've seen proposed don't affect the rest of the software in the system, don't even require changing compilers. These instructions are usually used in two or three places in a software library to speed up some specialized thing by a factor of five or twenty or whatever. Often it's not even worth modifying the assembler to know about them -- it woudl be easier overall to just encode them in hex with a .word directive where you need them.
But in fact the RISC-V GNU assembler has a special ".insn" directive that lets the user's program source define a new instruction using any of a number of standard instruction encoding formats and then immediately use it -- no modifications to the assembler.
For details see https://embarc.org/man-pages/as/RISC_002dV_002dFormats.html
That covers small, secret, extensions anyone can make.
Larger RISC-V extensions that will be standardized and made available for everyone go through a review process where experts from *many* companies and universities and research organisations look at them, try experimental implementations of them, suggest improvements etc. This process slows things down, but it's quite likely that the end result will be of *better* quality than any one company would do.
... much as Microsoft lost the web and mobile to open-source software based on common architectural ideas.
I would hardly call Google Search, Chrome, or Android open source. You might be able to add an overlay to them, as happens in mobile or use them as a base of your design as happens with the various browsers based on chrome, but that doesnt make them open source...
I would hardly call Google Search, Chrome, or Android open source.
In addition to @deive's reply, which points out that upstream Chrome (Chromium) and Android's AOSP are Open Source, most of those web sites that are accessed by Chrome and whose content is indexed in Google search engines is run on Open Source webservers (Nginx, Apache to name the primary ones) runnning mostly on Open Source operating systems - Linux and the BSDs.
Most of the server-side systems run on Open Source webservers, operating systems, databases, directory servers and so on. Most of the shop-fronts backends use open source - or open source derived - database engines.
In fact TheReg's own 'Under the hood' link in the site footer states in part:
Your requests are served by a few Debian GNU/Linux servers, running nginx and Apache.All our web applications (search, forums, whitepapers, etc) are written using mod_perl and connect to MySQL or PostgreSQL databases.
Android itself runs on top of Linux - an Open Source project, without the Linux kernel in there there would be no Android as it is today.
The Chinese (EMUI, MIUI) and Korean (Tizen) mobile operating systems being developed as alternatives to Android are Linux-based.
Most of the network infrastructure these packest are being delivered by run on Open Source. Most home routers/modems/AP's run Linux, as do most of the CDN's (Cloudfare, etc.) that cache and deliver the content you are viewing. Even many of the Enterprise appliances are running Linux or a BSD, SSL accelerators, reverse proxies, 'white box' routers and other software defined network devices, ESB devices, the list goes on.
Has anyone left Cambridge to live on a tropical Island lately? I cant believe that no-one in ARM knew about the sudden uptake in ARM products after the buyout? Either Softbank was sharing developer information internally (and so illegally?) or someone at ARM must have seen what was going on.
> I cant believe that no-one in ARM knew about the sudden uptake in ARM products after the buyout?
The uptake in ARM-based products had been happening for at least a decade prior to the Softbank acquisition, and it was all public information.
I don't recall that the information about iPhones or Android smartphones or cable modems or storage appliances running on ARM or ARM64 was classified Top Secret anywhere.
> Heart Bleed, Spectre and the very latest Intel Management Engine vulnerability are all either signs of verification failure or, even worse, problems that came out during verification but were too expensive to fix and too dangerous to admit.
Heart Bleed was a bug in the Open Source OpenSSL library. Doesn't belong here at all, I think.
I'm not sure what your question means, but Heartbleed was completely processor-independent.
Presumably Rupert meant Meltdown, not Heartbleed. Though I don't agree with his argument anyway. Verification of CPUs won't "catch" things which are not violations of the specifications, and eliminating side channels wasn't part of the specifications. Asking verification to identify side-channel attacks is like asking a proofreader to correct weak characterization, or asking a hammer to loosen a bolt. Wrong tool for the job.
Not to mention you can get entire desktops and servers with Power from Raptor Computing Systems. I can't recall seeing an equivalent for RISC-V.
Oh, and the firmware is all open source alongside the open ISA, too:
https://git.raptorcs.com/git/
I use one of their desktops. Yes probably biased but I like it, and they do sell to Blighty!
"Not to mention you can get entire desktops and servers with Power from Raptor Computing Systems. I can't recall seeing an equivalent for RISC-V."
Of course not. It's too new. It's not even five years since the RISC-V Foundation was set up and everything open-sourced. It's only a year and a half since the base instruction set, initial extensions (MAFDC), and privileged architecture were formally ratified and set in stone.
POWER has been going for thirty years.
RISC-V vendors have started with small embedded cores, with only a couple recently starting to get more into CPUs suitable for mobile applications processors let alone desktop or server. The most sophisticated RISC-V core so far -- SiFive's U-84 -- was announced at the end of October and the way these things progress will probably see first silicon around this time next year, and get into products six to twelve months later. The U-84 is competitive with ARM's Cortex A72 which was in the hot phones in 2016 and just found its way into the Raspberry Pi in June/July last year.
Of course not. It's too new.
POWER has been going for thirty years.
Good points. What do you see as RISC-V's advantage over POWER, aside from the current hype train surrounding RISC-V? Genuinely curious, both seem interesting, though I still find a Beaglebone tends to do everything I need in an SBC at a more affordable price than an equivalent RISC-V thing.
> I still find a Beaglebone tends to do everything I need in an SBC at a more affordable price than an equivalent RISC-V thing.
Guessing you've not looked past the SiFive boards?
Take a look at AliExpress, as there are lots of RISC-V dev boards on there.
From the low end (32-bit etc), costing all of US$4.30.
Through to more up market, dual core 64-bit boards (with AI extensions) for US$20.
Haven't seen POWER dev boards around that cheaply, but that could just be my not knowing where to look.
I wish Raptor sold a laptop. I don't think there's been a POWER-based laptop since the RS/6000 Model 860.
Not particularly practical, I know. (It would be a perfectly usable Linux machine, but due to economies of scale it would be more expensive than a generic x86-based laptop.) But it would be cool.
Conversely, the "Trust us" stamp is looking quite tarnished. Heart Bleed[sic], Spectre and the very latest Intel Management Engine vulnerability are all either signs of verification failure or, even worse, problems that came out during verification but were too expensive to fix and too dangerous to admit.
I can see a doomsday scenario where one day a vulnerability is found which is unfixable and easily exploitable which would kill an entire CPU line. Almost all modern CPUs are vulnerable to some of these side channel attacks; but Intel's chips seem much worse than any other.
> doomsday scenario where one day a vulnerability is found which is unfixable
Well, there already have been a couple more or less unfixable vulnerabilities found in the last years, and what was the result? "[Intel] just rounded off a record year with a record quarter"...
Intel has a bulletproof insurance: It builds the CPU that runs Windows (and Apple), which means people will keep buying Intel no matter what vulnerabilities or other problems their products might have. (Yes, there is AMD too, but so far it's more Intel's anti-monopoly insurance than a real threat: Nobody ever got fired for buying Intel.)
"Intel has a bulletproof insurance: It builds the CPU that runs Windows (and Apple),"
Until it doesn't.
Windows has been demonstrated on other CPUs - most recently ARM, but I'm sure oldtimers can remember SPARC, Alpha and Itanium versions (as well as a rumoured MIPS port)
Apple have already demonstrated their CPU agility
Regulators have noted the past attempts at dominance where Intel would nobble supplies to makers selling appreciable quantities of AMD systems, rather than competing on merits
x86 shouldn't have won out - it had the highest power consumption AND slowest execution speed of all the competing processors. The only thing which kept it afloat was dominance of the desktop market via Windows and with that it was able to leverage into the datacentre.
Scenario: Apple announces the next generation of powermacs are ARM-powered and shortly afterwards MS launches Win10 for ARM to land on the increasing number of more powerful ARM notebooks (and gets out of the Surface hardware market entirely)
(Could be risc-v, could be ARM, but ARM is more likely in the short term)
At that point I would not like to be an Intel shareholder. AMD are a bit better insulated thanks to their GPU holdings
The closest thing to windows on MIPS that i'm aware of died with windows 2000, which was the last version of windows that had HAL support for the SGI 320/540, which were kind of a bastard child between SGI's MIPS based lineups and x86. Those had an ARC prom like SGI's MIPS lineup instead of a BIOS, as well a UMA memory architecture similar to what was used in the o2. But they had x86 CPU's
I was a systems architect for the Parasolid solid modeller in the '90s and we produced a prototype for Win/MIPS which ran well, unsurprisingly as we already had it running on MIPS under DEC Ultrix. IIRC, when the C compilers were handed over to MS to integrate into Visual Studio etc everything went titsup and we never went to production.
> Until it doesn't.
I wouldn't hold my breath. See what happened to Windows RT: Microsoft is clearly not eager to switch processors, I guess due to the existing software base which after all makes Windows' strength and biggest appeal (After all the #1 reason people hesitate to switch to Linux). Nobody wants to lose that ecosystem in exchange for a handful of dumbed-down Windows Store Metro "apps".
Also, corporate servers and the attached workstations will remain on Intel for quite a while: You won't change hardware and software on many thousands of workstations and hundreds of servers without a very serious reason.
Last but not least, the market is locked up: Try buying a high-end laptop with an AMD processor, your can count the choices on the fingers of one hand... Intel really doesn't have to (and doesn't) worry about its future. It survived all the nasty problems thrown at it those last years (fabrication issues, safety blunders, etc.) with flying colors (and stock value).
Most of the patents are EOL and open sourcing X86 would seriously slow down RISC-V advance.
Intel and AMD would not lose out much for many years as they have so much experience in the technology.
On another point Intel while far larger is vulnerable to AMD. :-
1) TSMC fab investment so much higher than Intels (and works). Partly depends on who ordered the most EUV
2) Chiplets add flexibility to inventory. AMD can put in a big order and then work out later which die to put them in.
3) AMD are big on both CPU and GPU which is becoming a thing in HPC.
4) Lisa Su a great boss. Bob Swan bonus dependent on share value not high volume production of next generation fabs. By a whisper he got his $25m bonus as Intel shares stayed above $62 for 31 days in a row Jan / Feb. He needed 30 days to get it.
Of course a massive earthquake in Taiwan, a hack or Xi trying to divert attention could make AMD very vulnerable but not even Intel at its worse would engineer this...(hopefully)
"1) TSMC fab investment so much higher than Intels (and works). Partly depends on who ordered the most EUV
2) Chiplets add flexibility to inventory. AMD can put in a big order and then work out later which die to put them in."
TSMC currently have 110,000 7nm wafer starts per month and a lower reported yield than Intel at 65%-70% for AMD CPU's. AMD doesn't' get 100% of this capacity.
Intel have approximately 500,000 14nm (9 x fabs @60,000 each minus some downtime for maintenance) wafer starts per month and yields of 80%-85%. At 10nm, they have ~80,000 wafer starts per month and very low yields, but 10nm+ appears to be functional and will allow a further ~100,000 wafer starts per month due to improvements in tooling and less maintenance.
AMD appear to be doing everything right, and I suspect Intel will continue to struggle until their EUV process comes on-line and they can compete with TSMC again (likely end of 2021/beginning of 2022) but don't underestimate just how big a head start in terms of fab investment/production capacity/sales/available funds that Intel has.
Anything could go open source, but often the embarrassment isn't worth the gain. In the last few years, we have been privy to some of intel's stupendously bad engineering decisions. Anybody peeking in wonders is it possible to run mission critical code on x86 cpus at all?
Case in point -- treat the L0 cache as a virtual cache. Unless you have spent time in this area, it is tough to parse, but the basic idea is this: in a physical cache, you have to wait until the mmu-hardware validates the address, loads its physical translation, then push that translation into the cache(s) to see if the memory is instantly available.
Many RISC architectures had recognized the latency in this, so used a virtual zero level cache, so they could spit the program address into the cache int parallel with the mmu, thus reducing the latency. These architectures used "address space identifiers" to segregate the virtual cache for protection.
Intel noticed that *most* of the time, the lower N bits of Virtual Address == lower N bits of Physical Address, so shipped a masked Virtual address into the level 0 cache at the same time as waiting for the mmu to respond. Thusly, they simulated the performance gain of a virtual cache, with the maintenance simplicity of a physical cache, at only the cost of surrendering the privacy of all programs.
Nice job.
Indeed, ARM is a bigger threat to Intel than RISC-V. Today, Android is popular in the high-volume categories of smartphones and tablets.
Someday, RISC-V will be popular. But unlike ARM, Intel doesn't need to buy a license for RISC-V. So it could churn out RISC-V chips whenever it felt like it. With all those facilities x86 paid for.
It would only do that when its current path fails and it thinks it can sell a MASSIVE amount of them. And then would you buy 'RISC-V' chips from them? I think they may find it hard to match AMD and they could presumably put them out PDQ if they felt there was a big market for them.
I would like to see RISC-V become popular - I think it would require the biggest kickstarter and a lot of people suddenly wising up to whats potentially going on with their data.
> Someday, RISC-V will be popular. But unlike ARM, Intel doesn't need to buy a license for RISC-V. So it could churn out RISC-V chips whenever it felt like it.
Yeah; it is called autocannibalism. Shoot your left foot so that other one become stronger.
Just as few already said: If China decided, China would do it (...whatever). Surprise, surprise: China is already doing it. RISC-V is base for their (incoming) supercomputers.
Particularly when LoongSon 3 appears to deliver significantly more performance than RISC-V at present.
While I don't believe MIPS64 can catch x86 in the near future, MIPS64 is a well understood architecture with significant room to grow performance via die shrinks and the ability to scale to match low-end x86 chips using desktop level power requirements. RISC-V may beat it for performance per watt, but this is about peak performance not just efficiency as much of the efficiency disappears as you increase cache/pipeline lengths/parallelism to obtain higher frequencies.
ARM Linux has for many years been struggling with the diversity of chip designs it is being asked to support. Because they could, companies rolled nonstandard features into their chips, hacked ARM Linux to cope and then found that they had a fork on their hands. Only slowly is the hardware ecosystem forcing itself to standardise on functionality and pull those endless forks back into the main tree.
RISC-V is starting to go the same way.
Presumably a typical lifecycle will eventually emerge, maybe along the lines of; innovate, diversify, expand, struggle, consolidate, expand...
Yep. The perceived benefit of being able to add your own instructions is only really a benefit if you control the entire software stack too.
A desktop based system running Windows or Linux on custom RISC-V silicon is almost certainly never gong to happen. Apple are pretty much the only company that could pull this off on the desktop.
Mobile could be a different story though. A lot of phone manufacturers do already run their own variations of Android, et al. It’s not impossible to imagine new processor features only being made available to the OS and drivers. Application software wouldn’t need to know as long as it targeted the core architecture.
The author did a decent job but didn't think it through.
I worked at AMD just before the Y2K era: the reason AMD had a brief resurgence was that Intel took a generation to ramp towards power efficiency - which AMD ignored and kept focusing on raw compute. The resulting faster AMD processor didn't matter though, because Intel just sliced the cost of top line processors knowing that AMD couldn't churn out enough product in its one fab to significantly change market share.
How does this matter regarding RISC-V? The issue is modern process complexity. The architecture is an important step, but arguably less important than the ability to transform theoretical performance - compute and power/heat efficiency - into reality. While AMD's fabless approach has removed the single fab bottleneck from 20 years ago, the barrier to being able to put in the engineers, test chips and know how to derive product is reinforced by modern $10M+ mask costs.
There will never be more than a handful of startups that can afford even a single tapeout, much less the stream needed to validate a top-end processor.
Or in other words, RISC-V is interesting but has zero chance of turning back, or even slowing down, the ongoing maturation of the processor industry.
"Intel bribed and coerced the big brands into not buying AMD, and this is not hearsay but a legal case that was won on paper by AMD and on practice by Intel."
While you're not wrong, you're ignoring what AMD could have done if that hadn't happened - AMD were constrained by production. What you see is coercion is what the PC manufacturers saw as a choice between the best processor with limited production and the second best x86 processor with almost unlimited production and a manufacturer prepared to do all the hard stuff around motherboards/chipsets/supporting functions.
AMD had the better CPU design at the time - Intel had (and still has) the production capacity to meet the markets needs. CPU design requires investment and smart people. Production capacity requires a level of investment that is about 10x higher again.
That is why the coercion/blackmail worked!
If I had to choose at the time between Intel giving me money, or being denied sales/highly increased prices for Intel for using AMD, I would have only one option as a computer maker: go Intel.
right now companies are buying for their data-centres more expensive, higher power using less performant Intel bases servers.. and while the excellent Intel management might have part to do with this as it reduces the TCO, for many of them it does not make sense.. yet they buy Intel!
"That is why the coercion/blackmail worked!"
No...AMD was hurt by the same thing as all the other CPU makers. Building the next generation of CPU's is expensive and one slight miss-step costs you many billions. AMD couldn't quickly ramp up production when they had superior CPU designs because they didn't have the money or the 2+ year timeframes to do it while Intel already had the money and the production capabilities.
That's not saying that Intel's tactics didn't have a measurable effect. It's just that Intel was 5 times the size and therefore had five times the resources to invest in production. And at the end of the day, making and selling complex CPU's is more important than having the best design as long as you can afford to produce the next generation.
This is why Intel's 10nm struggles is so important and why Samsung/TSMC have dumped so much money into new fabs - beating Intel to a high volume EUV process will likely cost Intel their manufacturing dominance. If 10nm had worked, Intel could have had x86/4G/5G/networking/FPGA/flash dominance with a 2+ year process lead and winning sales on al fronts. Instead they are almost back to where they were 14 years ago - a one trick x86 pony with a very vertical market and a promising competitor. Intel have committed ~$95bn to fabs for 10/10+/7nm that have not produced a lot of saleable silicon so far (10+ is just coming on-line, 7nm in late 2021).
Guess how long you can make that level of investment with no return?
I well remember the RISC anxiety at Intel when I worked there 35 years ago.
No one was under any illusion about X86 vulnerability and the perceived attraction of RISC.
Andy Grove, the founder of Intel, taught us that "Only the Paranoid Survive" and was not afraid to do whatever it took to keep the competition at bay.
Never assume that Intel doesn't recognise danger or is afraid to use its formidable powers to survive.
Exactly. Plus, the elephant in the room, is that in really x86, for a long foreseeable future, is in absolutely no danger as it is about results, not what hardware you use to produce it.
In other words, this is hardware/software geeks worrying about architecture benefits (a la OS/2) instead of being concerned about what software, what solutions, the end users actually need. Better multitasking was redundant if the kernel is not running your preferred software; greater CPU architectural efficiency is utterly and completely moot for the exact same reason.
When RISC, or even ARM, runs those financial desktop Windows apps without a rewrite or recomplie, let the rest of the world know, eh?
' Andy Grove, the founder of Intel, taught us that "Only the Paranoid Survive" and was not afraid to do whatever it took to keep the competition at bay. '
Including unlawful behaviour that Intel was eventually called out on
' Never assume that Intel doesn't recognise danger or is afraid to use its formidable powers to survive. '
Having engaged in documented anticompetitive behaviour in the past, regulators (PARTICULARLY the Chinese and EU ones) won't tolerate that kind of game again and a sniff of it (such as playing favouritism games in the supply chains - a solid go-to in the past when regulators stomped on direct tactics) will result in harsh penalties
Unlike the USA, it's a _lot_ harder to bully/bribe/coerce those regulators into backing down when they see market damage being done
"I well remember the RISC anxiety at Intel when I worked there 35 years ago."
And when Intel moved from pure x86 CISC to x86 CISC instructions decoded to µops to run on a RISC like architecture with the P6, what happened to that anxiety? Sure, Intel hedged it's bets with Itanium/VLIW but reality wasn't kind to that...
Maybe the biggest risk to Intel is China. With the US being increasingly belligerent on using weaponizing IP , there is a incentive for China to invest in its own processor architecture. If China put its weight into RISC-V then Intel and ARM may find things moving away from themselves very quickly
"Don't forget the secure enclaves in US products, and the long story of backdoors for five eyes."
Ummm - do you have any proof to link five eyes and secure enclaves?
Secure enclaves would be very useful for a number of tasks if the designers could make them truly secure. Failing to make secure enclaves secure, particularly when attackers have demonstrated novel reverse engineering approaches, doesn't automatically make them back doors or a method for five eyes to pry. Five eyes is looking elsewhere....
"Five eyes is looking elsewhere...."
To clarify, Five Eyes information gathering has been primarily about working together on large-scale intelligence gathering from SIGINT/GEOINT and sharing of information. It is a way of bypassing national laws while allowing those involved to look like they have clean hands and obtain government funding.
The personal touch of using CPU/hardware back doors to gather information is much more specialist... While that information may eventually be shared amongst Five Eyes members, it's not necessarily done in a timely manner and distribution is limited to avoid detection of the methods used.
And if you believe that these flaws are used for large scale intelligence collection (i.e.from millions of devices) and so far they have avoided detection by IPS/IDS or packet captures then I've got a bridge you might like to buy.
Plenty of security software has been proven to have backdoors, and published here at The Reg.
Is is publicly KNOWN to have backdoors on purpose? No, but think about this: the US government can demand these backdoors to be present, with a gag order, and Intel (or any other US based chip company) would have to comply.
Do I think they have backdoors? It makes sense to think that there are ways for them to hack the system. And the secure enclave is one of the best targets.
Same for China, don´t get me wrong, they could also put backdoors/difficult to find vulnerabilities.
There are, of course, many other places to put backdoors-compromises, like UEFI, etc etc.
If someone who currently buys a lot of Intel based servers for their datacentres, think Google, Amazon, Facebook etc were to seriously put money into a RISC-V chip to replace their Intel chips that could really kick start the RISC-V ecosystem.
Amazon already offer ARM based instances on AWS, so could start offering RISC-V. And Google and Facebook could swap out their older Intel kit for RISC-V if they recompiled their internally used software. But it would require someone with deep pockets to put the investment in as the returns would not come until down the line.
"But it would require someone with deep pockets to put the investment in as the returns would not come until down the line."
For the big datacentre operators - the OSes are already there, all you need to do is run up an instance of whatever software you need on whatever platform you need.
The gains for them at this point are purely around _total_ compute per _total_ watt.
As we've seen repeatedly ARM when cranked up starts drawing as much as x86, but x86 has the advantage of overall platform integration and power usage - it's not just the CPU. RISC-V is still too immature to call on this
The moment ARM or RISC-V undercuts Intel by 5-10% in a server chassis, it's going to be game over for x86 in these datacentres. At 2-5% they'll be rolled over as systems age out and might have a chance to play catchup.
Who said, or measured 2-5%?
All the Intel and Windows software remediations have slowed performace 10-25%, yet expensive per cpu software licences stayed the same. I am not sure what the slowdown did to power consumption. Besides AWS ect choose places where electricity is the cheapest.
The beauty of different chipsets is that reliability is discovered. Intel has so much undocumented junk and bloat - it is time to leave that ship. ARM also caught a cold having copied intels spec execution blob. MIPS is pure, so are some others. But again, no point in moving to a less buggy cpu is the OS has hardcoded x86 ring shit nonsense
Throughput is what matters, and IBM Mainframes on an equal die footing do well, AND have memory guards not available anywhere else.
If Trump fucks around too much over trade then China will switch to RISC-V for the mobile phones it makes for everyone, because they will have no choice. If that ever happens, they will become the leading chip designers on the planet. Architecturally there's not much in it between ARM and RISC-V (and even x86 which has shed some baggage in going 64-bit), except perhaps that you can reliably virtualise a RISC-V system and run all tests in software. But I'm sure the major ARM licensees can do this themselves or get ARM to do it for them, and even Intel has been letting "high net worth" customers request chip customisations.
The monopoly is the whole PC architecture. That's what allows a single OS image to run on just about any "compatible" box you can buy. That's why Intel and AMD can both make good money selling one of the high-value components in that architecture.
That "whole standard architecture" is what doesn't exist for the ARM, which is why AOSP being open source means very little in practice -- you have to have an Android that is provided (and maintained, or not) by whoever built the specific device. If you want to run AOSP (in Lineage, for example) you first have to wait for someone to find a kernel crack to let you load it on your phone (against the wishes of the vendor) and then you have to hope that these same people don't lose interest in your model (which they will, after a few years).
It is interesting that the commercial pressures don't seem to have forced the Android vendors to standardise their architecture.
I suspect it doesn't exist for RISC-V either and the commercial pressures might not be in the right direction there either. We'll see.
Intel and AMD don't just have a duopoly on "x86"... what they have is the whole high-end computing segment. (POWER is negligible).
If someone puts together a RISC-V chip with some incredibly useful functionality... Intel and AMD will stick it in the design of their next processors, too. x86es didn't have FPUs, now they do. Add in MMX, 3d now, SIMD, sse2, and all the other fun stuff you'll find from grep -m1 ^flags /proc/cpuinfo ... That's why Intel and AMD have remained relevant, as other architectures fell by the wayside.
Other posters have already mentioned Intel and AMD benefit greatly from a standard architecture as well, which is seriously hindering ARM's growth, and that's the *advantage* that's going to help RISC-V? Not likely.
And x86 has competition... If AMD went away, Intel would crank up prices and slow down their R&D spends. THEN they might be in a position to be disrupted by the next big thing.
Intel have been dickheads about licensing their cores into architectures that would suit embedded machines, such as cell phones, tablets, etc... This leave it to beaver(ton) attitude has surely cemented their enormous success in the mobile market.
They aren't the only moghuls on the hill. Not all ARM licensees are created equal, so while some have to struggle to minimize the royalties they have to pay the japanese banks, others can put as many as they want on an SOC without affecting the bottom line at all. A more flexible arrangement permits using say an intelligent component in a place where you might think a dma controller or iommu might live. Distributing io resources in this way permits much higher io bandwidth with much less power, greater security. and a better design.
One of the promises of a truly open architecture is that designers are not hampered by penny-pinchers. There have been *open* designs in the past, for example Sun threw one edition of SPARC over the wall, but this isn't really *open source*, it is *abandonware*. Open source is all about the future.
If every CPU vendor could extend the Risc-V instruction to his liking, we would have an incredible software mess .
Look, I work in security and one of the major reasons ARM processors are so hard to lock down and boot securely (most hardware manufacturers skip the start entirely) is that there may be very little in common between processors families from the same CPU vendor, let alone different CPU vendors. As far as I am concerned, TrustZone is vague suggestion to CPU vendors to do something. Each CPU vendor implements TrustZone differently.
Every part number may have to setup differently and the software has to be customized differently. And a little bit of 'different' is the difference between secure and not-secure. The kernel patches are exhausting to maintain.
And that is just about security.
ARM is trying very hard to fix that by shipping its own version of software (e.g. mbed) but that is a hard sell: companies are not willing to be tied to a single vendor of anything, even free.
I can see China using Risc-V to create a whole class of instructions that give them a competitive advantage. The software stack may be decider, though.
In the 1980s I remember two types of chips that were going to "revolutionize" science and engineering applications: One was RISC based - The other was the Transputer. I spent a bit of time with them both, and we even bought expensive kit that used them. I think that they died because neither could run off-the-shelf WinTel/DOS business/general software for (clones of) the IBM-PC.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
