Lost in Translation
Another approach to virtualization is to provide the entire ABI environment to maintain binary compatibility. Instead of virtualizing just the OS, an ABI VM virtualizes an entire ISA and any calls to the OS. The classic example of a ABI VM is the Alpha’s FX!32, which allowed Alpha systems to run binaries compiled for x86.
Figure 9 – FX!32 on Alpha, with Alpha NT
In general, there are two different methods of executing instructions from an emulated or virtualized ISA. The first method is to have an interpreter that runs on the native ISA and fetches, decodes and executes instructions from the guest ISA. Unfortunately the overhead associated with an interpreter is fairly high and relatively constant; each guest instruction usually requires several native instructions, which is fairly inefficient. One example of interpretation is the x86 hardware compatibility layer in the Itanium 2, which unintelligently translated x86 instructions into IA64 groups and bundles. The alternative to interpretation is binary translation, which is a more intelligent and sophisticated solution. Under this scheme, entire sets of guest instructions are transformed into blocks of native instructions that perform the same task. There is a high cost for the first transform of guest to native instructions, but blocks of translated instructions can be cached for future use, avoiding the computational costs of on the fly translation. The advantages of binary translation over interpretation are actually very similar to the tradeoffs between trace caches and decoders. Decoders are much like interpreters, with a constant but high performance costs, whereas trace caches and binary translators manage to reduce the work dramatically by intelligently decoupling the translation and execution process. The difference can easily be seen by comparing the expected performance of Intel’s IA32 Execution Layer versus the hardware compatibility layer; nearly a 3x expected performance improvement.
However, an ABI also includes system calls. As Figure 9 shows, in a situation where the guest ABI has the same OS as the host ABI, everything is relatively simple; system calls can be made, with minor modifications to the host OS. However, when the guest applications make calls to non-native OSes, another layer of VM software is required. VMs designed to host a non-native ISA and OS, such as the Charon VAX environment are called whole system VMs. Unfortunately, the conversion of system calls from one proprietary OS to another is difficult at best, unless all of the products are controlled by the same company.
Out of Sight, Out of Mind
Typically, translation and replication VMs are designed as a solution to an existing problem. For example, Charon VAX was designed to allow VMS or Windows 2000 users to fully emulate a MicroVAX II, 3000 or 4000 system, so users could transition to newer platforms. These sorts of VMs are designed to solve a problem, with the hope of minimizing the performance penalty. However, some VMs are intended to optimize performance, power consumption, or some other particular feature by fully masking the underlying ISA and hardware. These Co-Designed VMs are created in tandem with the hardware they run on, such as the AS/400 or Transmeta’s Crusoe and Efficeon, and never expose the underlying resources. The VM runs in a dedicated portion of memory that is hidden from any guest software, and is responsible for binary translation, interpretation and VMM resource allocation. This grants the VM the flexibility to control the entire environment, which has quite a few benefits. In the case of Transmeta, the result is substantial power savings, as the VM intelligently optimizes software and hardware usage based on power consumption. For the AS/400, the advantage was total independence of the software environment from the underlying hardware. This allowed IBM to transition customers in a truly seamless fashion between older CISC based hardware and the newer Power based systems; a feat that has only been replicated by a few other vendors.
Be the first to discuss this article!