The RISC-V isa is specifically designed to be nice and regular and easy to decode, and work with, which definitely shows here (also in the RTL code if you look at some of the well designed RISC-V cores)
Of course, bot x86 and Arm started like that as well - but after 20+ years of evolution, they have to drag along a lot of history. (and one never really takes things away from an ISA, you only add new features, and at best deprecate old ones).
That said, with the extensibility of the ISA in mind as a design principle, I do have good hopes, RISC-V will stand the test of time reasonable well in that sense...
The ARM64 ISA does not have 20+ years of evolution as it was announced in 2011. It’s essentially a brand new ISA and has cast off almost all of the legacy of previous Arm ISAs.
This seems right at first; however, about half of the armv8 spec is taken up by a copy of the armv7 spec and info about interop between the two ISAs. So armv8 isa is considerably constrained not only by the interop requirements, whereby an armv8 OS/hypervisor must be able to control the environment of an armv7 process/OS, but also by the need for implementing both ISAs without excessive duplication of silicon. For example, an actual v8+v7 implementation must surely have a single pipeline supporting both ISAs.
It seems notable to me that Aarch64 is the only general purpose "clean sheet" ISA designed after 1990 (after POWER) that has condition codes. This seems like a prime example of something constrained by 32 bit ARM compatibility -- both porting software, and in the shared pipeline in CPUs that implement both.
On the gripping hand, there are a number of cores that implement ONLY the 64 bit ISA, starting from ThunderX, to Apple's M1/M2, to the latest ARM cores found in for example the Snapdragon 8 Gen 1/2 phone SoCs -- from memory only one of the three core types in those SoCs can run 32 bit code. ARM has said all their future ARMv9 cores will not have 32 bit compatibility.
I think the key test is whether significant features that were seen as problematic in earlier versions have indeed survived. AFAIK almost all were fixed.
Patterson and Henessy comment as to how different (better) ARM64 is when compared to previous versions!
>Of course, bot x86 and Arm started like that as well - but after 20+ years of evolution, they have to drag along a lot of history. (and one never really takes things away from an ISA, you only add new features, and at best deprecate old ones).
Feature-wise, RISC-V is already about on par and has managed not to become a mess.
Furthermore, unlike x86, ARM has broken binary compatibility several times in the past, and yet failed to use the chance to do anything else than minor adjustments.
ARM has broken binary compatibility many many times.
The first was probably when they took the condition codes out of the hi bits of the PC into their own register, to allow 32 bit addressing instead of 26 bit addressing, thus nuking all the software that thought (as it was encouraged to!) that saving and restoring the PC also saved and restored condition codes.
After Thumb mode was introduced they've waffled over whether you must use only BX to change modes, or whether any instruction that writes to PC (mov, add, pop ...) is ok.
Thumb only CPUs such as Cortex M3/M4/M7 can't run code from e.g. ARM7TDMI. The Thumb mode stuff will work, but it's not a complete ISA. On ARM7TDMI you have to switch to ARM mode for many things, while on ARMv7 you need additional instructions that don't exist on ARM7TDMI. CM0 adds only the essential operations to Thumb1, while M3/M4/M7 add basically a complete re-encoding of ARM mode -- minus conditional execution on every instruction.
In Thumb mode on ARM7DTMI (and successors) a 4 byte `BL` instruction is actually two 2-byte instructions run one after the other. You can separate them with arbitrary other instructions between them, as long as LR is not touched. In ARMv7 `BL` looks the same, but you can no longer split the two 2-byte halves -- it is now actually a 4-byte instruction, and other 4-byte instructions exist using the same initial 2 bytes.
And of course Aarch64 is utterly incompatible with any of the 32 bit ISAs. Early 64 bit cores from ARM also ran 32 bit code. At first they could boot 32 bit OSes, then only 64 bit OSes but they could run 32 bit user code. The latest ARM cores run only 64 bit code, and ARM has said no future 64 bit cores will run 32 bit code at all. Other 64 bit only cores also exist, including the ThunderX (9 years ago!) and Apple's M1 and M2 as well as all iPhones starting from the iPhone 8.
ARMv8 aarch32 is backwards compatible with v5-v7 but aarch64 mode cannot run aarch32 code of any kind. ARMv8 makes supporting aarch32 mode optional too and so it really is a hard break.
A while back, I read a Sun patent on not implementing some instructions and emulating them in the kernel's illegal operation trap handler. The whole patent seemed obvious to me, but I'm glad that it was patented and now expired, providing obvious prior art in any attempts to patent it today.
For MIT's 6.004 "Beta" processor loosely based on the DEC Alpha AXP, our test cases ran with a minimal kernel that would trap and emulate multiply, divide, etc. instructions using shifts and adds/subtracts, so we could implement more simple ALUs and still test the full instruction set.
In any case, particularly in the world of hypervisors, it doesn't seem too hard to deprecate an instruction and stop implementing it in hardware, and push that complexity into firmware. As long as the CPU covers the Popek and Goldberg virtualization requirements, hypervisors could be nested, and the firmware could implement a lowest level hypervisor that handles unimplemented instructions.
More generally, I wish ARM64, RISC-V, and other modern ISAs had taken DEC Alpha AXP's idea of restricting all of the privileged instructions to the firmware (PALCode in the Alpha's case) and basically implementing a single-tenant hypervisor in the firmware. The OS kernel always used an upcall instruction to the hypervisor/firmware to perform privileged operations. In other words, the OS kernel for Alpha was always paravirtualized. (UNSW's L4/Alpha microkernel was actually implemented in PALCode, so in that case, the L4 microkernel was the firmware-implemented hypervisor and the L4 syscalls were upcalls to the firmware.) As it stands, hypervisors need to both implement upcalls for efficiency and also implement trap-and-emulate functionality for OS kernels that aren't hypervisor-aware. The trap-and-emulate portions of the code are both lower performance and more complicated than the upcall handlers. Both hypervisors and OS kernels would be simpler if the platform guaranteed a hypervisor is always present.
Always having a firmware hypervisor also allows pushing even more complexity out of hardware into the firmware. The Alpha had a single privilege bit indicating if it was currently running in firmware/hypervisor (PALCode) mode, and the firmware could emulate an arbitrary number of privilege levels/rings. The Ultrix/Tru64 Unix/Linux firmware just emulated kernel and user modes, but the OpenVMS firmware emulated more levels/rings. x86's 5 rings (including "ring -1/hypervisor) could be efficiently emulated by hardware that only implements ring -1 (hypervisor) and ring 3 (user mode).
Edit: Taken to an extreme, you get something like Transmeta's Crusoe that pushed instruction decoding and scheduling into a firmware hypervisor JIT that works on the processor's microcode level. In retrospect, it seems that Crusoe went too far, at least as far as early 2000's technology could go. However, there's still plenty of optimization space in between the latest Intel processors on the extreme hardware complexity side and Transmeta's Crusoe on the extreme firmware complexity side.
Edit 2: In-order processors like (at least early) Intel Atom, P.A. Semi's PWRficient, and Transmeta's Crusoe tend to be more power-efficient. If the architecture designed for it, I could see a case for limited out-of-order hardware capability with hardware tracing and performance counters/reservoir sampling of instructions that caused pipeline stalls. The firmware could then use run-time information to JIT re-order the instruction streams in hotspots that weren't well-served by the hardware's limited out-of-order execution capacity. This might be a viable alternative to ARM's big.LITTLE, where the firmware (or kernel) kicks in to provide a performance boost to hotspots when plugged in, and executes as a simple in-order processor when lower power consumption is desired, without the extra complexity of separate pairs of cores for performance and efficiency. Hardware sampling of which speculations work out and which are wasted would presumably guide the firmware's attempts to efficiently re-optimize the hot spots.
> I wish ARM64, RISC-V, and other modern ISAs had taken DEC Alpha AXP's idea of restricting all of the privileged instructions to the firmware
This is already possible on RISC-V to some extend, by trapping privileged instructions into upper privileged modes. Everything in the ISA is made so it may be achieved cleanly. It also does not allow to detect current privileged mode, so the kernel running in U-mode and trapped on each privileged instruction would never know it's actually not in S-mode.
There is even a software-based hypervisor extension emulator based on that, that brings KVM to non-hypervisor-capable HW: https://github.com/dramforever/opensbi-h
Right, but it's cleaner and better performant to use higher-level upcalls to the hypervisor rather than trapping and emulating every privileged instruction.
As it stands, the hypervisor needs to implement both trap-and-emulate and upcall handlers, and OSes need to implement both running on bare metal and (if they want to perform well on hypervisors) hypervisor upcalls.
If you want your hypervisor to support nested hypervisors, then I guess you'd still need to implement trap-and-emulate in the hypervisor to allow running a hypervisor on top. However, you at least remove the dual paths in the OS kernel if you just disallow the bare-metal case. This also allows a bit more flexibility in hardware implementation as you can change the hardware implementation and the instruction sequence in the hypervisor without needing to modify any legacy OS kernels.
>A while back, I read a Sun patent on not implementing some instructions and emulating them in the kernel's illegal operation trap handler. The whole patent seemed obvious to me, but I'm glad that it was patented and now expired, providing obvious prior art in any attempts to patent it today.
I understand opensbi runs in M mode, taking on that role among others.
That's a cool achievement, but I imagine the single-switch decoder is a bit of a limiting design factor if this project grows (disabling/enabling instructions will introduce branches everywhere, and that's needed for proper FPU conformance).
Also a bit jealous of how it is so popular by just presenting that Doom runs on a minimal ISA subset, while the VM that literally outperforms QEMU was around for much longer. I definitely should time-travel back and tell myself from 2021 to just show off people Doom, since I was doing the same in my communication circles back then xD
I agree a lot, but RVVM implements an API to register new instructions at runtime, so I wanted to leave the core sources as much understandable and macro-free. Plus I don't see how other switch-based approaches in QEMU, or near-mentioned mini-rv32ima are better, so there is no really any ground I could compare upon.
I guess about 1K lines for a hugely-performant, readable and extendable interpreter, which itself does calls into a tracing JIT is a fine trade-off to change it at this point)
You're not allowed to use branding material of the RISC-V foundation to advertise your personal project. I suggest removing the logo to avoid your repo being taken down.
This is not commercial and the terms for the logo is:
“(..) The RISC-V trade mark or the RISC-V logo may be freely used for non-commercial research
and academic projects as long as the guidelines below are followed. Individual members
may not use the RISC-V trademark for commercial purposes (..)”
Basically there are few design choices where it's substantially different to QEMU.
Performance-wise:
- Instead of a static translate-and-run flow like in QEMU, RVVM has an interpret-trace-run execution loop which is remotely similar to JVM, and allows to collect some data like branch probabilities and hot loops, and optimize better
- Using a hardware host FPU instead of softfp emulation. This is like, 10x faster with some synthetic FPU benchmarks
- Conscious decisions for beneficial trade-offs, like fast-path JIT trace cache, JIT IR is more streamlined to "Big ISA Triad" (RISC-V, ARM64, x86-64), etc
Infrastructure-wise:
- A public library API for a lot of things: Machine management (Construct and run 'em in any program), device integration, registering new CPU instructions, userspace emulation
- Subjectively, a more lean and clean codebase, in places where it wasn't harmed by either 1) performance decisions to copy-paste or restructure things 2) complexity of related things like JIT backend arches
- Portability. RVVM officially runs in WASM, runs on Haiku, SerenityOS, KolibriOS, even DOS!
So yeah, while I can't say for sure it's the fastest RISC-V VM, but if we had a bunch more contributors and a bit more popularity it could definitely take a part of the QEMU crown (For things like distro building and god knows what else).
There are a few other differences here & there, but they aren't as much worth mentioning. Do you believe I should make some kind of QEMU/RVVM comparison anywhere in the repo? It seems kind of selfish to present it like that...
It's supposed to be faster, smaller, and easier to integrate into other applications and systems than QEMU. In my tests it's sometimes faster and definitely smaller and simpler.
I think it's also easier to build as WASM and run in a browser.
I don't think 100% feature parity with QEMU is a goal.
I had the exact same question. I do like this - it's nice and ambitious to build something like this from the ground up. Looking at the todo list though, they still have quite some work to get to parity with qemu...
Starfive Visionfive 2 looks to be in stock on Ameridroid and Kickstarter? Pine's Ox64 says it will restock "in March". Last I checked, Clockwork Pi was also selling their RISCV modules separately for ~$20. If you're willing to play with RV32, there are quite a few MCU boards available - CH32V003, BL602, ESP32, etc. Many ARM SBCs also have a RISCV MCU built in, but I haven't seen any docs or reports of anyone actually using the "mailbox" mechanism to run code on it. If nothing else works, get a cheap FPGA and run a softcore?
Right now, yes. Sipeed LP4A (and other TH1520 boards) should be close to 2x the speed, certainly if run with cooling to permit the rated 2.5 GHz speed, in April or May maybe. For around $100. And the SiFive "HiFive Pro" maybe 1.5x faster again in late summer, though probably quite a bit more expensive.
That comment is actually a good politically-neutral illustration of a major force underpinning today's political hyper-polarization: people simply can't handle the mere existence of something they don't like and will respond by shunning entire bodies of work or attacking people unnecessarily.
This is definitely new as in the last 10-15 years. In the past more people seemed able to just disregard or shrug at things they didn't approve of.
We've had eras of profound intolerance before. I think this one might be unique in that it seems universal across the entire political and social spectrum.
Reminds me of [0]. The original poster's account is deleted, but it was "@Christian-Schiffer" — yes, the person who complained about presence of a Christmas-related icon in VS Code had name "Christian". And the VS Code team responded immediately, the icon was removed what, one or two days after the complaint, in an urgently published patch.
I think that people who haven't been raised in such a society don't realize how chilling it is to be afraid to say something wrong and constantly be aware that you could be punished for your words. It makes you unable to even think clearly, lest a slip-of-tongue gets you sent to jail. It's no way to live.
> Is this a “the first as tragedy, then as farce” type of deal?
Definitely. First, cancel culture emerged as a response to genuine concerns about social justice and equity, particularly with regards to marginalized communities. Cancel culture initially sought to hold people accountable for their harmful actions and words, and to create a more inclusive and just society.
However, over time, cancel culture has increasingly become a farcical parody of its original intentions - it has devolved into a tool for online mobs to attack individuals for minor or unintentional offenses, resulting in a culture of fear and self-censorship.
Cancel culture has also been weaponized by some to silence dissenting opinions or to settle personal scores, rather than to advance social justice. See: https://rms-open-letter.github.io/ for a recent example.
It's very hard to believe you. Comparing life under a dictatorship with somebody asking to change an icon without having any power to impose their will.
There doesn't have to be a direct tangible threat for people to act on impulses they were taught through a direct tangible threat (see: learned helplessness [0]). That's the way reinforcement learning works on humans, otherwise there would be no concept of ethics - ethics itself is based on generalizing a basic set of rules learned through punishment and reward.
The power is there, because it had an effect on reality, whether you admit it or not. The person has indeed asked, but consider what would happen if the person asked for the whole repository to be deleted, for example, because they personally didn't like the RISC-V architecture: the request would probably not be fulfilled. But the request for removing the cigarette emoji was followed - why? What's the difference between the two?
My theory is that the ratio between the learned "threat" and required effort to avoid the "threat" was low enough to warrant the action. Assuming the effort is a constant (editing a single text file and pushing it to GitHub == removing the repository; ~same amount of clicks), that means that the learned "threat" was high enough to warrant the deletion. The threat comes from the cancel culture that glorifies anyone that presents themselves (or others) as victims. In case of the second - hypothetical - request, there is no such threat, so the request itself would be rendered bizarre and selfish.
> My theory is that the ratio between the learned "threat" and required effort to avoid the "threat" was low enough to warrant the action.
We can also take the more charitable interpretation: the repo owner saw the post asking for it to be removed, thought "yeah, wow, you're right, cigarettes do suck, and having it there is unnecessary and doesn't actually add anything valuable, so I might as well change it to something else".
Or, hell, we could even go out on a limb: "oh wow, I didn't realize someone might be offended by that, but I'll change it because I have no feelings about it being there whatsoever, and I don't want my project to make someone feel bad". Cuz, y'know, empathy is a thing.
(The cigarette emoji was in front of the "Tell me more..." heading; I'm having a hard time coming up with a reason for it to be there in the first place.)
I do agree with you that cancel culture has gotten out of hand, and some people will make the calculus you describe in some situations, but that seems a bit too much here. I doubt anyone is going to get cancelled over a cigarette emoji in a README, and it seems overblown to assume the repo owner made the change out of fear. (Famous last words, I know, but I stand by that.)
Alternatively, maybe the project authors decided that the cigarette imagery was (1) bothering somebody, and (2) did not matter to the identity of the project and was easily removed, so they decided to honor the request. It's probably what I would have done.
Conversely, I was the author of a project whose namesake and mascot was an animal considered unclean by several world religions. Nobody ever asked me to change it, but I probably would have refused, because in this case, it was tied too much into the identity of the project.
This is exactly what happened. I never though much about the imagery, it was a 5-min commit to "make README look nicer", and I actually have asthma as well (Never been much around smokers so maybe I don't have such terrible associations). So it's much more of a, heh let's honor this random person request since I don't care much in the first place, and even if it's a little weird to trigger at the icon, I can kind of see why.
> people simply can't handle the mere existence of something
Unlike the previous say 2000 years of history, where societies around the world were very tolerant, especially of different religions, cultures, lifestyles etc /s
No? Then please don't be silly. xiphias2's request might be strange and even mildly annoying but modern society does NOT have a problem of anti-smoker extremists organizing hangings in the town's square.
> modern society does NOT have a problem of anti-smoker extremists organizing hangings in the town's square.
You are missing the point. The xiphias2's request was not anti-smoking in any way (I doubt they even volunteer in any anti-smoking rallies in their own community) - it was purely masturbatory, using victimhood as a cover for forcing their own will upon a repository that they didn't even have to look at, and which definitely didn't celebrate smoking in any way a reasonable person would recognize.
Victimhood is not supposed to provide you with power (at least not without proper verification), otherwise it provides a perverse incentive [0] for anyone to pretend they're victims in order to gain influence over things that they otherwise wouldn't have.
xiphias2 asking to remove a cigarette icon, nothing more and nothing less. Without any power whatsoever to force the repository owner. There is no Icon Police around.
> anyone to pretend they're victims in order to gain influence over things that they otherwise wouldn't have
You are implying that people have an undue influence over society, which includes you AKA you are painting yourself as the victim of xiphias2 alleged victimhood.
Again, there is no Icon Police around, don't be scared.
This may be new in the last 10-15 years, but let's not forget why that icon appeared there: because of the huge marketing budget spend created by tobacco companies to make smoking look cool instead of something that kills millions of people slowly.
I'm not a smoker and don't want smoking anywhere near me, but I don't think it's fair to assume it's just advertising. Smoking is enjoyable for many people and makes them feel good. It's also been in use as far as history records, long before advertising budgets and big tobacco.
It's not new, and it's not "profound intolerance", jfc. Cigarette advertising has been banned on American television since at least the 1980's, and it's generally been taboo to depict unnecessary cigarette usage in TV shows and movies for at least as long. This has actually been extraordinarily effective as part of a multifaceted effort to reduce cigarette usage and the resulting diseases.
And yes, people have been complaining about it on civil libertarian grounds at least as long. Which is fair enough.
But if you want to see some actual __intolerance__, you might look at what's happening in Florida.
> Cigarette advertising has been banned on American television since at least the 1980's, and it's generally been taboo to depict unnecessary cigarette usage in TV shows and movies for at least as long
Fight Club was recorded in 1999, and it explicitly shows a scene of Tyler Durden smoking a cigarette, so I doubt your claim has any substance to it.
> But if you want to see some actual __intolerance__, you might look at what's happening in Florida.
If you want to actually enlighten anyone, you might want to provide more information than "what's happening in Florida". There's a lot of things happening in Florida in any given moment, so I have no way of knowing what you're referring to.
