virtual CPU

A virtual CPU is a CPU implemented in software. It is typically executed by an executor (a sort of simulator for the CPU) which runs on a real (host) CPU.

Overview

A virtual CPU is in many respects very similar to a real, physical CPU. A physical CPU runs directly on hardware, in either a soft core or hard core. A virtual CPU also has a defined instruction set (ISA), but is not implemented in hardware, but instead executed in software. The execution is typically done by an executor, a small piece of software (usually between 300 and 1200 bytes) which loads the instructions and executes it in software, meaning that it simulates the behavior of the CPU. However, there is also the option to translate the instruction stream of the virtual CPU into native code, so basically compile on the host, before executing it. This delivers much higher, close to native performance and is what Apple's Rosetta emulator does.

Performance

Performance of the virtual CPU obviously depends on many factors, such as the ISA of the virtual CPU and the implementation of the executor. For well optimized executors, a factor of 10-20 is realistic, meaning that functionality implemented on the host (native CPU) is about 10-20 times as fast as implementation on the virtual CPU. While this sounds like a lot, it is normally not a problem when implementing compute intensive functionality on the host itself. Especially for systems in which the virtual CPU is more powerful than the underlying host the performance factor can be better than 10 since fewer instructions are required. This applies to SWEET16, which implements a virtual 16-bit CPU on the 8-bit 6502 CPU, but also to systems like S32E, especially when running on a RISC-V host.

Code density

Code density of virtual CPU obviously depends on the ISA of the virtual CPU. There is a trade-off between the size of the executor and the code density of the virtual CPU: The more instructions are available, the larger the executor. As a general rule, code density of the virtual CPU is usually higher than that of the host CPU, as virtual CPUs are typically optimized to use fewer instructions. Steve Wozniak claims to have saved about 1KB of program code (out of 5KB) by implementing a part of his basic interpreter in SWEET16, without noticeable performance degradation. Assuming that he "virtualized" half of the program code, that means a 40% code size reduction of the part virtualized. With the 300bytes required for the executor, he still saved around 724 bytes of program size (assuming the SWEET16 executor was only used for this purpose).
Furthermore, modern implementations —like SEGGER’s own S32E virtual CPU running on RISC-V hosts— can yield code size savings around 30%.

Examples

• SWEET16 - One of the first implementations of a virtual CPU. Developed by Steve Wozniak to run on the 8-bit 6502 (Apple II), implementing a virtual 16-bit CPU.
• SEGGER S32E - SEGGER's generic virtual 32-bit CPU. Extremely efficient and very high code density. Used in many SEGGER products such as the Flasher family of in-system programmers, J-Link debug probes and also in emApps, which makes this functionality available to third parties.

Summary Table

Topic	Highlights
What it is	Software-based CPU simulated by an executor with optional native translation
Performance	Host-native execution is 10–20× faster; richer virtual ISAs may reduce instruction counts
Code Density	Virtual CPU ISAs often enable denser code; examples show savings of ~30–40% even after executor
Real-world Examples	SWEET16 (Wozniak, Apple II), SEGGER S32E (used in modern SEGGER hardware and emApps)

FAQ

Q: Can a physical CPU also be "virtualized"?
A: Yes. Every CPU can be virtualized. Virtualizing basically means: Run it in a simulator. However, a simulator needs to be fast, and the CPU should be suited for virtualization. CPUs designed especially for virtualization are usually easy to simulate: Relatively few, simple instructions and typically few or no flags, and only few instructions actually affect these flags. Also the instruction are usually quite powerful in order to minimize the number of instructions, which increases code density and performance.

Q: Can Apps for virtual CPUs be downloaded at run time?
A: Yes. That is in fact what SEGGER is doing in it's J-Link and Flasher products and also the market target with emApps.

Q: Can Apps for virtual CPUs be run on different host CPUs?
A: Yes, absolutely. This is part of the beauty: When the product switches to a new CPU (for cost or efficiency or whatever reasons), the same apps can be executed. If the executor is written in C, all of the code ports can simply be run on any other system.

Q: What is the aproximate performance gain of an assembler vs. C executor?
A: Of course it depends, but around 50-100% higher speed on ASM