Live data from Hacker News

Open-source chip RISC-V to take on closed x86, ARM CPUs

computerworld.com.au

131–140 of 157 posts

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#131

Earlier quoted context omitted.

> In other words, if you want competitive RISC-V chip, some company must spend hundreds of millions to develop their own RISK-V chip architecture... I wonder if a country like Russia, wanting something that they can deploy without worrying that the NSA & Intel are cooperating on state spying, will eventually try and take something like this and bootstrap a domestic semiconductor line of business.

Russians have build their own processors for decades. They have used SPARC instructions sets and they also have their own VLIW Elbrus 64-bit ISA and processors are made by TSMC for 28 nm process. It has Intel x86 comparability with system-level dynamic translation. Just adopting new Instruction Set Architecture (ISA) is not going to help to magically boost semiconductor business.

The Russians have Baikal (T1), the Chinese have Loongson (3A/B). Both are MIPS based. Unfortunately, even though both announced that there will be consumer hardware available over a year ago, it did not happen. So I'm not too optimistic regarding RISC-V.

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#132

Earlier quoted context omitted.

> RISC-V is amenable to a wide array of microarchitectural decisions As is ARMv8. Applied Micro, Broadcom, Cavium, Huawei, Nvidia, AMD, Samsung and Apple are all architectural licensees with radically different microarchitectural implementations. For example, Nvidia is Transmeta code-morphing style implementation. Also, Intel and AMD continue to innovate in the x86 space. At this date, RISC-V has no fundamental advan…

NVIDIA's Denver is a feat; I think that if it says anything, it's that ARM's instruction encoding is deficient. AArch64 instruction encoding is less dense than AMD64, and completely lacks compressed instructions (like Thumb). To NVIDIA, it made more sense for them to write a realtime binary translator for an internal ISA which is clearly enabling their microarchitecture more than ARM is. AMD and Intel spend more mone…

> just imagine how much of their chips is just decode.

This article has some annotated pics of AMD Ryzen 7: http://wccftech.com/amd-ryzen-architecture-detailed/

Based on these photos, I’d estimate instruction decoder takes about 10% of each core, and about 7% of the whole chip.

For Intel I was unable to find similar pics, but my estimation is 3-4% of the chip area. The instruction set is the same; the complexity should be comparable. But most Intel chips have like 50% of the area occupied by integrated graphics.

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#133
post #79
post #72

I see on this thread a lot of people getting blind-folded by the "open-source" term attached to the headline of this article. First of all RISC-V can mean more than one thing: it can refer to the architecture, which is in fact open and free to use, or it can refer to the implementation of the same architecture, which will not be necessarily free or open source. For example, check the so claimed SiFive company which w…

> You don't need to be completely tied to ARM. The point is that if you want to use the ARM ISA you have to pay ARM. Not so with RISC-V. Anyone is free to fab a RISC-V chip without paying royalties.

I believe this is incorrect. It seems that there is lots of confusion related to RISC-V.

Only RISC-V ISA and some simple (and relatively inefficient) architectural designs are free and without royalties.

But when someone develops efficient RISC-V microarchitecture they are not going to provide it free. If some company develops RISC-V based architecture that is competitive with AMD,Intel or ARM, they are going to ask good money for it.

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#134

Earlier quoted context omitted.

NVIDIA's Denver is a feat; I think that if it says anything, it's that ARM's instruction encoding is deficient. AArch64 instruction encoding is less dense than AMD64, and completely lacks compressed instructions (like Thumb). To NVIDIA, it made more sense for them to write a realtime binary translator for an internal ISA which is clearly enabling their microarchitecture more than ARM is. AMD and Intel spend more mone…

That's a good point about Nvidia adopting RISC-V. I didn't know that but for their application it's a good idea. I'm not a Denver fan and at this point I think we can safely say Code Morphing has been tried. However, I wouldn't conclude that Denver means that ARM's instruction encoding is deficient . The optimizations that Denver provides would be impractical in any ISA. Moreover architectures are meant to be impleme…

Yeah, I agree that condition codes (and offset loads) are features, not bugs in x86 and ARM; also ARMv8 shows an effort to reduce the number of instructions which can respond to condition codes. Chris Celio has talked about some interesting ways to make up for the lack of these two features, and it seems quite convincing. If you're using the compressed instruction set (which all desktop/workstation type RISC-Vs and most microcontrollers support), then the decoder can implicitly fuse the add and the load, or various forms of conditions, and treat them as a single operation. AFAIK, the compiler backends already try to order the instructions to exploit this.

And yeah, I'm not utterly convinced by any argument about "purity" in ISAs, but in this case there's no question that it has helped a wider variety of people develop interesting and competitive chips in less time.

ARMv8 is a considerable step up in many ways from ARMv7 and earlier, but AArch64 retains user mode compatibility with ARMv7, which means that the more different AArch64 is, the harder it is to implement. In this way, every ARMv8 is also an ARMv7 (of course, sans all the supervisor/hypervisor instructions).

In many ways I like x86, and for the most part I like the vendors. I love that x86 has given Intel and AMD the opportunity to innovate so dramatically.

But just for a moment, imagine that instead of just Intel and AMD, the whole industry can put that same flag in the sand and have just one general purpose instruction set family.

