The likelihood of ARM sailing off into the distance and x86 disappearing is very slim. It's worth keeping in mind that they have more in common than you might think (i.e. RISC and CISC don't mean a huge amount any more when the old x86 instructions aren't used any more and ARM had/has a JavaScript instruction)
"ARM has a Javascript instruction" is just misinformed.
They have always had the FCVTZS instruction which converts a floating point number to an integer (just as every instruction set has). If the floating point number is too large to fit in an integer then the bottom 32 bits are returned.
The new(ish) FJCVTZS does exactly the same operation except that if the floating point number it too large then the largest integer is always returned.
The implementation complexity difference is just about zero. It just so happens that the new instruction fits what JavaScript wants while the old one fits what C wants.
There is certainly nothing non-RISC about FJCVTZS. It's a perfectly simple instruction.
x86 has a quite variable instruction size, up to 15 bytes. So an x86 decoder will be more complicated than an ARM or RISC-V decoder. I'm pretty sure that means that designing performant IP is more difficult engineering-wise for x86.
And it turns out to take up a remarkably small area of the die. So, unless it actually slows down execution, it is a small tax that is overwhelmed by benefits of volume production.
Sorry for going off topic, but your comment confuses me. Doesn't "sail off into the distance" mean to disappear? But you're saying the opposite in your comment?
My reasonibg being that when a ship sails off into the distance it disappears from view.
I think they are saying it is unlikely ARM or x86 disappear, and that these instruction sets share some unexpected commonalities. They are not otherwise comparing/contrasting x86 and ARM, they are basically evaluating if either one seems likely to disappear and answering in their opinion: “no”.
So if RISC-V adopts WASM would that give it an interesting edge? I'm not a hardware guy, all software, but definitely would love to see a little more diversity in consumer grade hardware.
You could standardize a WASM translator into any ISA (or a direct implementation hypothetically), but it wouldn't be particularly useful because WASM is designed to be nice (safe) to be run in the browser in a JIT environment.
If you want diversity, and an introduction to truly Alien CPU designs I recommend taking a look at the Mill.
Speaking of competition, I was reading the Mill news board and apparently they were planning on taking a step up this summer but COVID meant they couldn't do it. (But they are still ticking along)
In the current legal environment exported by the US, it might be better to have licensed patented technology. Otherwise one leaves opportunity for trolls to patent and sue companies in that space.
I wonder to what extent the digital logic design is open source. The RISC-V core ought to be, but what about the memory controller or PCIE root complex, (or USB3)? Those parts are also very important.
Just because it's RISC-V doesn't mean it's open source. RISC-V is an open architecture so anyone can make an implementation but those implementations can be closed source. SiFive have released some open source stuff (https://github.com/sifive/freedom) but the majority of their work is closed source IP. In a way they're quite similar to arm.
Not just like ARM. You don't need a license to implement a RISC-V compatible machine. IIUC, you only need to pass a compliance test to brand your machine RISC-V and use the trademark.
There's not just one RISC-V core, one of the great things is that there are many, of varying complexity and performance. Some are very open source some are not.
There's already GCC and clang support, linux is here too.
The vector extension is still in draft and still changing. We don't want to add support that we will have to remove later if the proposal changes again. But we have support in the rvv-intrinsic branch at github.com/riscv/riscv-gnu-toolchain. There is also LLVM work, they have different rules for development, so are handling this differently.
Thanks. That's rather what I'd expect, but I was surprised at hardware being announced with (some version of) the vector extension and wondered what support there would be for it. Is it reasonable to ask what you might expect in terms of changes if you started playing with an initial implementation, or is it still wide open? (Assuming the right Jim!)
The vector extension is getting close to being formally submitted, so things should settle down. There was a major compatibility break a few weeks ago, but I'm hoping that was the last one. We won't know for sure until it is approved.
Vendors advertising vector support will have to maintain their own toolchains if they implement drafts. Most vector support is in IP cores, and they can be changed to follow the draft. There is no problem until someone makes an ASIC. Unfortunately Alibaba already did that and they are going to have lots of problems as they are incompatible with everyone else. But most everyone else is waiting for the official vector extension before making ASICs.
That spec is just a draft, and still undergoing revision. Its close in spirit to a Scheme RFI (request for implementation). Until the consortium ratifies it (ie, members state their intention to implement it), its just a wishlist. A well-reasoned wishlist, but a wishlist just the same.
It is just hard to imagine the thought process that would leave something as important as popcount to such a dodgy and long-delayed prospect; hard to imagine omitting it from the core instruction set, so that it is only ever implemented, if ever, in the most distended and expensive chips.
I think RISC-V isn't really targeting general-purpose machines. They are targeting special-purpose machines. Think Google TPU built from a RISC-V scalar unit + custom tensor unit. 64-bit flash controller without a multiplier or MMU, but with specialized instructions to accelerate error correction. Something to manage the DDR training at startup. Embedded security widgets. Things like that.
This is a development machine announcement for the companies who are building such custom hardware.
The sort of things being targetted by one effort are listed at https://shakti.org.in/processors.html whether or not that has anything to do with popcount.
This SiFive one seems interesting for having the vector extension, though that hadn't been finalized the last I knew.
There are a number of companies asking that popcount not be included in the standard Bitmanip extension, but be optional, because it is expensive to implement.
The MMU works fine, it's just poorly-documented and turns out to implement the incompatible draft-1.9.1 spec not the ratified and standard-going-forward 1.10 spec.
This is not Linux-capable though. The choices are FreeRTOS and bare metal. The chip is pretty unbelievable at that price though. You get a lot of functionality for $9. And it works - I have it on my desk.
Yes, it's the beauty of RISC-V: eventually, it's going to cover all the niches. From RFID energy-gathering chips up to desktop / datacenter CPUs.
Right now, its use is still very fragmentary, but Kendryte K210 chip shows that Chinese chip designers already got some real experience with RISC-V, and it's safe to bet it will be more chips with RISC-V coming from China every year.
At some level... does it matter? The BCM2837 (used in the RPi 3), is 40nm if https://www.raspberrypi.org/forums/viewtopic.php?t=137991 is to be believed; more advanced fabbing is good if you wanna go head-to-head with cutting edge ARM or even x86, but for a lot of stuff you don't need to be that good.
Alibaba have presented their Xuantie910 RISC-V processor, one month ago at Hot Chips.
It is by far the RISC-V CPU with the highest performance ever designed.
Nevertheless, to reach that performance, they had to add a custom instruction set extension with indexed addressing modes, as a workaround for the greatest defect of the RISC-V ISA, its incomplete set of addressing modes.
