x86 is the past, but ARM is proprietary. RISC-V is the open source answer (there is SPARC but it's much older and never gained enough traction + Power/PowerPC became open source too but it's also not a modern ISA)
AMD had their own non-x86 instruction set once upon a time. I remember using it in the mid-90s in some embedded thing it worked, but as a developer once there is a compiler all instruction sets are hidden so I can't comment.
The article says it got designed in to a bunch of laser printers, but not which ones.
There were a bunch of RISC designs floating around then. The ones still relatively familiar are those that were being used as workstation CPUs -- SPARC, MIPS, POWER/PowerPC, DEC Alpha. But there were also the 29k, the Motorola 88000, and Intel i860. Probably others I'm not remembering.
If you mean amd64 it's the 64 bit extension of the x86 instruction set. It's just named after AMD because they were the ones introducing it while Intel was instead working on the arguably failed brand new 64 bit-only Itanium architecture. In the end they "went back" and picked up amd64 too that's why multiple names exist: x64, x86_64, amd64.
And there were/are some differences between AMD and Intel 64-bit x86 once you get into the details (and indeed between various extensions on a given microarchitecture). x86_64 (or x86-64), ugly as it is, is probably the best way to refer to specifically 64-bit x86 at a non-vendor-specific level. Just x86 works for a lot of purposes too.
To be precise, RISC-V is an open architecture. (Which the hope is will be more successful than cases where the implementation was mostly take it or leave it open implementations/models.)
They have many op codes that bloat the instruction set, that need to be broken apart to fit into a multi-scalar design. This is over head that takes of silicon space. This is especially painful with multi-core designs since each core needs this.
They may have memory models that make guarantees that are insignificantly secure or impede optimisation.
There is something about condition codes vs explicit checks that made speculative execution difficult. I don't recall the details about this one.
I don't dispute that legacy cruft is a problem, but I don't see how "not modern" (which still isn't defined) necessarily means legacy cruft. ARM or MIPS aren't especially recent in ISA terms, but I think most would agree each has less cruft in it than x86, for example.
MIPS has cruft in things such as architectural load and branch delay slots. Helped in the first, simple, implementation but just (worse than) useless baggage after that. Instructions that trap on overflow too. Helped on some programs on simple implementations, but on an OoO implementation just the mere existence vastly complicates the pipeline even if programs don't use them.
With Arm, the bitmapped arbitrary set of registers load/store/push/pop is cruft that helped the first simple implementations (especially ones without icache). Same with the predication on every instruction. It uses a ton of instruction encoding space, doesn't get used much outside of conditional branches, and in modern implementations branch prediction is usually so good that you don't want to predicate instructions -- certainly not several in a row. Arm is deprecating IT* predication in Thumb2 now also. Also PC as a general register is harmful to modern implementations. ANY instruction with r15 as the destination can change control flow -- load, add, xor .. whatever. At least you can tell at instruction decode time, but it needs both opcode and dst register to tell.
Aarch64 fixes most of the traditional Arm cruft (everything mentioned above) and is a pretty good ISA. The main faults are that it still has condition codes (no other high performance ISA designed after 1990 does), insistence on the purity of 4-byte instructions only (Thumb2 showed that the benefit is well worth the small cost), and just the simple fact that there is TOO MUCH of it and no subsets allowed, making it impractical for small CPUs e.g. microcontrollers.
The instruction set architecture (ISA), is open source, which means there is a minimum amount of instructions (think assembly instructions) that people can use to target/implement the functionality of that CPU architecture, similar to x86, x64, ARM or POWER.
The big thing that is different than other "open" ISAs in the past is that there is an open specification / standard that isn't encumbered by restrictive licensing or patents. This allows software (think compilers) and hardware designers to target the ISA without fears of getting sued for using the ISA or having to have restrictive licenses.
It can also be simple to implement, but there are commercial, highly performant cores available too, for example, sifive.
People get excited because "it's open source". Except it's really not as only the instruction set is "open source" and even that doesn't really mean much as interfaces have dubious copyright protection. Still, it promises a cheaper alternative to ARM because of the theoretical reduced licensing costs from the trademark name.
The other salient is political: ARM, x86, etc are Western aligned while RISC-V is attractively nonaligned. ARM's government mandated Chinese subsidiary went rogue against ARM itself which endangers the use of ARM chips in China. RISC-V hedges against this risk for China.
> because "it's open source". Except it's really not as only the instruction set is "open source"
There are multiple cores available under permissive licenses all the way through to ASIC or FPGA implementation. There is also quite a bit of academic research happening now, which may not be formally open source but is shared and published.
> even that doesn't really mean much as interfaces have dubious copyright protection
There's a big difference between "given a license to use this" and "might not get sued, or at least might win if we do, if we use this without permission."
Basically, all the same arguments you've heard in favor of open source in general.
Today, board developers have to pay if they want to license ARM. And with recent developments coming out of ARM, the price to pay is going up by a lot, very soon. If RISC-V can develop to the point of more or less parity with ARM, then that will enable cheaper products that are just as good, equally priced products that are better, or equivalently positioned products that return a better profit to their manufacturers (which is good for you even if only indirectly—better profitability means easier entry for competition, better financial stability behind whatever ecosystem you're buying into, lower chances of companies crashing and leaving behind unmaintainable e-waste, etc).
IMO, reduced rent-seeking is good for everybody no matter what sector. I want more collaboration and less human effort/ingenuity/resource dissipating to waste heat. Open source makes Moloch cry.
SiFive is pretty nice, they have a very attractive offering and will probably make the transition much easier for folks who are on ARM offerings.
IMHO the biggest issue right now with ARM is the uncertainty surrounding it, their Chinese subsidiary went rogue and they are trying to raise prices significantly in preparation for a sale or IPO.
This emphasis on price is a bit misleading imho. Arm had revenues of less than $800m in the last reported quarter and there were 8 billion Arm cores shipped. So that’s less than 10c per core. And that’s not the fee for the ISA it’s the total cost of licensing the core. So if you’re expecting a big cost saving on the end user price from the ISA being open source then you’ll be likely to be disappointed.
More important is that more competition may lead to better designs and the RISC-V gives more freedom for firms to innovate.
$745m, their highest ever. $2.74 billion for the year. Not chicken feed.
As for the 10c a core on average, there will be billions of 1c/core royalties for things you don't even realise have a CPU in them, and tens of millions of much much higher royalties on the kinds of chips that go into smartphones and SBCs. Maybe as much as $10 a chip?
No your numbers are wrong (1) by an order of magnitude. The cost per smartphone equivalent CPU will be around $1 and that’s for the whole design not the ISA.
[1] tens of millions is wrong and it clearly not true that Arm charges ‘as much as $10’ for an SBC that will cost $40 retail.
Not on average, obviously. But most phones sold are low end. I bet Arm gets a lot more than $1 from ARMv9 Snapdragon 8 gen 1/2 with the very latest cores.
So you’re complaining that Arm make more than a dollar on the latest multi core CPU on an absolutely top end smartphone that retails for probably near $1000. Seems like a perfectly reasonable deal to me!
Who is complaining? I'm merely pointing out that not all those cores are licensed for 10c each. Many go for a lot less, some go for a lot more. It's been a struggle but I'd glad we agree on that now.
Now we can discuss what the scope is for RISC-V companies to charge for cores or chips.
Jim Keller said yesterday that in 2024 his company will have an 8-wide RISC-V core, on a chip, that performs on a par with Apple M1/M2 and Zen 5.
Performance gap between RISC-V and x86 down to zero.
I suspect that in 2024 he means expensive shuttle run chips. But working and able to be demoed. Mass-production chips are usually 12-24 months later.
For CPU developers it's permissionless. To develop a new Arm chip you need to negotiate a license up front from that company. To develop a new x86 chip, well, forget about that. Intel won't license x86 for any amount of money. For RISC-V, download a BSD-licensed core from github, or grab the BSD-licensed specs and write your own. No need to ask anyone's permission, and no fees to pay.
Somehow I doubt that they're much more friendly about it. At a technical level, though it's an interesting question; I'm actually pretty curious to know whether you could make a processor that's pure amd64 without the legacy 32-bit mode... I suspect it would be a fair bit of work from the software side to support that, but it's probably possible. But I'm no ISA designer:)
Edit: Or is 32-bit x86 so old that you could "just" clone it because all the patents have expired?
So it means the entity wanting to develop an amd64 processor will need licenses from both Intel and AMD. I don't see how this could practically happen through.
I don't know how far you'd get with an amd64 core that didn't support x86. I mean you couldn't run Windows on it. You probably could run Surface as it's almost certainly legacy-free as it can run on ARM.
If you are a CPU developer either you need to use x86-64 for compatibility, or you can use whatever you feel like it. Risc-v is still good though because the fact that others are using it mean you don't have to build a compiler for your new one. (eventually you may want to work on the optimizer)
Open IP, you can make a chip without paying any licensing fees. On a desktop or laptop CPU, or even a phone, you probably don't care that $10 of the cost goes to licensing. But on internet-of0things processors that are aiming to be under $10 or even $1, licensing becomes a big pain point.
On a more general level, the idea of RISC is to have a very very simple instruction set instead of a thousand 'clever' features that are mostly underused, so that you can optimize your software project out the yin-yang if you're more concerned with pure performance than versatility.
I really like Pine64, this is really nice to see! The coolest part IMHO is they are including an PCIe x1 slot, right on the board.
I feel like RISC V has really started to pick up momentum over the last year or two, which is awesome to see. There have also been a bunch of tiny RISC V softcores for FPGAs too.
They list an NVMe SSD adapter board with PCIe x4, I wonder if that works together and can be booted from? I know with my RPi getting away from SD card boot made a huge difference.
While looking for the successor to Raspberry Pi's, my interest revolves around how open source the drivers are and whether they're upstreamed or not. I have no interesting in a board, no matter how cheap, that will be stuck on some ancient, unmaintained kernel version.
It looks like they're off to a good start but appearances can be deceiving. Kernel is a fork and who knows if it's missing anything. It's all pretty new so I wouldn't expect it in mainline. GPU (Imagination BXE4-32) also seems to have a pipeline towards upstreaming.
> Kernel is a fork and who knows if it's missing anything. It's all pretty new so I wouldn't expect it in mainline.
Yeah, it's at an awkward point right now where you wouldn't expect to have drivers upstream, so it's harder to predict whether it will get where we want it.
how much work/how long will it take before the kernel is not a fork/everything is upstreamed. 12 months?
also, on my raspberry pi i at least stood a chance of running a headless chrome for some silly scrape job i had. RISC-V pretty much guarantees that's not the case, right?
RISC-V is unlikely to have native support from proprietary applications, if that's what you're asking. That said, I would be shocked if the open source chromium doesn't run on it either now or soon.
RISC, ARM, whatever, just give me more cores and memory (ECC please!), maybe even better NICs, and keep it sub $300. AMD Ryzen is a really solid platform right now that's hard to beat with a cluster of 4GB SoCs.
Since most of us don't design CPUs or micros, does it matter much whether it's RISC-V vs ARM? In other words, is there any way to contribute in the RISC-V space and gain an advantage? I can see how it could work out for Intel or Nvidia but for an end-user I can't see how I would jump away from the architecture I've spent the last 10 years on.
To the end user, it won't matter much either way, because most open source software already compiles and runs just fine on RISC-V; there are plans for projects like Chromium and Android to fully support RISC-V. RISC-V is on a trajectory to "just work".
However, what does matter is that the RISC-V ISA will be cheaper and more flexible for device manufacturers to use. That's why it's superior to ARM and has already partly supplanted it for smaller chips (there are over 1 billion RISC-V chips in use already).
Technically they are close enough that you mostly don't care. Many RISC-V core customers say they ended up with using less silicon area / cost / energy usage at the same performance level. Arm proponents say their code size is a little smaller in 32 bit -- RISC-V is definitely significantly smaller code than Arm or x86 in 64 bit.
But we're only talking 10% or 20% difference here.
The big difference is Arm is owned by a single company that can and does change its contract terms and prices, sues its customers, obsoletes old stuff at will etc.
RISC-V is managed by a non-profit that is steering along a path agreed by its hundreds of member companies, but can't and doesn't stop anyone from adding custom stuff as long as they stay compatible with the core ISA. There is a promise to only add capability over time, but keeping compatibility with the core 32 and 64 bit ISAs published in 2015 and ratified in 2019 ... forever.
There are already a dozen or more companies competing to design the best and most competitive and compatible RISC-V cores and chips, and that's only going to increase. If the company you are using falls behind or raises prices or goes out of business then you can just switch to another -- as long as you didn't drink their proprietary extension cool-aid (it can be very tasty).
The current limits of the RISC-V ecosystem are (I currently have one sitting in front of me, and ssh access to the other):
- Sophon SG2042 64x 2.0 GHz OoO cores similar to Arm A72, each core with a 256 bit vector unit, 64K L1 cache, 1M L2 (shared per 4 cores), 4M L3 local to a cluster of 4 cores, with the other 15x 4 MB L3 accessible via NoC at ~half the local bandwidth. 32 lanes of PCIe gen 4. https://www.sophon.ai/product/introduce/sg2042.html
On the other hand, existing GPU company Think Silicon spent six weeks in October/November 2019 adding some GPU instructions to RISC-V, showed it running in an FPGA at their booth at the December 2019 RISC-V Summit, and are shipping the resulting product now:
I'm curious about standardization of the rest of the system - the way x86 operating systems more or less work on any x86 machine, whereas ARM seems to basically require a device-specific OS image for every single device. Is there any work going into addressing that and making RISK-V more like x86 and less like ARM systems?
Yes. However the board is different and offer different features. I'm quite interested in seeing a complete comparison and wonder about exactly who will contribute upstream support for what and how that's shared between them. It's all very unclear to me.
73 comments
[ 3.3 ms ] story [ 147 ms ] threadhttps://en.m.wikipedia.org/wiki/AMD_Am29000
The article says it got designed in to a bunch of laser printers, but not which ones.
There were a bunch of RISC designs floating around then. The ones still relatively familiar are those that were being used as workstation CPUs -- SPARC, MIPS, POWER/PowerPC, DEC Alpha. But there were also the 29k, the Motorola 88000, and Intel i860. Probably others I'm not remembering.
This particular CPU is not open source.
They may have memory models that make guarantees that are insignificantly secure or impede optimisation.
There is something about condition codes vs explicit checks that made speculative execution difficult. I don't recall the details about this one.
MIPS has cruft in things such as architectural load and branch delay slots. Helped in the first, simple, implementation but just (worse than) useless baggage after that. Instructions that trap on overflow too. Helped on some programs on simple implementations, but on an OoO implementation just the mere existence vastly complicates the pipeline even if programs don't use them.
With Arm, the bitmapped arbitrary set of registers load/store/push/pop is cruft that helped the first simple implementations (especially ones without icache). Same with the predication on every instruction. It uses a ton of instruction encoding space, doesn't get used much outside of conditional branches, and in modern implementations branch prediction is usually so good that you don't want to predicate instructions -- certainly not several in a row. Arm is deprecating IT* predication in Thumb2 now also. Also PC as a general register is harmful to modern implementations. ANY instruction with r15 as the destination can change control flow -- load, add, xor .. whatever. At least you can tell at instruction decode time, but it needs both opcode and dst register to tell.
Aarch64 fixes most of the traditional Arm cruft (everything mentioned above) and is a pretty good ISA. The main faults are that it still has condition codes (no other high performance ISA designed after 1990 does), insistence on the purity of 4-byte instructions only (Thumb2 showed that the benefit is well worth the small cost), and just the simple fact that there is TOO MUCH of it and no subsets allowed, making it impractical for small CPUs e.g. microcontrollers.
0. https://www.amazon.com/RISC-V-Reader-Open-Architecture-Atlas...
The big thing that is different than other "open" ISAs in the past is that there is an open specification / standard that isn't encumbered by restrictive licensing or patents. This allows software (think compilers) and hardware designers to target the ISA without fears of getting sued for using the ISA or having to have restrictive licenses.
It can also be simple to implement, but there are commercial, highly performant cores available too, for example, sifive.
The other salient is political: ARM, x86, etc are Western aligned while RISC-V is attractively nonaligned. ARM's government mandated Chinese subsidiary went rogue against ARM itself which endangers the use of ARM chips in China. RISC-V hedges against this risk for China.
I care because David Patterson is a badass who was right about everything. :)
You don't until you do. Like all the corps which need to replace the Huawei tech unexpectedly.
There are multiple cores available under permissive licenses all the way through to ASIC or FPGA implementation. There is also quite a bit of academic research happening now, which may not be formally open source but is shared and published.
> even that doesn't really mean much as interfaces have dubious copyright protection
There's a big difference between "given a license to use this" and "might not get sued, or at least might win if we do, if we use this without permission."
Today, board developers have to pay if they want to license ARM. And with recent developments coming out of ARM, the price to pay is going up by a lot, very soon. If RISC-V can develop to the point of more or less parity with ARM, then that will enable cheaper products that are just as good, equally priced products that are better, or equivalently positioned products that return a better profit to their manufacturers (which is good for you even if only indirectly—better profitability means easier entry for competition, better financial stability behind whatever ecosystem you're buying into, lower chances of companies crashing and leaving behind unmaintainable e-waste, etc).
IMO, reduced rent-seeking is good for everybody no matter what sector. I want more collaboration and less human effort/ingenuity/resource dissipating to waste heat. Open source makes Moloch cry.
IMHO the biggest issue right now with ARM is the uncertainty surrounding it, their Chinese subsidiary went rogue and they are trying to raise prices significantly in preparation for a sale or IPO.
More important is that more competition may lead to better designs and the RISC-V gives more freedom for firms to innovate.
As for the 10c a core on average, there will be billions of 1c/core royalties for things you don't even realise have a CPU in them, and tens of millions of much much higher royalties on the kinds of chips that go into smartphones and SBCs. Maybe as much as $10 a chip?
[1] tens of millions is wrong and it clearly not true that Arm charges ‘as much as $10’ for an SBC that will cost $40 retail.
Apple sells 70 or 80 million phones per quarter and they are only a small fraction of the market. Android phones sell over a billion a year.
Now we can discuss what the scope is for RISC-V companies to charge for cores or chips.
Jim Keller said yesterday that in 2024 his company will have an 8-wide RISC-V core, on a chip, that performs on a par with Apple M1/M2 and Zen 5.
Performance gap between RISC-V and x86 down to zero.
I suspect that in 2024 he means expensive shuttle run chips. But working and able to be demoed. Mass-production chips are usually 12-24 months later.
Edit: Or is 32-bit x86 so old that you could "just" clone it because all the patents have expired?
On a more general level, the idea of RISC is to have a very very simple instruction set instead of a thousand 'clever' features that are mostly underused, so that you can optimize your software project out the yin-yang if you're more concerned with pure performance than versatility.
I feel like RISC V has really started to pick up momentum over the last year or two, which is awesome to see. There have also been a bunch of tiny RISC V softcores for FPGAs too.
They list an NVMe SSD adapter board with PCIe x4, I wonder if that works together and can be booted from? I know with my RPi getting away from SD card boot made a huge difference.
It's still possible (with an adapter) to use PCIe cards.
It is already possible (with current u-boot patchset) to boot from NVMe. It has been possible for months to have root on NVMe.
It is indeed much faster than your average SD card.
It looks like they're off to a good start but appearances can be deceiving. Kernel is a fork and who knows if it's missing anything. It's all pretty new so I wouldn't expect it in mainline. GPU (Imagination BXE4-32) also seems to have a pipeline towards upstreaming.
https://wiki.pine64.org/wiki/STAR64
It's nice to see that it has onboard wifi. Barrel jack for power, rather than USB-C, is a little disappointing.
Yeah, it's at an awkward point right now where you wouldn't expect to have drivers upstream, so it's harder to predict whether it will get where we want it.
also, on my raspberry pi i at least stood a chance of running a headless chrome for some silly scrape job i had. RISC-V pretty much guarantees that's not the case, right?
I can confirm both chromium and firefox run.
They even have javascript JIT, so the performance is good.
However, what does matter is that the RISC-V ISA will be cheaper and more flexible for device manufacturers to use. That's why it's superior to ARM and has already partly supplanted it for smaller chips (there are over 1 billion RISC-V chips in use already).
* if you want to support the development of RISC-V as an alternative to x86 Arm /have some preference for not supporting x86 or Arm.
* if you are writing code generators, you may find RISC-V easier to generate code for.
If you don't care about these, then I would agree, keep using what works best for you.
But we're only talking 10% or 20% difference here.
The big difference is Arm is owned by a single company that can and does change its contract terms and prices, sues its customers, obsoletes old stuff at will etc.
RISC-V is managed by a non-profit that is steering along a path agreed by its hundreds of member companies, but can't and doesn't stop anyone from adding custom stuff as long as they stay compatible with the core ISA. There is a promise to only add capability over time, but keeping compatibility with the core 32 and 64 bit ISAs published in 2015 and ratified in 2019 ... forever.
There are already a dozen or more companies competing to design the best and most competitive and compatible RISC-V cores and chips, and that's only going to increase. If the company you are using falls behind or raises prices or goes out of business then you can just switch to another -- as long as you didn't drink their proprietary extension cool-aid (it can be very tasty).
The current limits of the RISC-V ecosystem are (I currently have one sitting in front of me, and ssh access to the other):
- WCH CH32V003 microcontroller with 2 KB RAM and 16 KB flash in an 8 pin package for 10c each or 20 pin package for $14.6c https://www.aliexpress.us/item/3256804850399956.htm
- Sophon SG2042 64x 2.0 GHz OoO cores similar to Arm A72, each core with a 256 bit vector unit, 64K L1 cache, 1M L2 (shared per 4 cores), 4M L3 local to a cluster of 4 cores, with the other 15x 4 MB L3 accessible via NoC at ~half the local bandwidth. 32 lanes of PCIe gen 4. https://www.sophon.ai/product/introduce/sg2042.html
On the other hand, existing GPU company Think Silicon spent six weeks in October/November 2019 adding some GPU instructions to RISC-V, showed it running in an FPGA at their booth at the December 2019 RISC-V Summit, and are shipping the resulting product now:
https://www.think-silicon.com/?section=2172
I'm curious about standardization of the rest of the system - the way x86 operating systems more or less work on any x86 machine, whereas ARM seems to basically require a device-specific OS image for every single device. Is there any work going into addressing that and making RISK-V more like x86 and less like ARM systems?
RISC-V is in a much better position than ARM and x86 already, because this is well underway and the boot specs have been available for years now.
In ARM, there was too little, too late. Most vendors do not follow the relevant specs.
As for the PC, the platform became so by accident (IBM PC clones happened) and there's of course a serious amount of historical cruft.
0. https://github.com/riscv/riscv-platform-specs/blob/main/risc...