You could have an 8088, a Cortex M0-M4, an ARC, an AVR, a PicoBlaze, a MicroBlaze, a SuperH, a MIPS, a Power, a LatticeMico, etc. but many of these architectures survive today because of a differential in licensing cost with ARM, not because of any technical prowess (and some of them are better in some ways, don't get me wrong!). Imagine that for the vast majority of these people, one ISA family would suffice, and the whole market could compete to bring new performance, power, and cost profiles to each market served by these cores. Then imagine that that same industry can easily start scaling up their designs to compete in the application processor market, and then perhaps in the workstation and server market, then perhaps the HPC market.

Just a thought though, I can't predict the future with any degree of certainty. I just think RISC-V is a whole lot more practical than you might think, just perhaps for people who have slightly different values from you (or from me, for that matter).

I think there's a lot of promise in that it is becoming the standard teaching ISA for universities throughout the United States, Canada, India, and elsewhere. If there is a generation of new computer engineers coming out of school with research-grade FPGAs in their hands, and their thesis work can be commercialized in a matter of months rather than years, then you can imagine that there will be huge commercial output in RISC-V whether it catches on now or then.

I think that's when it will start to seem more attractive to you, there will be more investment in it and you can see some clear, immediate benefit aside from cost savings and licensing flexibility.

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#135
post #107

Earlier quoted context omitted.

I am aware that they exist but it's not like companies are going to actively invest in devices for the end consumer purely based on RISC-V.

From where I'm standing, it looks like you're shifting goalposts: > > RISC-V is thrown around like if it's an already working CPU but it is not (Evidence of existing CPUs provided) > I am aware that they exist but it's not like companies are going to actively invest in devices for the end consumer purely based on RISC-V.

My point is, you can't get those existing CPUs for free.

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#136

Earlier quoted context omitted.

NVIDIA's Denver is a feat; I think that if it says anything, it's that ARM's instruction encoding is deficient. AArch64 instruction encoding is less dense than AMD64, and completely lacks compressed instructions (like Thumb). To NVIDIA, it made more sense for them to write a realtime binary translator for an internal ISA which is clearly enabling their microarchitecture more than ARM is. AMD and Intel spend more mone…

> just imagine how much of their chips is just decode. This article has some annotated pics of AMD Ryzen 7: http://wccftech.com/amd-ryzen-architecture-detailed/ Based on these photos, I’d estimate instruction decoder takes about 10% of each core, and about 7% of the whole chip. For Intel I was unable to find similar pics, but my estimation is 3-4% of the chip area. The instruction set is the same; the complexity shou…

I'd add to that Agner Fog's early report on Ryzen:

http://agner.org/optimize/blog/read.php?i=838

The micro-op cache size increased to 2048 from Intel's 1536 μops. His testing shows 5 instructions per clock cycle up from Intel's 4. There are limits to the ILP a scheduler can find; more in one area means more demand in another. This is no mean feat for AMD to pull off.

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#137

Earlier quoted context omitted.

There are a number of things that make RISC-V different from OpenSPARC. One is that OpenSPARC is not a very scalable design, it could probably only ever work in servers and workstations, and workstations are essentially a monoculture. Another reason is timing: manufacturing processes have effectively stopped yielding performance and power gains as the fundamental constraint (distance between components on chip) doesn…

> RISC-V is amenable to a wide array of microarchitectural decisions As is ARMv8. Applied Micro, Broadcom, Cavium, Huawei, Nvidia, AMD, Samsung and Apple are all architectural licensees with radically different microarchitectural implementations. For example, Nvidia is Transmeta code-morphing style implementation. Also, Intel and AMD continue to innovate in the x86 space. At this date, RISC-V has no fundamental advan…

> and your advantage is that you're wearing organic cotton.

Open source hardware is not like organic cotton, it's more like having the kitchen, the tools and the ingredients to cook your own awesome meal vs going to a restaurant but never able to make any food yourself.

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#138
post #128
post #122

Earlier quoted context omitted.

A lot of the interest behind open ISAs like RISC-V isn't from a cost perspective, because most people recognize that the cost differences are negligible. They want to avoid the Intel scenario, where a company controls an ISA that industries depend on, and can force their ideology on implementing silicon for whatever ends they want. ARM, being proprietary and controlled by the company can do the same. If you want a sp…

This is one of the few sensible comments in this thread and explains exactly why RISC-V is important.

Touche!

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#139
post #53

RISC-V is atleast 10 years away from competing with x86 and ARM. It is just now getting to a point where it can power arduino class hardware. Long way to go... but looks promising.

The Freedom E310 chip in the HiFive1 board is shipping today and is already competitive with embedded ARM: https://www.crowdsupply.com/sifive/hifive1/#comparisons . It's comically faster (i.e., 100x) than the AVR chip in the Arduino Uno board, but the similar form factor makes it cheap & easy for early adopters to play around with. I'd bet that within five years a good proportion, even the majority, of Amazon & Googl…

The big problem with the E310 is that after you've prototyped something and want to design a custom board, you've got a much more difficult task ahead of you. The AVR needs a significantly fewer number of support chips, as it has onboard flash, has pretty large voltage tolerances, has adcs, etc. It gets even murkier when you start considering boards from other companies like STMicro, which have Cortex-M7s, are competitive in performance and have boards that go for half the cost of a hifive1. It's interesting if you want to poke around with Risc-V for the purpose of poking around, but i wouldn't want to start a serious project based on it at the current time.

Re: Open-source chip RISC-V to take on closed x86, ARM CPUs

#140

Earlier quoted context omitted.

There are important people at Microsoft who basically get very confused about what "x86" or "arm" means. There was a contingent that decided allowing third parties to port win32 apps with a recompile was off the table (despite it being very doable - just look at explorer or notepad running on surface rt), and to this day whenever many MS folks make public statements about windows on arm they sound hopelessly confused…

Important people don't know what underlying hardware their software runs on? I mean it's not that hard to figure that out... I hope they're not just parroting what others tell them.

I could never figure out if it was stupidity or willful ignorance. Probably elements of both.

So I quit that company.

Post reply on HN