China To Publish Policy To Boost RISC-V Chip Use Nationwide (reuters.com) 23
AmiMoJo writes: China plans to issue guidance to encourage the use of open-source RISC-V chips nationwide for the first time, Reuters reports, citing two sources briefed on the matter, as Beijing accelerates efforts to curb the country's dependence on Western-owned technology.
The policy guidance on boosting the use of RISC-V chips could be released as soon as this month, although the final date could change, the sources said. It is being drafted jointly by eight government bodies, including the Cyberspace Administration of China, China's Ministry of Industry and Information Technology, the Ministry of Science and Technology, and the China National Intellectual Property Administration, they added.
The policy guidance on boosting the use of RISC-V chips could be released as soon as this month, although the final date could change, the sources said. It is being drafted jointly by eight government bodies, including the Cyberspace Administration of China, China's Ministry of Industry and Information Technology, the Ministry of Science and Technology, and the China National Intellectual Property Administration, they added.
Intel (Score:2)
And so we see that the protectionist policies that ban China from acquiring decent technology really just serves to seal Intel's fate. It's also a market Arm would like to be in, but they're still competitive, so stand a chance of innovating out of trouble.
Intel was failing anyway, so this wasn't the cause of it, but missing out on that particular market sure won't make it easy for them to recover. Meanwhile, Chinese foundries will be minting chinese versions of Risc-V and chinese buyers will be buying the
Re: (Score:2)
Re: (Score:1)
The protectionist policies, in my opinion, had little to do with China's push for RISC-V. The reason I think that is because China has, at least since Xi (I-AM-not-a-petty-little-dictator) Xinping, been working to wean itself off Western and especially U.S. controlled technology. Also, that leech, the CCP, needs something they can promote to the Chinese to claim they aren't just a bunch of worthless parasites.
All the protectionist policies in the U.S. do is show that la Presidenta understands nothing about
Re: (Score:2)
>> from acquiring decent technology
Its just the most cutting-edge technology. They can still get decent stuff.
Meanwhile, Intel is heavily involved in RISC-V;
https://www.intel.com/content/... [intel.com]
RISC-V performance (Score:2, Insightful)
Re: (Score:2)
>> RISC-V and its successors as an architecture perform better than x86 and ARM
Where are you seeing that? The ARM architecture is based on RISC principles.
Re: (Score:2)
Thats like saying Windows and Mac are also based on the same principles (GUI based OS).
Re: (Score:2)
No, it isn't like that.
Re: (Score:2)
Re: (Score:2)
You made your claim with no evidence, so all I have to do is disagree.
Meanwhile the original claim was that "RISC-V and its successors as an architecture perform better than x86 and ARM". Also no evidence, and ARM is in fact RISC.
Re: (Score:1)
Nothing says "State of the art" than 1980s chip design!
I really think RISC-V is overblown. An open CPU standard is a good thing, but using an ABI that's only efficient using one specific CPU architecture that was relevant 40 years ago solely because 100,000 transistors was considered a lot is... weird.
Apple's done sterling work making ARM work for non-embedded applications, but very little of that has anything to do with RISC.
Re: (Score:2)
Maybe, although I think raw computational performance x86, or rather AMD64, will continue to win out for now. The basic concept of taking an intermediate bytecode like AMD64 and converting that to extensive amounts of microcode seems to be pretty unbeatable for a lot of tasks. Not so much on energy performance, but even there it's not terrible.
I'm sure RISC-V will come to rival ARM for both though. With big backers and huge amounts of R&D pumped into it, can ARM and its partners really compete? History
Re: (Score:2)
This depends entirely on the implementation. RISC-V is an ISA.
Some boards are on par, most are simple, slow, and cheap.
Explaining Computers has some great videos comparing performance of various boards. Most are slower than a Pi.
I have several RISC-V boards but none of the expensive ones. Raxxa (sp?) has a fast dev board now for about $500. Mine are like $79.
Re:RISC-V performance (Score:4, Informative)
RISC-V is probably going to overtake ARM and MIPS for low-end systems. A lot of embedded stuff could easily switch to RISC-V. Being royalty-free makes it attractive compared to ARM, and it's a bit cleaner than (also royalty-free) MIPS.
However at the high end, I think that's just wishful thinking. It's up against OpenPOWER and SPARCv9, which are both similarly royalty-free, and AArch64 which is a better architecture for a superscalar multi-issue design.
Dealing with SPARC first, there are implementations of it like the ESA's LEON, used in aerospace, but going forward I don't think it will be popular. No-one likes branch delay slots, register windows, spill/fill traps, needing to scrub hidden registers, etc. Sun bet on Berkeley RISC and it looked pretty good initially, but in the long run it turned out not to be such a great decision.
OpenPOWER/PowerPC is starting to show its age. IBM were experimenting with out-of-order designs earlier than a lot of people, so PowerPC avoids problematic things like branch delay slots, instructions that update some but not all condition codes, etc. However, the immediate value sizes chosen don't work so well with 64-bit systems and big address spaces, the dedicated branch unit registers (LR and CTR) end up being a pain to work with, the eight sets of condition codes don't get utilised enough to really be worthwhile, and RLWIMI/RLWINM use up too much of the instruction space. That's not to say it's bad as such, it's just that if you were designing it today, you could do better for how CPUs are used.
And then there's AArch64. They've obviously taken a good look at what's gone before, and learned from everyone else's mistakes. It eliminates a bunch of less-useful ARM features so the registers can be doubled. It gets rid of instructions that update some but not all condition codes. It has a context-sensitive constant zero register like PowerPC. It covers the most common bit field manipulation instructions without squandering instruction set space. It doesn't bother with scalar FPU registers at all, there are only vector registers. It lets you calculate a PC-relative address with +/-4GiB reach in just two instructions. It gives you just enough addressing modes to cover the important cases (register with byte displacement, register with element displacement, PC relative with word displacement).
RISC-V doesn't have enough useful addressing modes. You always end up needing to use too many instructions for address calculations, filling up your issue slots and keeping the ALUs busy. The lack of an actual condition code register means you need too many read ports on your integer register file in a superscalar design. The compact instruction encoding is a context-sensitive compression scheme that greatly complicates decoding (Thumb2, MIPS16 and PowerPC-VLE are all far simpler to decode).
The best-performing RISC-V implementations are the ones from Huawei that use up all the instruction space extension areas adding addressing modes that the base architecture should have included all along.
It's telling that the Libre-SoC project switched from RISC-V to OpenPOWER due to the issues encountered while trying to create an out-of-order superscalar RISC-V implementation. (It's sad to see that project seems to have stalled due to the main contributor's mental health issues.)
Re: (Score:2)
How do other architectures compare, eg Alpha, HPPA, IA64, Elbrus etc?
Re:RISC-V performance (Score:4, Informative)
Briefly, Alpha and HP-PA are more cases of "you'd do it differently in hindsight" like MIPS and SPARC.
Elbrus is conceptually similar to the Transmeta Crusoe - it's a 512-bit VLIW architecture that uses binary translation to run x86 code. It doesn't seem to be getting great clock speeds, being stuck around 1.5GHz for the available parts. I think they're compromising on everything in order to maintain x86 compatibility. They lack the resources to make a competitive conventional x86 clone, so they're taking an approach that's less work, but unlikely to match performance. (Note that internally, Libre-SoC also uses a VLIW architecture, but it does the translation from PowerPC to internal VLIW in its instruction decoding front-end, not as a binary translation step.)
IA64 is an interesting one. It actually started as EPIC at HP when they were looking at their options for an eventual successor to HP-PA. The project was transferred to Intel because they felt they lacked the resources to be competitive in that space. The engineers felt that classic RISC designs were saturating at one instruction per clock cycle. IBM were working towards multi-issue superscalar designs where the CPU manages dependencies between instructions automatically, but the HP engineers felt this would add a lot of complexity to the CPU, and hence increase power consumption, etc. You'd also end up with a situation where only certain combinations of instructions could be issued simultaneously, so the compiler would need some awareness of the microarchitecture if you want to maximise performance, but the CPU would still need to be able to deal with less than ideal sequences of instructions. There were already DSPs with explicitly parallel instruction sets, but they tended to be rather inflexible.
The basic idea of EPIC was to push the bulk of the work of organising instructions in groups with no dependencies to the compiler so you could have a simple in-order CPU design while still being able to issue multiple instructions simultaneously. Instructions are bundled into packs of three, and while it's more flexible than an explicitly parallel DSP or a typical VLIW processor, there are still limitations. The trouble is, in real life, doing this kind of optimisation is difficult. Itanium processors performed very well on hand-tuned code written in assembly language, but compiled code written in high-level languages never performed particularly well. Then you had to re-tune your code for each significant change in microarchitecture. You can't really do this if you're using compiled commercial off-the-shelf software without source code. They told us that everything would be Java or .NET CLR byte code soon, and the JIT compilers would deal with the microarchitecture changes for us, but JIT compilers ended up being even worse at the complex optimisations you needed because they need to run on-the-fly.
IA64 also has register windows, but rather than using spill/fill traps like SPARC or Hyperstone E1, it automatically spills and fills in the background. This can cause unpredictable latency for register operations if you're unlucky. There are a bunch of other quirks as well. IA64 kind of makes sense if you think of it as an overgrown DSP, but it was never going to be a great general-purpose CPU architecture.
Now the HP engineers weren't completely wrong about out-of-order CPUs - they do need a lot of silicon and run hot. The IBM PowerPC 970 (aka G5) and POWER5 used a lot of power and ran very hot due to the out-of-order functionality. The Cell (PlayStation 3) and Xenon (Xbox 360) used the same execution units but with pure in-order designs, and ran much cooler. Of course, they also perform very poorly if the code isn't tuned for the microarchitecture.
Despite being one of the first companies to start delivering out-of-order CPUs, IBM keeps trying to get away from them. I already mentioned Cell and Xenon. The z9 mainframe architecture was purely in-order and performance suffered, so they eventually switched back to an out-of-order architecture in later mainframes. POWER6 is mostly in-order (only the FPU is out-of-order), and it has poorer per-core performance than the fully out-of-order POWER5, but tries to make up for it by packing in more cores, which they can do due to the lower power consumption.
Re: (Score:2)
Interesting, thanks for the insight.
Re: RISC-V performance (Score:1)
Dogfooding (Score:2)
This is good.
Having wide usage will promote more rapid development of capabilities.
An open source ISA is inevitable. It should be noted that some implementations have undocumented instructions that are starting to be used for license management and who knows what else so it's only a necessary precondition, not a panacea.
But Apple infamously has undocumented hardware backdoors too, so it's hardly unique.
A trustworthy OEM can use a trustworthy fab and create a trusted platform. In a free market.
Re: (Score:2)
If anything thi
*Sounds* Cool, But.... (Score:2)
But it's important to remember that, while the core of RISC-V is Open Source, it also expressly provides for extensions -- the ability to add custom instructions and silicon to help optimize whatever application they're designing for. A media-focused RISC-V SoC could have custom instructions to, for example, take apart DCT macroblocks. [wikipedia.org]
RISC-V implementers are not required to Open Source, or even disclose the existe