> instead of a PDP 11 as the virtual machine, why not risc V
What would that look like, in your view? I can't see them being significantly different, as computation models go. And I'm familiar with both.
If you're thinking of ++ and --, those were introduced in the B language before the first PDP-11 was even made, plus of course the PDP-11 only offers pre-decrement and post-increment while C offers all four combinations.
I'm not really sure. Problem is, is that a lot of the compressed instructions have been informed by the c way of doing things.
TBF I'm playing with a pi Pico, so anything I do is likely to be more influenced by the memory set up. Ie xip.
I could write a whole essay on this. But I was more meditating on the assumptions and decisions made, because that was obvious/easy given the hardware available. Why don't really write languages like that now, and I don't really think C is that language anymore. But it would be interesting to see what could emerge.
To answer this follow-up, Benji, the syntax was designed so the learning curve isn’t too steep for people coming from languages like C/C++, even if I think that analogy is wrong, Riscrithm isn’t trying to be another C, as that would just be a cheap and worse copy. My goal is to allow people writing drivers or high-performance code to focus on structuring their logic without the compiler abstracting it into ambiguous implementations. Also, it’s great seeing you using a Pico; working with microcontrollers is fantastic, and I think it would be nice if you considered running Riscrithm on it—especially v1.1. Let’s be honest, v1.0 was an MVP, while v1.1 aims to bring all the features that will appear in v2.0, which will largely improve the compiler’s structure and make the language cleaner. I also appreciate your curiosity about what might emerge, and I want to assure you that I’ll do my best to make it a great language!
I was more just musing on the space around high level assembler/ low level programming language. Currently C is the option. So anything entering that space will be competing with C
They've finally stopped comparing RISC-V boards to Pi 3!
But why don't they include Pi 3 and Pi 4 in the charts *anyway*, as well as come more appropriate x86 machines such as Core2Duo, i7-860 (or other Nehalem), 2nd-5th gen i5 etc?
It's not telling anyone anything they didn't know that a K3 isn't going to compare to an Apple M5 or Core Ultra 9 or whatever.
I've got as 32 GB PicoITX K3 and I've been comparing it to a "Late 2012" Mac Mini with i7-3720QM running Ubuntu 24.04 and the Mac is 20% or 30% faster single-core, but of course on some things the K3 wins from having lots of cores.
I imagine the issue is not having hardware to test. Or, at least, not having a test environment for that hardware.
Probably the only hardware they tested for this article was the K3 and the only recent test results they had that were slow enough were the Pi 500+, the P550, and Loongson. I agree though that comparing it to 10 different Ryzens is not super useful.
The Pi and the P550 are what people are comparing it against. And showing how much slower it still is compared to modern x86-86 is useful too. Something like the RK3588 would have been interesting.
This shows that RISC-V has improved a lot compared to itself, that it is becoming competitive with ARM, and that it has a long way to go to the high-end desktop. That is about the right story to tell.
The average bystander doesn't have to care, just buy a machine implementing the RVA23 profile (standard set of extensions) and be happy.
If you're building your own embedded hardware then you determine what your needs actually are e.g. do you need double precision? half precision? vector?. Then you choose a chip implementing that. Then you copy the ISA string from your chip's documentation to the `-march=` argument for GCC/Clang and be happy.
It's not hard and you don't have to think about it unless you very specifically want to.
The average bystander might want to write high-performance code for their risc-v cpu. Then they must know precisely which instructions are available and what the performance implications of using them are. E.g., the difference between a shared and non-shared fp register file is huge.
For the "average bystander" they're going to buy an OS and compatible hardware, or if they're the average programmer they're going to use a compiler and libraries that solve the problem already for them. Very very few people need to worry about the details.
If you want to get the absolute most out of a specific CPU that is in your hands then you of course have to refer to the documentation for that specific CPU.
That process doesn't depend on whether it's an x86 or an Arm or a RISC-V.
That's why x86 people refer to the HUGE document maintained by Agner Fog.
If you want your code to run well on all standards-compliant implementations then you write according to the ISA documentation, in this case RVA23. Or ARMv9-A. Or x86_64 v3.
Nope. I want to get the most out of all cpus that will run my code. This is a combinatorial problem that grows exponentially by the number of relevant extensions. So, yes, you need to know the hardware, but accounting for combinations of 5 features is way easier than accounting for combinations of 10 features.
Riscv is basically repeating the same mistake X11 did. A minimal base that could be varied endlessly by combining extensions. I didn't work for X11. Some extensions became de facto mandatory (shm) while others fell by the wayside. But you could never rely on the availability of a given extension because someone somewhere might not have had it or disabled it. Then Wayland came along and cleaned up the gazillion extensions mis-design because it was a huge PITA. Riscv will get there too, sooner or later.
You think the average person writes performance optmized code?
If you are on that level then you know pretty well what you are targeting. And even then in 99% of cases you just look at the top level profile.
If you do performance analysis for some specific embeded project that is not using a standard profile, then its a bit more work, but hardly impossible.
Bruh, the "average person" won't buy a riscv-based computer in decades. The average bystander to the riscv project indeed writes high-performance code for their, so far, mostly non-existent or emulated riscv processors.
Your seriously arguing the the avg person write performance code so critical that minor difference in hardware implementation are relevant? Most people write code that isn't that performance critical, fireware or they are porting existing software over. A extreme minority of people that interact with an ISA is hand optimizing code.
Lol... the RISC-V ecosystem has loooong passed that stage. RISC-V is eating into markets from deeply embedded to automotive, high-end server cpu's to specialized accelerators. That's mass-produced hard silicon.
It's here to stay, coming to a device near you Real Soon Now (tm).
Do high-performance RISC-V CPUs (that you can actually buy) still exist? SiFive Unleashed was great but IIRC it was a single batch that never returned.
I have in my hands one of the new SpacemiT K3 machines. It arrived today. I'm comparing it to several other things, and finding that it is pretty comparable to a "late 2012" Mac Mini with a i7-3720QM with base 2.6 GHz turbo 3.6 GHz running Ubuntu 24.04. They are quite close in feel for general use, web browsing, code editing, watching YouTube etc. The Mac is a little faster on many things, a LOT slower on others (anything that can use 8 cores, obviously).
You might say that's not "high performance" but we thought it was pretty good a dozen years ago.
The previous SpacemiT K1 chip two years ago was more like one of the last Pentium IIIs or PowerpC G4s, except with a lot more cores.
SpacemiT have a next generation K5 coming out, they say, at the end of the year. Tenstorrent have their new Ascalon-X core comparable to Apple's late 2020 M1 — and designed by the same guy who designed the M1. They've taped out a chip using that and say they'll be selling a dev board in Q2 or Q3. For now the first version is using an old chip process and it will be running at half the clock speed of the M1, but that's still going to be a very decent machine.
The HiFive Unleashed was of course 8 years ago. Since then there have been the HiFive Unmatched (roughly like Cortex A55) and the HiFive Premier P550 (a bit better than Cortex A72, other than no SIMD).
> You might say that's not "high performance" but we thought it was pretty good a dozen years ago.
Definitely sounds pretty high-performance compared to basically every RISC I've seen (and including nearly every cell phone I've ever owned with the exception of the Apple ones).
Tenstorrent is awesome, can't wait to see if I can afford any of their hardware in 5ish years. I miss when you could buy TPUs as a consumer (Coral etc.)
The Arace purchase link for the Jupiter 2 kit says it's “in stock“, but it's actually for a discount coupon. The actual system can only pre-ordered. The Sipeed web site does not say anything about shipping timelines, and the products are not offered in their AliExpress store. I think the Sipeed boards are in preorder, too.
Of course, neither of these are machines. And the average bystander probably isn't used to importing computer parts directly from China, either.
Deep Computing have started taking orders for the final product and the Preorders are shipping within the next 6 weeks. They will be shipping from China I expect, but it's a proper shop front.
AVR is vastly better to program than 8 bit PIC — either by hand or by compiler from C — but some people still insist on using those PICs for simple things.
The "PIC32" name was originally used for MIPS CPUs but more recently ARM ones and PIC32A is an extended dsPIC (16 bit).
There is also now PIC64 which is currently a couple of different RISC-V implementations, one based on quad core SiFive U54 from 2018 (same as PolarFire SoC FPGAS), and higher performance (and rad-tolerant in some versions) octa-core SiFive X280 with vector processing. Microchip have I think also indicated there will be future Arm-based 64 bit PICs.
The PIC and AVR are both more about peripherals (and low power, since they can sleep while peripherals do things).
The documentation on PIC or AVR assembly is extremely short, less than 200 pages. But the chips other peripherals (MVIO, 50mA push/pull current at upto 5V, OpAmps, differential ADCs, Event systems, and more) is where these chips get a resounding advantage.
Except now PIC32 CM has those very nice peripherals (comparable to AVR DD at least). It's very curious to me how it all works out: if Microchip will continue porting their nice hardware to ARM, or if they'll continue to develop new stuff for the 8bit market.
----------
Because the peripherals are hardware, I don't think it's really too valuable looking at the assembly language or other comp-sci details. The 8-bit assembly languages, be it PIC or AVR (or 8051) are all sufficient. Enough CPU to do things and glue the peripherals together.
I'm not sure why anyone would care what chip is in a router that should just sit there doing its job and you're not going to write or run other software on?
Sure it's kind of nice to know the car media player thing I've had for a couple of years has a RISC-V D1s/F133 chip in it, but I bought it because it receives CarPlay (and Android Auto) and transmits audio on FM (actually the best quality one I've had, and I've had a few) and cost $30, not because it's RISC-V.
And I'm eagerly awaiting a pico-ITX SpacemiT K3 box arriving in the next week or so.
But a router? Why do I care, past price and functionality?
> it’s not even clear if it can saturate a gigabit
If that's the case then it's not the CPU's fault. I can't open the linked site but assuming it's really the same as a BPI-F3 i.e. a SpacemiT K1 chip, that can do 2.8 GB/sec on large RAM to RAM memcpy using a CPU core i.e. 44 Gbps total, 22 Gbps each read and write. Plus I assume it's got DMA so no need to involve the CPU anyway.
Here is a test I ran in April 2025 on a Sipeed LicheePi 3A same chip).
Although your benchmark is interesting, I don't think it's very relevant here. In my experience, you'll saturate the CPU through packet decoding, routing, and firewalling long before memory becomes a bottleneck.
That's why all network SoCs have hardware to accelerate such thing, otherwise in software alone they can barely handle simple routing at a few hundred mbps.
1 Gb/s is only ~100,000 packets/s at standard MTU. You literally get 10 us/packet which is a eternity. Normal fast-path router operation only really needs to consider the header of <100 bytes/packet, so you are getting ~100 ns of compute per byte of considered data and on even a 1 Ghz processor you are getting over 100 instructions per byte of considered data. Failure to achieve a measly 1 Gb/s really says more about those software implementations than it says anything about the impossibility or difficulty of the problem.
That 10c microcontroller has 15 32 bit registers, allowing you to make up to a 480 bit counter. That ought to be enough until long after the heat death of the universe.
It also has 2k (16384 bits) of SRAM, allowing even larger counters.
It runs off 2.8V - 5.5V DC, so supplying power is pretty trivial. Doesn't need a crystal, though of course adding one will improve the timing accuracy.
somewhere else they were discussing how to use a 555 to time 55 years, and how for such a long period you'd need impractical resistance and capacitance values.
easy workaround would be to set a more reasonable period, say, 1 sec, and use a counter to know when you hit 55 years.
coincidentally, 55 years is 2 ** 30.7 seconds, so it'd just fit in a 32 bit register.
though i take you were thinking about counting clock cycles or something in which case surely your register would overflow
I find it much easier to write a ten line program for an 8 pin CH32V003 (or ATTiny85 in past times) to do exactly the timing or SDC comparisons I want than to figure out the circuit and component values for a 555 or op-amp.
For that matter, a 16 pin CH32V003 can emulate a vast array of 7400 series devices as long as you don't need ns timing — no problem for µs. It's also cheaper.
"There's a reason microcontrollers are used for tasks like debouncing switches."
Because people are too cheap (or fail that hard at basic analog electronic control) to get a proper single-pole single-throw switch with a pair of MOSFETs in a monostable mode, or use an S-R flip-flop latch to debounce, or even a very simple R-C filter circuit.
"Throw a microcontroller on it and call it a day" is the surest sign of someone not properly educated in electronic engineering.
If you live under a waterfall you'll use 1000 gallons of fresh water pumped at blasting high speed to wash a cup.
We live under a waterfall of cpus and gates in general, and organisms don't care if their environment is perverse. A thoughtless organism will happily consume 1000 units of a free resource just to get 1 unit of some other non-free resource.
And a lot of humans are the worst. Thinking beings who elect not to care about anything like that. Like spammers that operate simply because sending email is free for the sender. They get almost nothing from it, and it costs everyone else a lot, but it costs them even less than the tiny bit they gain, and the external costs don't matter to them the tiniest bit.
But the environment is perverse, created by economies of scale and Asian slave labor and the push for advancement for it's own sake which makes existing useful things artificially low value by being "obsolete".
A software version of that might be making apps with Electron. It doesn't matter how much cpu and ram and disk and general mass of tech stack it takes to make some trivial app. The developers precious time outweighs all other considerations. If they can make the app in a few minutes with no effort instead of a few hours, it doesn't matter how much of everyone else's resources they consume since their time is valuable and 1M other people's cpus are free.
Not THAT much of watershed. I didn't even see a lot of stuff about the equivalent first ARMv9 SBCs (and first with SVE almost TEN YEARS after the spec was published), the Radxa Orion O6 a year ago and Orange Pi 6 Plus half a year ago (same chip).
Also, none of us actually HAVE them yet. Sure, I've been using a pre-production board at SpacemiT via ssh to China since mid January, but it's still probably two weeks until I'll have one in front of me and I can browse the web and watch YouTube on it etc.
All the things we could do via ssh were published three months ago. LivingLinux for example has a whole series of videos on YouTube.
I'm going to replace it before then.
reply