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.
Some alternate titles for this tome might be:
1. Reversi: C64 Speed on a Pentium IV
2. Double Your Code, Halve Your Speed
3. Real Men Don't Use Real Computers
4. VM:Very Macho or Verily laMe
5. Atari ST Rebirth: a 20 Year Reversal
etc., etc.
Ack, I'm turning into a crank! Oy.
Everything in the Universe sucks: It's the law!
One of the things that has surprised me about virtual machines ever since Java became a buzzword was that no one had ever thought to eliminate the relative performance penalty by implementing the VM as hardware on a PCI card (or a licensed chipset to put on the mobo. I can understand the portability implications of using VM's, and I'm glad that much work is being developed in this area.
My question to anyone qualified to comment: Is there a reason why these virtual machines aren't taken as a blueprint for real hardware and implemented as such? I can imagine real performance benefits happening with such an idea...
An emulator is a virtual machine with a pre-existing non-virtual counterpart.
An emulator is a specific type of virtual machine. VMs don't necessarily reproduce a real machine, while emulators do. Also, many emulators reproduce the original machine down to the timing of instructions.
For example, some of the nuclear power plants here in Canada are using or switching over to an emulator to run the plants because they are running out of spare parts for their 1972 control machines. Without the use of an emulator, they'd each have to rewrite shelves and shelves of assembler code.
You can imagine that some of the code is timing critical, so the emulator must be exact down to the timing.
I program in Java mostly right now, and so when people begin the usual 'vm is slow' crank I am curious about what they exactly mean.
Programs written to run on vm's can be significantly slower due to the extra layer. Yet, if the design of the vm is done well enough (by perhaps reading this tome?) then the vm should be comparable. Certainly C is faster generally than an interpreted language. But there are native compilers out there than provide very comparable results, and the advantage of a language that forces careful programing. Here is the slashdot link
If adding layers to programs automatically makes them slower, and so slow that they are useless, we all would code in assembly.
Good design is important. A badly written C program of which there are thousands, will be just as slow (read bad) as a badly written vm program.
"The large print giveth, and the small print taketh away" -Tom Waits
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.
Also, don't forget the UCSD P-System, which used a virtual machine to run code compiled in that environment. I know of at least one commercial product that used the P-System; I believe there were many.
Virtual machines have been around awhile; they're an interesting field, made newly relevant by the ascendancy of environments such as Java and the MS CLR. I just wish I had a good excuse to drop $50 on this book...:-)
Eric
Be who you are...and be it in style!
It would also be nice to have language-level support for parallel processing, like in Occam.
For example, in a Python implementation, the following code would execute the two for-statements in the "par"-block in parallel:
As the two threads would be executed exactly at the same speed, the output would be:
People had said for a long time that personal computers connected to file servers was a lower-cost, better system. However, now many places are going to web-based or host-based connections because of buggy issues at the desktop and the unmanageability of the personal computer. Couple this with the fact that licensing manangement is such a bear and you see why us Unix folks are glad to see the turn-around.
Mainframes had been on their way out before the personal computer, in favor of smaller satellite processing via minicomputers. However, now people are realizing that virtual computers in a big iron case gives you a better managed array of computing power for multiple users or processes. I for one welcome this back, and hope that we will continue to see vitual computing take over the personal computer business market approach. Bring in the network computers!
Click here or here.
but does it cover infocoms famous zmachine VM, which runs on more hardware than any other virtual machine ever... (considering it can run under java as well.. a vm runnnig a vm!)..
or magnetic scrolls 68k VM, that that even ran on the c64 with its mighty 8bit chip, was emulating the 16/32bit 68K!
aaah long live interactive fiction and virtual machines.
no sig for you
For instance, if you were to make a Pentium emulator to run on a 486, then many of the instructions could be executed as-is by the hardware. Most register values could be stored in actual registers. And so on.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
one thing to remember is that the microsoft .net infrastructure does not run on a virtual machine!
.net support libraries. there is no interpreted code execution going on, and indeed, the IR is not optimized for interpreted execution. hence, there's no virtual machine running, unlike in the case of Java or other bytecode interpreters.
.net code (c#, etc.) compiles down to a standard intermediate language, which gets JITted into machine code, and linked to
.net is not a virtual machine any more than gcc is a virtual machine.
My other car is a cons.
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.