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.
Mainstream operating systems which drop support for the virtual machines?
dmarien
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...
Cruise TT
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.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
Inside my virtual machine, where then I can run some sort of virtual reality program where I can interface with Eliza.
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!
virtual machines are leet because you can test your virus code without actually damaging your own system. Unless you're clueless, in which case you'll probably infect yourself and the rest of the internet and get ass raped in prison.
Linux is dead.
LU
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...
Dear sir, That was one of the most informative posts I have seen on Slashdot in a long time, perhaps since the days of TheGloriousMeept! It truly captures the spirit of discussion. Thank you again kind sir, me
C/C++ (for use in enterprise apps) is already being outdated because of Java. .NET (and it's oss clones) is really just a mocking of Java and the J2EE.
.class files, allowing you to throw the .class files into a JVM like it were a Java program, and allowing easy interfacing with a Java program.
also, perl is a VM. It compiles into bytecode, then executes the bytecode. Perl 6 is actually supposed to be able to compile Java
So you want more info on searching on virtual machines on Google, not using Java ?
Search on : "virtual machine -java"
It's simple & off topic.
Cheers,
T.
The same is true of virtual machines. Simulating how a computer might react to certain error codes and so forth is all right in small doses, but the only way to get real data is go out there and buy some actual hardware.
Just my $.02.
Define operating system. Don't mix it up with boot loaders or kernels. Now explain how Microsoft's .NET isn't an operating system.
Um, no. It is an implementation written in c/c++ (as opposed to Fortran for instance...) not a VM for c/c++.
Well, not yet at least.
.NET is still in the works.
Lets remember, XP is kinda like ME in the sense that it's just an interface update. The actual OS behind XP is essentially just Win2k. 'Whistler' AKA
I'm actually interested in seeing what it's like, in all seriousness, I've heard M$ programmers refer to it as MS UNIX. I can only imagine what that means...
Linux is dead.
LU
The Implementation of the Icon Programming Language
[cover]
This book describes the implementation of Icon in detail. Highlights include:
* Icon's virtual machine
* the interpreter for the virtual machine
* generators and goal-directed evaluation
* data representation
* string manipulation
* structures
* memory management
http://www.cs.arizona.edu/icon/ibsale.htm
Information on the Icon programming language itself can be found at
http://www.cs.arizona.edu/icon
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!
Practically all coding books do this, and I mostly find it a cheap way to poop out thick books and massive volumes... Not a measure of quality in any way.
When will I end this grieving ? When will my future begin ?
Isn't perl technically an interperted language like basic?
I'm not trying to troll, but I guess I should have stayed awake in my CS class because i was under the impression the 'scripting' languages were not compiled.
I guess that would be why it runs on a virtual machine, if I'm right (and I think i may be way outta whack).
Someone throw me a bone here.
Linux is dead.
LU
Perl 6 is supposed to be compiled to Parrot instead of machine code.
M$'s new runtime being CLR (Common Language Runtime, or something like that)
.NET is NOT an Operating System.
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
Yessir it is. .NET is a blanket term for everything MS is coming out with these days, including the upcoming successor to Win2k, the .NET Server range.
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?
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:
Please don't feed the trolls.
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.
No way, you've just been trolled.
Perl is a hybrid. It's interpreted at run-time like a scripting language, but before execution, it's pre-compiled to a VM-like bytecode. The idea is to get the best of all worlds. Things like mod_perl benefit from this a lot by only having to compile once but running many times.
God Fucking Damnit
You need UML to design a VM. IF UML dies, all VMs die as well.
and that's part of the reason that you should go to college and study CS rather than teaching yourself.
I rule.
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.
I'd like to nominate some software I wrote for the most random use of a virtual machine.
I was asked to code a registration routine for a piece of software - after getting the username + serial number from the user I would have typically done some magic to calculate a checksum from the name and see if it matched the given key.
Instead I wrote a small virtual machine which executed z80 machine code. The protection routine litererally started the VM - where all the magic happened. Each opcode was fetched decoded and executed. I think it would have been a real pain to decode ;)
(I guess the clever cracker could have disassembled my windows binary with a z80 disassembler and gotten lucky; but it would have been hard to see what was being executed - unless they could do clever things like disassemble z80 in their head...)
for(;;){cout"YHBT. YHL. HAND."endl;}
n/m
It seems to me that more and more languages nowadays are designed for a VM, thus adding a level in between the OS and the application. Of course, this leads to a slowdown because the JIT has to do its thing AND the compiled code that runs has to use system calls to do what it wants to. But has anybody given any thought to making a VM that runs almost on top of the hardware with almost no system calls? Perhaps the only interference the OS would make is scheduling and possibly memory management. This kind of approach (like the exokernel approach in the EROS project) would allow a VM to greatly speed up its resultant code because it would have almost direct control of the hardware, and the VM would be optimized for that hardware. I am working on an OS (Middle Earth OS) that is looking into this kind of design, and would appreciate your input either here or in the project's forums as to whether you think this would work (well) or not.
Never overestimate the intelligence of a slashbot.
What language is that written in, Visual Basic gave me a compile error
Yea, so for a class project we took the kvm and (Java VM for embeded devices), and turned it into a pipelined architecture. It was very educational, but the practicality is lacking ... You at least need a 4 proc machine to be useful, as it was a simple 4-stage. But the speed was soo lacking.
;) .... as it was only a learning experince no big deal. By the end i could've written my java in assembly ;)
It was worthwile experience, though I do wish java was reg based.
/* Lobster Stick To Magnet!*/
.NET is (for purposes here) a runtime environment/API. It's predicated upon Microsoft Intermediate Language (MSIL): basically, code that's easily compiled for a specific CPU or Operating system. The whole system is based upon a Just-In-Time compiler. It's all compiled to native code and executed as a normal program.
.NET is just a small but growing part of the Windows(tm) operating system.
As for whether or not this constitutes an Operating System, that's a little vague. It does provide some memory management functions (garbage collection), but it certainly doesn't do a lot of OS type things (device drivers, file systems). An operating system is many things, and
bance.net
We might as well get the terminology right. Perl 5 compiles the source code at compile time (at sometimes at runtime for eval STRING) into opcodes for the terribly-undocumented and very-well-hidden Perl 5 virtual machine. You just don't notice it 'cos it compiles it and runs it in one step.
Perl 6 (not finished yet) aims to seperate the virtual machine (http://www.parrotcode.org/) from rest of the language.
Hopefully this clears things up.
'c' has always been a *systems* programming language - it was never [originally] intended
for applications programming
fortran, cobol, and perl are very much thriving (not as popular, but still very much in use). my guess at the replacement is gonna be c++ or java.
that's interesting, because java wont celebrate
it's 10th birthday until May 23, 2005 - am i to
assume you were using "oak" before that ?!??!
you have *GOT* to be kidding me. what do you think all the worlds' operating systems are written with? most good compilers go straight to binary. and some of these compilers put out some pretty efficient binary. i used to a boat-load of assembly development, and some of the cutting edge c-compilers were putting out efficient code.
java is interpreted, although you can generate native binaries. vb is in the same boat, but its object-based, which is fairly wimpy. i cant talk about c#, all i know is that it was created as a marketing language to compete with java (cause microsoft couldnt shut it down).
a c programmer worth his salt will know exactly how to use his chosen language. it's the typical 9-5 programmer that hasnt a clue.
that's not even a comparison, so try something else. learning how to release allocated memory is child's play - you just have to be an efficient developer.
you are obviously clueless, based on your previous paragraph. you dont "duplicate" memory so that a pointer can point to something. memory is first allocated, either on the heap or the stack (i hope i'm not using language that is unfamilar), and then a pointer is created, either on the stack or heap, so that you can access the memory it is pointing to. pointers are the most efficient way to access memory on the heap (and stack), short of reverting to assembly language. pointer arithmetic and the use of a pointer to "walk" memory locations is waaaaay more efficient then, say, using array offsets.
again, it is an incredibly *fast* language - your
lack of understanding is displayed through
your naive statements.
vb - what a joke. like i said, i've never dealt with c#, so i cant talk to it. and java is efficient for OTHER reasons - it's not faster than 'c'. there is a lot of plumbing in java that is included out of the box, is truly object oriented, and includes a garbage collector. but the garbage collector is very inefficient, in time-critical applications. you can get garbage collectors for c++ and c also.
i'll tell you what, let's decide on a back-end,
speed critical application to run on a real OS,
like Linux or Unix - you do it in VB, and i'll do
it in C, and we'll do some speed runs and see
what the outcome is.
much of my experience developing real time
systems involved, you guessed it, c. and why
is that? because it is fast, compact, and very
efficient.
so, what happened to c++???? because i am
sure you have no significant experience with
it, you've already dismissed it.
BWA HAHHAHHAHAHA
feeling a little blue, but now i'm smiling
like i said, you havent a clue about the language because of that typical microsoft mentality: "if it dont have a GUI, i'm lost"
again, you havent a clue. what, do you think that sun owns all the code you write??? sheesh.
BWA HAHAHAHAHAHA. come on come on,
*names* please - what "luminaries" in the
industry are dying to move from c to vb.
For more information on Parrot, which will be the Perl 6 virtual machine, and which is register-based, you may want to check out http://www.parrotcode.org/.
It seems to me that many of you are viewing VM as some kind of emulation application rather than a virtual machine. What you may not realize is that many(most?)OS kernels including Linux virtualize the hardware to make the software more portable and less able to crash your entire system. What you lose in performance you make up for in stability. Operating systems books are a great reference for studying VMs.
Operating System Concepts by Abraham Silberschatz, et al.
Design and Implementation of the 4.4bsd Operating System by McKusic, et al.
Design of the UNIX Operating System by Bach
Modern Operating Systems by Tanenbaum
Operating Systems Design and Implementation by Tanenbaum
what time did he pass away
i haven't heard anything on the news yet
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
It doesn't run without Windows?
I guess you could say it blurs the line/is highly integrated with the underlying OS, but wasn't there just a protracted legal battle based on that?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
A BEHAVIORAL simulation/VM can generally be brought up a great deal faster than a group of designers can create Verilog, tape out and get Si back. While this type of simulation isn't perfect as far as timing and bus cycles, a SW group can get a major head start preparing for new Si - both in terms of actual SW development and Post-Si validation.
Can anyone explain what's similar/different between doing this and doing something like ReBirth?
Libertarianism is rich wolves and poor sheep playing gambler's ruin for dinner.
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.
Sun always planned hardware chips.. modified sparc cores that ran Java on 'bare iron'...
They got 'em now... have for a while now.
---- Booth was a patriot ----
Was in Unreal. That was, what, five years ago? It was a revalation to me as a commercial games developer. You could script object behaviour in C-like code, and load it dynamically at run time without having to restart the engine or try and do clever tricks with dll's. The development time that saved was simply breathtaking, and it pretty much defined the future of games engines and games development, which epitomise the RAD concept. Heck, the first thing that we did was crank out our own C-like VM, and we never looked back.
If you were blocking sigs, you wouldn't have to read this.
Because of the increased power of CPUs through time, we SHOULD expect features of development environments to be expanded.
I'm in the camp that programming as a art should evolve to way beyond what we have today. GC may evolve to a more manageable version (defer/force intructions) but you can consider thick APIs and these features to be the norm in the future.
Although actual silicon being called virtual does kinda twist one's mind.
Security is not the issue. Having software that runs on any machine is. Java has hijacked the VM world into thinking a VM must support garbage collection. This is a falsehood. A VM merely has to run its code the same everywhere - ideally as fast as possible. Any software you run is potentially non-secure. You ultimately must trust its author or the vendor you bought it from. Sure, you could look at the source code in the case of free software - but no one actually does (or can even to hope to understand hundreds of thousands lines of code written in any language). For that matter, any standalone Java application is free to make the same logic mistakes as their supposedly non-secure traditional compiled language counterparts. Even a standalone Java application can be malicious - overwriting your files or emailing them to random people on the internet. Take the popular Java file-sharing application Limewire, for example, do you know for a fact what it is actually doing? Of course you don't. Is it "secure"? You believe it is - but who knows? You must ultimately trust the vendor.
I was the maintainer of the p-System version of NPL, a 4GL for numerous platforms from Desktop Software out of Princeton.
Given the hardware of the day (early-mid 80's), a VM system like p-System was (ahem) ahead of its time. It was really slow, even to our ancient sense of performance. But the same binary did run fine on numerous p-System implementations, including the IBM PC and DEC Rainbow.
I also did work on the HP Pascal system on their Series 200 68000-based systems. The Pascal system was a native 68K port of the p-System. You got the UCSD Pascal, which was a great Pascal, and a number of other HP proprietary enhancements, and it was the fastest computer I had ever seen at the time.
Parrot is appearantly the result of an April fools joke that wouldn't die. As a result Parrot is supposed to compile not only Perl 6 but also Python and possibly Ruby.
Whee!
So a C/C++ library that interfaces well to Parrot would be accessible by LOTS of different scripting languages.
(I haven't been following the developer lists, so this is just based on what I overheard as a casual outsider with a bit of interest.)
I think we've pushed this "anyone can grow up to be president" thing too far.
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.
instead of having native binary packages for each arch, why not compile to an intermediate bytecode (distribute that), then compile and cache the native binary? would too much optimization info be lost?
amiga was working on something like this. were the resulting native binaries decently optimized?
i'm imagining an isa that would use labels (instead of registers). the compiler would just do all the macro expansion, etc. maybe this wouldn't be much faster than just compiling it from scratch, though.
I haven't seen much discussion about the concepts which allow virtual machines to exist, but isn't there a theory that any turing-complete system can emulate any other turing-complete system flawlessly? At least, if you ignore the infinite space requirement of a turing machine, any turing-complete system can at least simulate what any other turing complete system can do?
I think this is the theory that the *AA, Microsoft, and any other DRM implementors are going to have to realize. It is not possible for software to trust hardware. Any hardware interrupts or memory-mapped I/O can be completely simulated; the only problem is getting the correct response back (i.e., through breaking the encryption keys or whatever. How long did it take dongles to be cracked?) The software can't even necessarily do anything malicious to the user if whatever authentications fail; any instructions can be executed conditionally at every step, and anything malicious simply ignored. The bytecode for a program is sort of like a book of instructions - the book may say "Step 4: if you don't have the password, burn this book", but the reader doesn't have to do anything of the sort.
Of course, the problem is, the instructions may say "Step 5: Use the password to decrypt the hardware key, then use the decrypted key to decrypt the rest of this book." This is little more than security through obscurity.
The cat is out of the bag, and all the czar's horses can't put it back in. They'll need to invent a system that is not turing-complete and then get the american sheeple to buy it; good luck.
The Wizard utters the word 'frobnoid!' and cackles gleefully
Python behaves similarly. Upon importing a module into another program, a ".pyc" file is created containing the compiled bytecode. Subsequently, Python uses the compiled module rather than the source file.
This is an obvious troll, and you sir, have been suckered. I'm not sure what's funnier -- the troll itself or the dimwits who took it seriously. What is clear from the amounts of responses this troll gets is that the troll is clearly more intelligent than the respondents !
Has anybody here, other than the reviewer, actually read the book? The reviewer says:
...a number of advanced topics (garbage collection, memory management, assembler construction, paging, token parsing) are dealt with in a very easy to understand way.
Blunden [the author] makes sure to cover every topic related to virtual machines in extreme depth.
Fine, that I could believe...maybe...in a 650-page book. But then, he goes on to say:
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.
All in just 2 chapters? Furthermore:
Followed by a complete VM implementation, with assembler and debugger, including clear and pertinent code examples in C/C++? All in a 650-page book? Maybe the writing is really, really small?
This book must be a tour de force of clear, concise writing. Either that, or the reviewer's ability to discriminate between hand waving and thorough discussion of a topic is limited, at best.
If this book really is as good as the reviewer says, then I absolutely must get it. But, somehow, it sounds too good to be true.
At least we know what C++ programmers are good for.
If a VM doesn't support garbage collection, then programs written for it will be buggier and less safe than programs written for a VM with garbage collection.
One of the biggest reasons that existing software is so unreliable and unsafe is because of its dependence on C, and the lack of both type safety and garbage collection in C. This allows buffer overflows and memory access violations. You're correct that adding garbage collection (and true type safety) doesn't buy security in and of itself, but it buys a heck of a lot of safety.
Although it's being done with Perl in mind, it's not just the Perl 6 VM; it's actually aimed at pretty much any dynamic language. Hence we should also see backends for Ruby, Python, Basic, any pretty much any language you care to impliment.
There's also talk of Parrot bytecode to Java/CLR bytecode convertors. Interesting stuff, even if we're gonna have to wait ages to actually get something useful.
It would be great if someone was able to dig up some of these p-Systems and documentation and made them available. I imagine only binaries would be available. Wouldn't they scream on today's computers?
Can anyone give me a substantial difference between a virtual machine, and an emulator
Others have commented on the theoretical differences, but I feel I should say something as to what distinguishes a VM from an emulator in practice. Virtual machines do not promote piracy because software is designed to run on virtual machines. On the other hand, an emulator is often written with unlawful redistribution of proprietary software in mind, even if it is wink-wink-nudge-nudge.
because I can't see whats different between my mame and java virutal machine
I find the most important difference between MAME and JVM that there is a much larger library of free software designed to run under JVM than under MAME.
Will I retire or break 10K?
The programmers' holy grail, stuff of legends, the Lisp machine. It was virtualized by Symbolics and ported to the 64-bit Alpha. If I remember right, the Symbolics LispM had a variable length word and Megaword, which made the Alpha the only viable option. I believed it utilized Alpha microcode, and required Digital Unix to work correctly. The new "operating-system" was called Genera. I have a copy of it (somewhere around here) I intend to buy a Multia for myself someday, but I wonder if there was still some interest in porting Genera to a 64-bit x86? Hope so.
Implementing a VM is bad enough -- imagine the testing matrix. It would have been nice if the author covered information on the most efficient methods of verifying the functionality of a VM, or comparing the actual behavior of an emulator against the target platform whether through the use of Formal Methods, instrumentation, or some exhaustive state-transition generator framework.
Has anyone else had to test VMs or emulators?
I got the point of the article, dumbass. Thanks for repeating it for no reason. GC will not save you from a logic error in your program that gives users unauthorized rights (or other privledges). And I guess you've never encountered runaway Java memory retention bugs - can you say "denial of service"? You're pretty closed minded. GC is not the sole answer to everyone's ills.
Parrot is going nowhere fast. Too many philosophical debates about VM purity and goodness. Too many crazy ops. It's not a VM - it's an operating system that will never be finished. Perhaps it will run on Hurd one day.
Rather than running user programs, CP-67 multitasked operating systems. Each client system ran believing that it was operating in supervisor mode on a bare 360/65. In fact, the clients were all running in user mode. CP-67 trapped the privileged instructions (including all i/o instructions), which it emulated on behalf its clients; and it used the Model 67's Dynamic Address Translation unit (what we'd call a VMM today) to present a flat model of the 360's address space to each client operating system.
CP-67 was neither a bytecode interpreter nor a full-fledged emulator. All programs were compiled into 360 machine code, and most instructions (all of the non-privileged ones) executed natively. IBM referred to the client environment as a "virtual machine." The flat address space presented to each client (which could magically exceed the amount of physical memory in the machine) they called "virtual memory."
I guess I should clarify. I didn't mean that just 1 VM is running on top of the hardware. It would actually be 2 or 3 (or more) VMs running simultaneously with a native "VM" that is not really virtual but actually the API to the kernel. The VMs would be subject to scheduling (obviously) by the kernel.
I'd like to see a good book on writing backends to gcc so that you don't also have to write your own VM compiler. I have the Using and Porting GCC book, and admittedly I've yet to really sit down and go through it thoroughly, but it doesn't seem to make it plainly obvious to me just how you make gcc aware of what opcodes your system needs.
I can't believe how this guy got a job! Man, when C dies your VB also will because VB creators will not be able to continue making your program! Damn, I don't know what to say about all this STUPID comment... man are you a lawyer? or maybe a sailor? because this is a tech/programmers site... just if you didn't know it.
I couldn't agree less. I flipped through the book in the bookstore, and I wasn't impressed. Blunden is a C/Assembly language programmer with little understanding of the requirements that a modern programming language places on a virtual machine. So his virtual machine is single threaded and runs in a fixed block of address space, with a fixed size code and data section, a growable stack, and a growable explicitly managed heap. This is fine if the target language is C or assembly language, but not so fine if you want garbage collection, threads, closures, first class continuations, or any of those other language features that were considered cutting edge back in the 1970s. How does his system link to external code, like the system calls in libc? Well, there are 11 "interrupts" called int0 through int10, sort of like the DOS system call interface.
His explanation of why he doesn't support garbage collection is pretty muddled: basically, he's not comfortable with the idea, and doesn't think its practical.
Although I think that a register machine probably is better than a stack machine for this kind of system, he gives none of the arguments I was expecting to see to support this design decision. Instead, we get vague handwaving: apparently, he's more comfortable with register machines, because that's what he's used to.
Doug Moen
I have written a truly remarkable program which this sig is too small to contain.
Indeed. But last time I touched my Amiga was sometime back in 1994 (just after I discovered UNIX :-) when I wrote this.
At some point I really do need to go through my old floppy collection and transfer all my old source code to a UAE-able form before it gets irretrievably lost.
Back on topic: Somewhere, I started on a Spectrum emulator that managed to emulate the weird Speccy screen layout by using the copper - the alternative at the time had to re-draw the screen every few frames, which really killed emulation speed.
But I guess that illustrates the point nicely between an emulator and a VM. The side effect of changing a single byte could means lots of work for the emulator, whereas changing another byte at some other address with the same instruction could just be as simple as storing the data.
They make the Java and php VMs look like the Johnny-come-lately's that they are. (Sorry Squeak! Wa-ay too slow.)
Blazing fast object allocation (both) interning & loading (VA by a nose,) and both have a full IDE that the others have been trying to achieve since Smalltalk'80 came out.
But remember thei're IDEs not production/delivery. For that you want internationalizable, database drivable GUIs, dialog managers, state machine and transition engines.
All in all. Look at VW & VA and weep. (Or better yet learn.) They've been at it since the days of UCSD Pascal. They've forgot more than you'll ever know.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
Anyone seriously interested in VM work should take a look at VMGen, which does a great deal of the hard work for you and produces high quality output.
Perl Uses a VM?
+3 Insighful for an incorrect statement?
There are a couple of different options for doing this in Python:
One is to use Christian Tismer's `Stackless Python'--the `uthread' module, if I recall correctly, allows the Python programmer to step op-by-op.
The other method is to use Python 2.3's generators (via the `yield' statement) (via the `from __future__ import generators' statement in Python 2.2).
There's an IBM-developerWorks article on the latter technique.
-rozzin.