Virtual Machine Design and Implementation in C/C++

wackybrit writes: "The concept of the virtual machine is one of the most important concepts in computer science today. Emulators use virtual machines, operating systems use virtual machines (Microsoft's .NET), and programming languages use virtual machines (Perl, Java)". Read on for his review of Virtual Machine Design and Implementation in C/C++, an attempt to examine and explain virtual machines and the concepts which allow them to exist. Virtual Machine Design and Implementation in C/C++ author Bill Blunden pages 670 publisher Wordware Publishing rating 9 reviewer Peter Cooper ISBN 1-55622-903-8 summary An in-depth look at virtual machines, assemblers, debuggers, and system architecture in general.

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 Summary

Released 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

1. History and Goals
2. Basic Execution Environment
3. Virtual Machine Implementation
4. The HEC Debugger
5. Assembler Implementation
6. Virtual Machine Interrupts
7. HEC Assembly Language
8. 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.

Comments

Virtual Machine

[JohnHegarty]

Can anyone give me a substantial difference between a virtual machine, and an emulator...

because I can't see whats different between my mame and java virutal machine...

Re:Virtual Machine

[Anonymous Coward]

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.

thank you!

[jeffy124]

I must say I'm pleased to hear about this book. I actually would like to do something with VMs in my upcoming academic life (read: grad school), but am having trouble getting started, nor am sure if this is what i want to study. Every search engine out there returns everything Java for the phrase "virtual machine," which is not exactly what I'm looking for.

Why *virtual* machines?

[Anonymous Coward]

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...

Re:Operating Systems

[queh]

Define operating system. Don't mix it up with boot loaders or kernels. Now explain how Microsoft's .NET isn't an operating system.

Take a Further look at this!

[idfrsr]

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.

Why are current VMs preoccupied with GC?

[Anonymous Coward]

It seems that everyone assumes that VMs these days (JVM, CLR, Mono, Parrot) must include garbage collection and not use pointer-based ops. Why is that? Knuth's MMIX VM is modelled after a traditional RISC CPU which modern compilers like GCC can target. C, C++, FORTH, Objective C can be targetted toward it out of the box.
I think that VMs these days are getting bloated with everything including the kitchen sink. This makes them harder to port and test. Performance suffers. What ever happened to keep it simple stupid?

Another use

[Erbo]

Another thing virtual machines have historically been used for is to assist in the development of new computers, by creating a perfect model of the new computer's hardware in software, so the microcode authors (and maybe the OS authors, too) can get their code working before the hardware's completely debugged. In this guise they're called "simulators," and there was mention of them in Tracy Kidder's seminal work The Soul of A New Machine. As the book says, "A simulator makes a slow computer, but a fast tool."

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

Low-resolution thread concurrency?

[magi]

Are there any VMs currently, for Java, Python or some other language, that can execute each thread one VM instruction at a time?

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:

par:
for a in range (0, 3):
print "a = %d" % (a)
for b in range (0, 3):
print "b = %d" % (b)

As the two threads would be executed exactly at the same speed, the output would be:

a = 0
b = 0
a = 1
b = 1
a = 2
b = 2

Re:Low-resolution thread concurrency?

[Anonymous Coward]

You're assuming print is atomic.
The output would more likely be:

a =b 0
a= 0
b= =1
a1
b =
= 2
2

Occam is an interesting language, but I think it has a too restrictive view. No global variables, no mutexes, everything uses channels - even shutting down a multithreaded Occam program is a major pain in the ass - message passing nightmare.

Re:Operating Systems

[Tikiman]

I don't think you read the quote correctly:

Emulators use virtual machines, operating systems use virtual machines (Microsoft's .NET), and programming languages use virtual machines (Perl, Java)".

Microsoft's .NET is an example of a virtual machine used by a particular operating system - there are no claims that .NET is an operating system by itself. Similarly, the Perl and Java programing languages have been implemented on virtual machines - the JVM, and the stack-based (soon to be register-based) Perl virtual machine.

hmm infocom...

[YakumoFuji]

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.