![]() As I summarized in slides 66 to 73 of my Rise Of The Virtual Machines lecture that I gave to an engineering class at Conestoga College in 2012, I want to see a future where we simplify hardware and emulate everything to the point where emulated code potentially runs even faster than the original bare metal it was written for. A couple of posts later ( Part 33) I took a detailed look at the implementation and performance of QEMU and found that QEMU had a lot of problems to solve first in terms of performance and correctness, but problems which I argued then were easily solvable and still claim today can easily be solved.Īnd since 2012, when the instruction set and specs of the Haswell processor were made public by Intel, I have been making the case (as I hopefully convinced you in my past few posts) that Haswell is a terrific processor to do interpretation and binary translation on which to implement some form of VERT. I made another series of posts in 2010 discussing the impact of the iPad and "the coming wave of ARM devices" ( Part 31) how this wave of small non-Intel devices would a game changer, pointing out that a binary translator such as QEMU could be critical to making this happen. I followed up in 2008 with posts on how one would go about implementing such a VERT, and co-authored the paper " Virtual Without Direct Execution" in 2008 to push this idea of emulation based hypervisors, with another paper in 2011 on Microcode Simulation that described a particularly fast implementation of a multiple instruction set direct threaded interpreter. It would allow the creation of virtual instruction sets that were completely decoupled from the underlying hardware. But option #3 is the one that really excited me because it leaves so much wiggle room on both sides of the ISA interface. NET where a virtual bytecode (Java, MSIL) is emulated on existing hardware. Option #2 describes managed runtimes like Java or. So option #1 is basically what Transmeta or Alpha's FX!32 did in the 1990's. This is what emulators like QEMU try to be. Or, do both, have an ability to interface arbitrary instruction sets to arbitrary hardware implementations by having a robust enough VERT that could be retargeted for various guest and host instruction sets.An instruction set I called VX64 that would have fewer crazy effects than legacy x86 but would have much the same functionality as x86. In a later posting ( Part 5) I thought out loud about simpler ways to re-encode x86 such that it would be easier to emit, to decode in hardware, or to emulate in software. ![]() Keep the hardware as-is, but the replace the instruction set that is being emulated.Imagine a version of a Linux GRUB loader that happened to be a VERT and could boot arbitrary x86, 圆4, PowerPC, MIPS, or ARM Linux images on the same system on the same hardware. Replace the hardware implementation with a much simpler architecture, what Transmeta did, but extended to support multiple guest instruction sets.This would allow you to do one of three things: A VERT would be some sort of binary translation and/or interpretation-based emulator that, much like Transmeta's CMS, runs directly on top of bare hardware and could host arbitrary instruction sets. Not my original idea, as I said back in that post I was merely connecting the dots and stating something that seemed obvious to me. In that post I floated the concept of something I called a "VERT", a Virtual Execution Run Time. This is similar to what I've done for almost 30 years every time I work on an emulator, from emulating 68040 for a Macintosh emulator to 6502 for an Atari 800 emulator to simulating x86 in C++ for Bochs. In Transmeta's case they replaced the hardware implementation of x86 with a simpler VLIW RISC-like processor and used a software decoder, as well as an interpreter and dynamic translator called CMS (Code Morphing Software), to emulate x86. Every model of AMD or Intel (or Transmeta or Via or Cyrix) x86 CPU is a slightly different implementation and behaves with different timings and performance characteristic but adhere to the x86 instruction set interface. It is a binary interface, an ABI, and as such one can independently modify the two sides of that interface. It is a bytecode that contains a sequence of instructions for the hardware CPU to execute. An instruction set - whether x86, ARM, PowerPC, 6502 - is just a particular encoding. In one of my first posts in 2007 ( Part 3) I argued that the Intel x86 instruction set should be redesigned. įor the past 8 years in this blog series I have commented on all things related to CPUs, virtual machines, and code optimization.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |