As Alibaba launches server-grade RISC-V CPU, Beijing throws its weight behind ISA The permissively licensed RISC-V instruction set architecture appears to be gaining significant momentum in China. One sign of enthusiasm for the royalty-free ISA came late last week when an outfit named XuanTie, which is part of Alibaba’s DAMO Academy R&D operation, announced a C930 CPU design that's available to license for …
If Beijing is strongly suggested to use the royalty-free arch under some major policy directive, then I'd suggest they also put some new OS together that can take adavantage of the very-many-simple-cores philosophy that underpins RISC-V.
x86, ARM, and POWER, are made for contemporary OSes that uphold multiple simultaneous users and multiple simultaneous tasks, many of which are dynamic (requiring some level of interpretation, eg. from bytecodes, and intricate memory management, eg. gc), with efficient preemptive context switching. RISC-V, not at all. That arch is not good for the main CPUs in datacenters, workstations, desktops, laptops, tablets, smartphones. It just isn't, until some new OS that does multi-user and multi-tasking on separate individual cores (each of which runs in purely single-user and single-tasking mode) is put together.
Today, RISC-V is fine (great even) for things like Tenstorrent's AI accelerators (that don't run an OS). But use it as a main CPU running Linux and it turns into a dog, with no tail, no legs, and no torso ... a lot of bark though.
Abstract computer science is fine on RISC-V (kind of), but real everyday workloads run like starch water: "it locks-up and holds its shape when [context-switching] pressure is applied to it".
In my view, yes, it is the ISA (its 32-bit wide instructions) that is designed for a 1W2R register file arch -- this means that during a clock, an instruction can read form 2 registers and write to 1 register, simultaneously -- not more.
This is not sufficient to write data (from one register) into a vector whose root is stored in a second register, at an index (into the vector) specified by a 3rd register -- this very basic operation requires (at least) a 0W3R register file. Similarly, at 1W2R, an instruction cannot read data from two consecutive cons cells in memory (parts of a list), where the cons cell's address is stored in a register, and data from the 2 consecutive memory locations are to be stored in two CPU registers -- this elementary operation requires a 2W1R register file (and corresponding ISA).
Considering these two very basic operations together suggests using a 2W3R ISA and file for performance and efficiency (rather than the 1W2R of RISC-V) -- or at least a blend of 2W2R and 1W3R (max of 4 registers specified in an instruction). Either way, that's not what RISC-V was designed as (which is ok for single tasking imperative workloads, but not for multitasking list-, graph- or even object-oriented codes, where compound data items are commonly referred to by root address and offset index, in machine code -- and if your machine can't do that ... it sucks at these workloads, by design).
The majority of commodity computers, especially in embedded systems, don't need ultimate performance, just 'good enough' performance. This poses a threat to proprietary architectures simply because it deprives manufacturers of revenue from bulk commodity parts. (You just can't make a satisfactory long term business from a handful of super-advanced parts.)
(Its also worth bearing in mind that complex architectures are invariably microprogrammed. The internal architecture is invariably a RISC.)
You are vastly wrong. Get up to date with the current state of risc-v instead of sitting in curmudgeon corner parroting old yropes.
The rv64 spec is in place, distros support it, the first gen CPUs are already doing real jobs, the next generation will be equal to current lower end arm/x86 systems. And then the real optimisation starts.
Oh…..the *next* generation of RISCV will be good? Excellent. I’ll wait.
The first generation are *not* doing real jobs. Unless by real jobs you mean “earning money for a tiny minority of snake-oil salesmen, while hoovering up the careers of thousands of well-meaning but gullible engineers and making them un-employable during a tech recession”. Good Job.
Any CPU that depends fundamentally on solving the “multicore scaling problem” with OS fairy-dust, is dead-on-arrival. Magic OS is not riding to the rescue of RISCV.
Alternatively, if you do have an idea how to write an OS that solves this, for *any* CPU, I suggest you do so and earn your first hundred billion quid. But don’t waste thinking about RISCV…..
Yeah, the thing about RISC-V cores (imho) is that they're very simple and inexpensive to implement (plus not encumbered by licensing) which is "opposite" to the historical situation where CPUs were complex and expensive, and so each and every one of them needed to be used to the very fullest of extents possible (i.e. multi-usered and multi-tasked). RISC-V is so cheap you can overprovision these cores wildly in a CPU or computational system, and run each core in a purely single user, single tasking, mode -- as per old DOS, which should run great on those.
So, the OS could be multiuser and multitasking at its top-level, but inside, users and tasks would be assigned to individual cores, without sharing nor context-switching, with all processes running to completion or termination before a core is freed and reassigned. A PC might have 256 RISC-V cores in its CPU (or more), most of them free and unassigned at any given time, much like RAM, SSD, etc ... (all rather cheap and plentiful).
Personally, I won't be unhappy if the US turns itself into an isolated technological backwater and continues to lose its dominance in the tech world.
And it seems trade restrictions are an excellent catalyst for that process because they force innovation by those on the receiving end
"...in servers, clouds, or other large-scale scenarios where the ability to run virtual machines is table stakes."
As a poker player, I found this confusing, but Google tells me that in business, this is indeed the common usage of the term "table stakes", where it means "the minimum expectation".
In poker though (where the business world stole the term from), this is nearly the opposite of what it means. It defines a maximum, not a minimum. In poker, "table stakes" means a person can not bet (or be compelled to call) more than they have on the table. For example, you can't pull out your wallet in the middle of a hand to place or call a bet, or take the watch off of your wrist and throw it in the pot. If two players are playing in a no-limit game, and find themselves the only 2 who are still in a pot, then if player A has $500 on the table, and player B only has $75, then player A can not bet more than it would take to put player B "all in", so $75 is the max bet.
Thank you for attending my pedantic TED talk.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
