Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RVVM – The RISC-V Virtual Machine

github.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: RVVM – The RISC-V Virtual Machine

#61

Post by LekKit »

KMag wrote: post #24
bippingchip wrote: post #5

Earlier quoted context omitted.

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…

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 a…

> 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

Re: RVVM – The RISC-V Virtual Machine

#62

Post by firstlink »

klelatti wrote: post #20
bippingchip wrote: post #5

Earlier quoted context omitted.

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…

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.

Re: RVVM – The RISC-V Virtual Machine

#63

Post by KMag »

LekKit wrote: post #61
KMag wrote: post #24

Earlier quoted context omitted.

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 a…

> 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 trappe…

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.

Re: RVVM – The RISC-V Virtual Machine

#64

Post by klelatti »

firstlink wrote: post #62
klelatti wrote: post #20

Earlier quoted context omitted.

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 ex…

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!

Re: RVVM – The RISC-V Virtual Machine

#65

Post by actionfromafar »

LekKit wrote: post #60
actionfromafar wrote: post #49

Earlier quoted context omitted.

So is this, even more so in my taste: https://github.com/cnlohr/mini-rv32ima/blob/master/mini-rv32... A RISC-V emulator in one include file.

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 d…

Well, the next best thing is to show it now running Doom! Or Quake.

Re: RVVM – The RISC-V Virtual Machine

#66

Post by brucehoult »

firstlink wrote: post #62
klelatti wrote: post #20

Earlier quoted context omitted.

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 ex…

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.

Re: RVVM – The RISC-V Virtual Machine

#67

Post by brucehoult »

snvzz wrote: post #40
efficax wrote: post #15

are there any risc v sbcs out there that are actually available? every one i look for is out of stock. i’d love to play around with a real chip

VisionFive 2 is the fastest money can buy while also being under $100, making it about the automatic choice today.

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.

Re: RVVM – The RISC-V Virtual Machine

#68

Post by brucehoult »

chungy wrote: post #42
snvzz wrote: post #38

Earlier quoted context omitted.

>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…

Pretty sure ARM has never broken binary compatibility, even across ISA expansions (16→32 bit, 32→64 bit).

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.

Re: RVVM – The RISC-V Virtual Machine

#69

Post by goodpoint »

bheadmaster wrote: post #48
goodpoint wrote: post #34

Earlier quoted context omitted.

> 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…

> 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 wh…

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.

Post reply on HN