Slashdot Mirror
Virtual Machine Design and Implementation in C/C++
Virtual machines are, in effect, a software model of a whole system architecture and processor. They take in bytecode (formed of opcodes, operands, and other data) and execute it, much in the same way a real system executes code. Running these operations in software, however, gives you more security, and total control over how the system works.
Virtual machines are popular for a number of reasons. The first is that they give programmers a third compiler option. You don't have to either go the dynamic interpreted route or the static compiled route, you can compile for a virtual machine instead. Another is that virtual machines aid portability. If you compile your code for a virtual machine, you can run that binary on any system to which the virtual machine has been ported.
Few books have been written on virtual machines, with only a few Java Virtual Machine titles available. Virtual Machine Design and Implementation by Bill Blunden is therefore a landmark book for anyone with an interest in virtual machines, or even system and processor architecture as a whole.
What's to Like?Blunden makes sure to cover every topic related to virtual machines in extreme depth. The beauty of this is that you're not left in the dark, but that experts can simply skip sections. The book is well divided up, and off topic rants or notes are clearly marked with dividers. This is an easy book to read, even though it runs to some 650 pages.
To lead the reader through the entire production of a virtual machine, Blunden showcases the development of his own 'HEC' virtual machine (HEC being one of the fictional companies in 'CPU Wars'). Initially he starts slowly, and introduces the reader to how CPUs work, how memory works, how paging works, and how almost any other system process you can imagine works. Nothing is missed out. Multitasking, threads, processes, porting.. he covers it all. This is excellent for those new to some of these topics, and makes this an advanced book that's actually quite readable by someone with a modicum of computer science experience.
After laying down the foundations for the design of the virtual machine, the actual development starts in Chapter 3. All of the code in this book is in C or C++, and nearly all of the code is talks about is actually printed on the right pages in the book. No more flipping between code on your computer and the book, it's all just where it should be!
Further on in the book, a number of extremely advanced concepts are introduced, but even these need not be out of the reach of an intermediate programmer. Blunden presents the most vivid insight into how assemblers and debuggers are created, and the book is worth it for this information alone.
Another important thing about this book is that it looks at creating a register based virtual machine. Stack based virtual machines are covered, but the author makes a compelling argument for using registers. This makes a refreshing change from the Java Virtual Machine books that ram stack based theory down your throat. It's also useful if you're interested in the Perl 6 'Parrot' project, which is also an in-development register based virtual machine, and bound to become rather important over the next few years.
What's to Consider?Virtual machines aren't for everyone. If you're a high level programmer working with database apps, this isn't really for you. This book is primarily for system engineers, low level programmers, and hobbyists with an interest in compilation, assembler, and virtual machine theory.
This is not a book for beginners. You need to have a reasonable knowledge of C to understand the plentiful examples and source code in the book. C++ is also useful, although OOP is clearly explained, so even a standard C programmer could follow it. That said, this is an excellent book for intermediate programmers or computer science students, as a number of advanced topics (garbage collection, memory management, assembler construction, paging, token parsing) are dealt with in a very easy to understand way.
The SummaryReleased in March 2002, this book is extremely up to date. This is good news, as virtual machines are clearly going to take up a good part of future compiler and operating system technology, and this makes it important to learn about their construction and operation now. These technologies are already in the marketplace; Microsoft's .NET, and JVM, for example. Perl 6's 'Parrot' is also going to become a big player, with languages like Ruby, Python, and Scheme being able to run on it in the future.
Whether you want to learn about system architecture, assembler construction, or just have a reasonably fun programming-related read, this book is great.
Table of Contents- History and Goals
- Basic Execution Environment
- Virtual Machine Implementation
- The HEC Debugger
- Assembler Implementation
- Virtual Machine Interrupts
- HEC Assembly Language
- Advanced Topics
You can purchase Virtual Machine Design and Implementation in C/C++ from bn.com. Slashdot welcomes readers' book reviews -- to submit yours, read the book review guidelines, then visit the submission page.
An emulator is a virtual machine with a pre-existing non-virtual counterpart.
Zuccotto and a few other companies have done just that...the JVM is an actual hardware chip. There were at least 5 companies doing the same at Java One
Never by hatred has hatred been appeased, only by kindness - the Buddha
A virtual machine is designed specifically to be general and run in different environments, whereas an emulator is designed to emulate the environment of some existing hardware or software to trick software into beleiving that it genuinely is running on the original device.
So, whereas a virtual machine will have a fairly abstract policy towards doing things (compare Java's AWT - I'd like to open a window, I'd like a button here, I'd like a menu there) and an emulator will get really bogged down emualting details, e.g. memory address $DFF180 changes the background colour.
Both can be easily emulated by a state machine (hence why they come up in this book), however virtual machines can be made more efficient as they are intentionally abstract. e.g. in the JVM, you know what is code and what isn't, so you can translate blocks of code into native machine code and run that directly instead of interpreting every instruction. If you try that with an emulator, you'll come unstuck when you come across self-modifying code, or things that access memory mapped registers (e.g. on a 68000 the instruction mov d0,4(a0) offers no clue as to whether the write is to hardware or memory.
Generally, you'll find that most virtual machine designs aim to reduce the instruction set down to a bare minimum. This allows a virtual machine (if it chooses) to effectively re-build the original parse tree and generate native code. However, emulators are generally trying to emulate CISC processors where as much is squashed into an instruction set as possible. Similarly, most virtual machines are heavily stack based, so as not to make any assumptions about register availability.
Implementing a stack-based machine in hardware is straightforward, and has been done many times. The first one was the English Electric Leo Marconi KDF9, in 1958. Burroughs followed, and thirty years of Burroughs stack machines were sold. Java has a small implementation of the Java engine in hardware. Forth chips have been manufactured.
But all these machines have used sequential execution - one instruction at a time. Nobody has yet built a stack machine with out-of-order execution. There's been a little research in this area. Sun's picoJava II machine has some paralellism in operand fetches and stores. But nobody has wanted to commit the huge resources needed to design a new type of superscalar processor. The design team for the Pentium Pro, Intel's first superscalar, was over 1000 people. And that architecture (which is in the Pentium II and III) didn't become profitable until the generation after the one in which it was first used.
In the end, a superscalar stack machine probably could be designed and built with performance comparable to high-end register machines. For superscalar machines, the programmer-visible instruction set doesn't matter that much, which is why the RISC vs. CISC performance debate is over. But so far, there's no economic reason to do this. Sun perhaps hoped that Java would take off to the point that such machines would make commercial sense. But it didn't happen.
Are there any VMs currently, for Java, Python or some other language, that can execute each thread one VM instruction at a time?
if you have a language that optimizes tail-calls, you could have the front-end of the language convert the separate threads of execution into continuation-passing style, and then execute the code one continuation at a time, simulating threading on a VM level. if i remember correctly, the scheme48 VM could do that kind of threading, though on a coarse level.
in CPS a function decomposes into a sequence of more primitive functions, each returning a continuation, ie. a handler for computation yet to come. for a simplified example, the evaluation of (+ (* 2 3) (* 4 5)) would evaluate (* 2 3) into 6 and return a continuation that evaluates (+ 6 (* 4 5)), which in turn would evaluate (* 4 5) into 20 and return a continuation that evaluates (+ 6 20), and that would finally evaluate to 26.
but the point here is that one could explicitly halt the evaluation after receiving the first continuation, store it on the queue, and go off and compute something else. after a while you can come back, pop the continuation off the queue, and pick up the computation where you left off.
the problem with such a setup is that it makes optimization difficult. i'd suggest looking at the CPS for more details...
My other car is a cons.