Previously software engineer working on compiler toolchains and runtime libraries at SiFive. Also involved in Working Groups developing future RISC-V extensions. Previously Samsung R&D (toolchains and runtime libraries for Android and Tizen), Mozilla (JavaScript JIT), and others. All opinions my own.
Submissions
RV32I Reference [pdf]
hoult.org
6 points·by brucehoult··1 comments
A 10-cent microcontroller deserves a 10-cent devboard: RISC-V CH32V003
hackster.io
14 points·by brucehoult··0 comments
An Empirical Comparison of the Riscv and AArch64 Instruction Sets
dl.acm.org
6 points·by brucehoult··5 comments
Chinese Company Developing 64-core RISC-V Chip with Tech from U.S.
hpcwire.com
7 points·by brucehoult··1 comments
Pricy RISC-V Roma laptop in shock cheeky CPU switcheroo
old.reddit.com
4 points·by brucehoult··2 comments
Could RISC-V become a force in high performance computing?
theregister.com
5 points·by brucehoult··0 comments
Dual core Xuantie 910 out of order RISC-V SBC available for preorder
twitter.com
2 points·by brucehoult··2 comments
Wave Computing Rebrands to MIPS, Embraces RISC-V for Next-Gen Cores
abopen.com
5 points·by brucehoult··2 comments
PolarFire SoC [RISC-V cores in FPGA] Icicle development board kit now available
I've never read any of his economics (didn't know until today that he was one) and formed an opinion based only on his tech press writing. Interesting that he was on the board of TSMC!
> I suspect his economic ideas were more premature than wrong.
I don't think economics is a time-dependent field.
Apparently he favoured more government involvement in industry, which I believe has rarely if ever worked out well anywhere. Government officials are very very bad at predicting what will actually work or sell well, are too risk-averse to back the true winners preferring CYA to prove that failure wasn't predictable or their fault, no real skin in the game so easily swayed by dinners and sports tickets and personal favours, and almost always double down on failed ideas and companies rather than admitting they got it wrong.
Provide a safety net for individuals, by all means, but not for companies.
Pournelle was good as a kind of (relatively) non-technical user in the early days (70s, early 80s) who just wanted to use computers to write books.
Dvorak was quite good, but for me much too oriented towards the Wintel world.
And then there was another guy who was sooo consistently bad I referred to him as Less Than Thorough. I'm not sure now whether he was also the MIT economist who died in 2016.
Robert X. Cringely (Mark Stephens, not those later writing at IDG under that name) was by far the best of the bunch, though was somewhat late starting writing columns only in 1987. He knew his stuff, correctly predicted trends etc. And continues to today at cringely.com, so that's a 40 year tech pundit career so far.
Software binary compatibility is less important now than it has been for 30 or 40 years of x86 dominance because now we are so over-served by hardware that most software runs just fine in emulation (especially transpiling/JIT).
Compatibility also wan't too important in the 70s and the 6502 wasn't compatible with anything else. Everyone expected to rewrite everything back then whether between manufacturers or just a new model from the same manufacturer.
> Finally the chips have to deliver in performance, to actually provide good mobile devices
There were still, as recently as 2025, new smartphones being released with only Arm A53 cores from 2012. Low end, obviously, but equally obviously there is a market for them.
RISC-V SoCs passed that performance mark in 2021 and shipping SBCs are currently at the Arm A76 RK3588/Pi 5 level. In flagship phones that was the Samsung Galaxy S10 generation, but there are still today a lot of budget phones using A76 as the primary cores (usually with some A55s too).
Cores are available for licensing up to around the Cortex-X3 level. Someone just has to be interested enough to put them in an SoC.
It's a business question now, not a technology one.
> Why not just switch to a slightly different compiler and core, and then you make all your old code safe without verifying it
You don't even need a new core. Fil-C makes regular old (and new) C code memory-safe. You can use it for individual apps on your existing OS, or Filip Pizło has been making an entire distro work with it ... libc, bash, ssh ... everything. He's got web browsing working and at the moment is working on LibreOffice. Many things work as-is, most things require very minor patches (which he's upstreaming).
Unlike Rust, there is no "unsafe" escape hatch (and it's not needed).
QEMU. Docker, using QEMU under the hood, there automatically with Docker Desktop on Mac & Windows, install QEMU yourself on Linux and configure binfmt_misc to use it.
The THead C906 core is full Linux-capable but is microcontroller-adjacent and has an early draft version of RVV that is different in details but has the same flavour (and at least some code is binary-compatible with RVV 1.0). Recent GCCs RVV intrinsics compile to either RVV 1.0 or the 0.7 draft (named XTHeadVector now) so if you're programming at that level they're compatible. Milk-V Duo starts at $3 for a tiny board with a 1.0 GHz C906 running Linux, a 700 MHz microcontroller config C906 (no MMU etc), and 64 MB RAM. Well, I paid $3 ... then they were $5 for several years and now I see $11 at arace.tech. There are also 256MB and 512MB versions, with the larger one also having an Arm A53 core.
That's actually got full 128 bit SIMD with all data types supported up to 64 bit int and FP.
You can also buy bare CV1800B and SG200x chips (Sophgo bought original designer Cvitek and enhanced the design)
> "arm removing thumb" should have been a strong signal.
I don't see any reason to think that Arm ISA designers are any more skilled and knowledgable than RISC-V ISA designers. Given the relative number of people and the amount of academic and industry expertise you'd rather expect the opposite! Retired Arm ISA designers such as Dave Jaggar who designed Thumb and Thumb2 are on record as saying that the RISC-V designers have done a fine job, and that RISC0V is the current state of the art.
When I tested my Primes benchmark on a Pi 4, the variable-length Thumb 2 version was the fastest as well as, of course, the smallest.
The performance gap between RISC-V and x86 or Arm is in fact closing.
The SpacemiT K3 machines which most people who ordered in early May have now received are comparable to the RK3588 and Pi 5, with Rock 5 delivered to customers in mid 2022, Orange Pi 5 at the end of that year, and Pi 5 in October 2023.
So that's at most a 4 year gap, less than 3 years in the cast of the Pi 5.
That is the highest performance Arm64 machine most SBC users have. The faster CIX P1 exists but it seems that very few people actually have Orion O2 or Orange Pi 6 Plus.
Before the launch of the K3, the previous gen early 2022 to early 2024 JH7110, TH1520, K1 were somewhere around 6 years behind Arm SBCs.
RISC-V machines expected late this year (let's say early next year) will be similar to CIX P1, so just a 1-2 year gap.
Vs x86 the previous generation RISC-V was something like one of the last Pentium III or PowerPC G4, while the K3 is mid range Core 2 verging on early i5/i7 in many regards. So that's caught up on Intel by something close to ten years in four years. And the next gen will be somewhere around Zen 2 or whichever Skylake iteration is in the same ballpark.
Even more importantly than the gap, once that SkyLake to Zen 2 to Apple M1 performance band is reached, that is a performance level that remains "good enough" in 2026 for most users of computing devices for their everyday web browsing, media consumption, productivity/business app uses. I'm typing this on an M1 that I sit at all day every day (using it to access some faster machines for heavy work), and I have a lightweight Zen 2 laptop that I use for travel.
You can't remove C from future RVA because a large part of the value of RVA is that each version can run all the shrink-wrapped (binary distribution) code built for the previous versions.
> small cores are arbitrarily given a burden of supporting variable-length instructions
Even the smallest commercial microcontroller cores e.g. the CH32V003, support the C extension. They strip out other things, such as half the integer registers, but they keep C.
And that's in a market where you can use literally any combination of extensions you want, because the customers compile all their own code, and you just tell them what ISA string to use.
And how is an instruction spanning a page boundary and causing a page fault any worse than an instruction NOT spanning a page boundary and the next instruction causing the page fault instead?
As Paul said, if a 4 byte instruction spans a cache line/page boundary then you just hang on to the last 2 bytes of the page (first 2 bytes of that instruction) and decode them along with the instructions in that next cache line / page.
The only time it could possibly make a difference is if that spanning instruction is a jump to somewhere else AND that instruction could somehow have fit entirely in the previous page.
If there was no C extension then that next instruction would NOT be entirely in the previous page, it would be somewhere well into the next page, and that next page would have been required to be fetched much sooner. The C extension typically allows 30% to 50% more functionality to fit in each VM page.
Also, Qualcomm's proposed new instructions did not in fact use the freed-up space from not having C. They fit into other unused parts of the ISA.
I don't object to the new instructions Qualcomm suggested. I'd be perfectly happy to see them ratified and added to a future standard (even to RVA23 if they'd chosen to pursue that, but they didn't).
What I and others objected to was dropping the C extension from RVA23, or any future RVA-series, overnight given that RVA20 and RVA22 already existed with the C extension.
There will come a time when some RISC-V extensions will be retired and replaced, and it's entirely possible that C might be one of them, but there is currently no mechanism to do that, and when there is I'd expect that it would be done with a 10 or 12 year deprecation period, minimum.
NEVER overnight between one standard and the next one.
Which wouldn't have helped Qualcomm with their Nuvia core anyway.
Anyway, Qualcomm had now bought Ventana, which has engineers who know how to support the C extension with high performance, and they already had high performance RISC-V cores doing so.
... confirms that, but I'm not clear on which config the $4000 upgrade was starting from, but I think it's from the M3 Ultra's standard 96 GB.
Both articles say that previously 256 GB RAM was a $1600 upgrade from 96 GB but "now" is a $2000 upgrade.
Now "now" even 256 GB isn't available and 96 GB is the only option with the M3 Ultra.
M3 Ultra is currently $3999 with 96 GB and 28 core CPU 60 core GPU, or +$1500 with 32 core CPU 80 core GPU. If the base price was the same prior to March then yeah $3999+$1500+$4000 = $9499 would have been the price for a maxed out CPU/GPU/RAM config with a 1 TB disk.
I wasn't looking at Mac Studio prices back then so unfortunately articles such as these are my only clue. I'm still more than happy with my original M1 Mini with 16 GB RAM as I don't work with local LLMs — only on my little NUC-like RISC-V "K3" machine with 32 GB RAM and regular RISC-V cores with 1024 bit vectors as the "NPU", doing around 7 tok/s on 32B models while using 14W of power.
They use the GPU but an Apple Silicon GPU has the same high speed access to all the RAM on the machine as the CPU does, rather than having its own walled-off maybe 16 GB VRAM in mainstream gaming GPUs or 24 GB in RTX 4090 or RTX 5090 (MSRP $1999 but in practice $3000-$4000 at the moment). Nvidia A100 (80GB VRAM) apparently cost $15,000 or so.
Not only does Apple's unified memory give the GPU more RAM to use, but it also eliminates copying things between CPU RAM and GPU RAM.
A Mac Mini with 48 GB RAM costs $1799. A Mac Studio with 96 GB RAM is $3999 — until March you could get a Mac Studio with 512 GB RAM for $3999, all of which could be used for your AI model.