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.
Another one from Warp Records. Hope y'all like it.
Jeez... if you are going to make fun of something, at least you should learn about it first.
I'm a first year programming student at an Ivy League school and I've just finished my Visual Basic classes. This term I'll be moving onto C++. However I've noticed some issues with C++ that I'd like to discuss with the rest of the programming community. Please do not think of me as being technically ignorant. In addition to VB, I am very skilled at HTML programming, one of the most challenging languages out there!
C++ is based on a concept known as Object Oriented Programming. In this style of programming (also known as OOPS in the coding community) a programmer builds "objects" or "glasses" out of his code, and then manipulates these "glasses". Since I'm assuming that you, dear reader, are as skilled at programming as I am, I'll skip further explanation of these "glasses".
Please allow me to make a brief aside here and discuss the origins C++ for a moment. My research shows that this language is one of the oldest languages in existance, pre-dating even assembly! It was created in the early 70s when AT&T began looking for a new language to write BSD, its Unix Operation System (later on, other companies would "borrow" the BSD source code to build both Solaris and Linux!) Interestingly, the name C++ is a pun by the creator of the language. When the first beta was released, it was remarked that the language would be graded as a C+, because of how hideously complex and unwieldy it was. The extra plus was tacked on during a later release when some of these issues were fixed. The language would still be graded a C, but it was the highest C possible! Truly a clever name for this language.
Back to the topic on hand, I feel that C++ - despite its flaws - has been a very valuable tool to the world of computers. Unfortunately its starting to show its age, and I feel that it should be retired as COBOL, ADA and Smalltalk seem to have been. Recently I've become aquainted with another language that's quite recently been developed. Its one that promises to greatly simplify programming. This new language is called C.
Although syntactically borrowing a great deal from its predecessor C++, C greatly simplifies things (thus its name, which hints at its simpler nature by striping off the klunky double-pluses.) Its biggest strength is that it abandons an OOPS-style of programming. No more awkward "objects" or "glasses". Instead C uses what are called structs. Vaguely similiar to a C++ "glass", a struct does away with anachronisms like inheiritance, namespaces and the whole private/public/protected/friend access issues of its variables and routines. By freeing the programmer from the requirement to juggle all these issues, the coder can focus on implementing his algorithm and rapidly developing his application.
While C lacks the speed and robustness of C++, I think these are petty issues. Given the speed of modern computers, the relative sluggishness of C shouldn't be an issue. Robustness and stability will occur as C becomes more pervasive amongst the programming community and it becomes more fine-tuned. Eventually C should have stablity rivalling that of C++.
I'm hoping to see C adopted as the de facto standard of programming. Based on what I've learned of this language, the future seems very bright indeed for C! Eventually, many years from now, perhaps we'll even see an operating system coded in this langauage.
Thank you for your time. Your feedback is greatly appreciated.
Despite the popularity of tools such as Together Control Center and Rational Rose, it is clear the UML is dying. Despite the bloat which occured between versions 1.2 and 1.4, the "language" is still incomplete in many places whilst still containing multiple notations in others.
UML will never be able to implement the feature sets which are vital to modern programming. These include multiple thread representation (which can be done clumsily using coloured sequence diagrams) and multiple view representation (such as the private and remote interfaces to an EJB). Even Peter Coad's group admit this.
The promise of the so-called "unified" modelling language has led to individual developers adding their own ad-hoc notations for the missing concepts - or, in many cases, abandoning UML altogether in favour of a home-grown notation. UML needs to be scrapped and replaced with a notation which is capable of representing the concepts which affect software developers today.
"Under the iron bridge, we fist" - The Smiths, Still Ill
Yes? No?
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
Gentlemen, the time has come for a serious discussion on whether or not to continue using C for serious programming projects. As I will explain, I feel that C needs to be retired, much the same way that Fortran, Cobol and Perl have been. Furthermore, allow me to be so bold as to suggest a superior replacement to this outdated language.
To give you a little background on this subject, I was recently asked to develop a client/server project on a Unix platform for a Fortune 500 company. While I've never coded in C before I have coded in VB for fifteen years, and in Java for over ten, I was stunned to see how poorly C fared compared to these two, more low-level languages.
C's biggest difficulty, as we all know, is the fact that it is by far one of the slowest languages in existance, especially when compared to more modern languages such as Java and C#. Although the reasons for this are varied, the main reasons seems to be the way C requires a programmer to laboriously work with chunks of memory.
Requiring a programmer to manipulate blocks of memory is a tedious way to program. This was satisfactory back in the early days of coding, but then again, so were punchcards. By using what are called "pointers" a C programmer is basically requiring the computer to do three sets of work rather than one. The first time requires the computer to duplicate whatever is stored in the memory space "pointed to" by the pointer. The second time requires it to perform the needed operation on this space. Finally the computer must delete the duplicate set and set the values of the original accordingly.
Clearly this is a horrendous use of resources and the chief reason why C is so slow. When one looks at a more modern (and a more serious) programming language like Java, C# or - even better - Visual Basic that lacks such archaic coding styles, one will also note a serious speed increase over C.
So what does this mean for the programming community? I think clearly that C needs to be abandonded. There are two candidates that would be a suitable replacement for it. Those are Java and Visual Basic.
Having programmed in both for many years, I believe that VB has the edge. Not only is it slightly faster than Java its also much easier to code in. I found C to be confusing, frightening and intimidating with its non-GUI-based coding style. Furthermore, I like to see the source code of the projects I work with. Java's source seems to be under the monopolistic thumb of Sun much the way that GCC is obscured from us by the marketing people at the FSF. Microsoft's "shared source" under which Visual Basic is released definately seems to be the most fair and reasonable of all the licenses in existance, with none of the harsh restrictions of the BSD license. It also lacks the GPLs requirement that anything coded with its tools becomes property of the FSF.
I hope to see a switch to VB very soon. I've already spoken with various luminaries in the *nix coding world and most are eager to begin to transition. Having just gotten off the phone with Mr. Alan Cox, I can say that he is quite thrilled with the speed increases that will occur when the Linux kernel is completely rewritten in Visual Basic. Richard Stallman plans to support this, and hopes that the great Swede himself, Linux Torvaldis, won't object to renaming Linux to VB/Linux. Although not a C coder himself, I'm told that Slashdot's very own Admiral Taco will support this on his web site. Finally, Dennis Ritchie is excited about the switch!
Thank you for your time. Happy coding.
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.
I was under the impression that Perl is compiled at runtime to machine code, not for a virtual machine. Am I completely off the mark?
.NET and its open source counterparts catch on?
Slightly more on topic, the idea of a vm for C/C++ is great, but isn't this going to become outdated once (if)
You have enemies? Good. That means you've stood up for something, sometime in your life. --Winston Churchill
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!
Woot!
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
why not review a relevant book - something about C# perhaps.
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...
NAZI s! We have NAZI s! Here at crazy uncle Sam's project Paperclip, we have the finest NAZI s your taxpayer money could buy!
We've got big name NAZI super-scientists like Wernher von Braun, who single-handedly built the US space program when we couldn't get even a mouse into space without blowing up on the pad! And don't you believe those who would cast aspersions on his character! He used concentration camp slave labor to build his V1s & V2s that he blew up innocent Londoners with!
If you're looking to beef up your intelligence services, Reinhard Gehlen is the NAZI for you! He's the NAZI that can make those commie bastards talk! He comes with a vast cache of intelligence documents on the USSR compilled by the pain-staking tourture and interrogation of red commie-bastard prisoners. Why do your own legwork when it's already been done for you?!! This man would be a great addition to any spy agency, and a sterling influence upon your junior agents!
If you're a US presidential candidate, and want to ensure that you crush your ineffectual, peanut-farming Democratic competitor, Heinrich Rupp is the NAZI for you! With strong ties to the Arab community, he can manage complex three-cornered schemes that will ensure that those hostages aren't released while there's a Democrat in the Oval Office. As a bonus, you can use the proceeds to fund anti-communist fascists in Central America.
We also have such all-stars as Arthur Rudolph, Kurt Blome, Walter Schreiber and Licio Gelli! We have everything you need to build an enlightened, democratic new world order! So hurry on down to crazy uncle Sam's before all of our NAZI s are gone!
(One of our most notorious NAZI s now works for Microsoft where he continues to commit crimes against humanity.)
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
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.
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 ?
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
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?
Where did you come up with all this nonsense ? There isn't almost one
bit of correct information in what you write. You learn how to
research because what you did is not one.
Let me help strate up some facts:
Object Oriented Programming = OOP not OOPS.
Object types are called classes not "glasses"
The language that was developed at the 70's was C which is a
procedural language, OOP is a more recent concept of programming
(which in the case of C++ was developed at the beginning of the 80's
by Bjarne Stroustrup - NOT Microsoft). (BTW, VB is supposed to be OO
language (object oriented) but it isn't fully since it doesn't have
inheritance in it).
C is compiled to a much faster code (since it is much closer to
machine code than C++).
The name C and/or C++ has nothing to do with grading the language.
C/C++ flaws are compiler flaws - not the language's, and speaking of
flaws, lets not start with the ones inside Microsoft's compilers...
C++ is a very good language - but like any other language you should
know to what purposes it is fits best.
Assembly is the most basic computer language (beside the actuall
machine code) a person can use - it is almost direcly translated into
machine code, hence it is technically the earliest computer language.
C (not C++) was developed in order to write out the first UNIX
operating systems, many of today's operating systems are written in C,
and some are beginning to adopt also some C++. For example, if any one
would like the source code of the Linux operating system (which is
mainly written using C) can be obtaind easily.
Next time before you write stupid things check out the real facts, and
this is without even getting into all the advatages OOP has over
regular procedural programming, and the advantages C++ has over many
other computer languages.
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:
[n/t]
YHBT. YHL. HAND.
No, im sorry you have been the one trolled.
I just heard some sad news on talk radio - Horror/Sci Fi writer Stephen King was found dead in his Maine home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't enjoy his work, there's no denying his contributions to popular culture. First Ann Landers, now this. Truly an American icon.
Heh!
and that's part of the reason that you should go to college and study CS rather than teaching yourself.
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!*/
'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
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
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?
The End of FreeBSD ed note in the following text former FreeBSD developerMike Smith gives his reasons for abandoning FreeBSD When I stood for election to theFreeBSD core team nearly two years ago many of you will recall that it was after a long seriesof debates during which I maintained that too much organisation too many rules and too much formality would be a bad thing for the project Today as I read the latest discussions onthe future of the FreeBSD project I see the same problem a few new faces and many of the oldgoing over the same tired arguments and suggesting variations on the same worthless schemes Frankly Im sick of it FreeBSD used to be fun It used to be about doing things theright way It used to be something that you could sink your teeth into when the mundane choresof programming for a living got you down It was something cool and exciting a way to spend your spare time on an endeavour you loved that was at the same time wholesome and worthwhile Its not anymore Its about bylaws and committees and reports and milestones tellingothers what to do and doing what youre told Its about who can rant the longest or shout theloudest or mislead the most people into a bloc in order to legitimise doing what they think is best Individuals notwithstanding the project as a whole has lost track of where its going and has instead become obsessed with process and mechanics So Im leaving core I dont want to feel like I should be doing something about a project that has lost interest in havingsomething done for it I dont have the energy to fight what has clearly become a losing battleI have a life to live and a job to keep and I wont achieve any of the goals I personallyconsider worthwhile if I remain obligated to care for the project Discussion Im sure that Ive offended some people already Im sure that by the time Im done here Illhave offended more If you feel a need to play to the crowd in your replies rather than make asincere effort to address the problems Im discussing here please do us the courtesy of playingyour politics openly From a technical perspective the project faces a set of challengesthat significantly outstrips our ability to deliver Some of the resources that we need toaddress these challenges are tied up in the fruitless metadiscussions that have raged since wemade the mistake of electing officers Others have left in disgust or been driven out by theculture of abuse and distraction that has grown up since then More may well remain availableto recruitment but while the project is busy infighting our chances for successful outreach aresorely diminished Theres no simple solution to this For the project to move forwardone or the other of the warring philosophies must win out either the project returns to itslaidback roots and gets on with the work or it transforms into a superorganised engineeringproject and executes a brilliant plan to deliver what ultimately we all know we want Whatever path is chosen whatever balance is struck the choosing and the striking are theimportant parts The current indecision and endless conflict are incompatible with any sortof progress Trying to dissect the above is far beyond the scope of any parting shotno matter how distended All I can reallyask of you all is to let go of the minutiae for a moment and take a look at the big pictureWhat is the ultimate goal here How can we get there with as little overhead as possibleHow would you like to be treated by your fellow travellers Shouts To theSlashdot BSD is dying crowd big deal Death is part of the cycle take a look at yoursoft pallid bodies and consider that right this very moment parts of you are dying SeeIts not so bad To the bulk of the FreeBSD committerbase and the developer community atlarge keep your eyes on the real goals Its when you get distracted by the politickersthat they sideline you The tireless work that you perform keeping the system clean andbuilding is what provides the platform for the obsessives and the prima donnas to have theirmoments in the sun In the end we need you all in order to go forwards we must first avoidgoing backwards To the paranoid conspiracy theorists yes I work for Apple too No myresignation wasnt on Steves direct orders or in any way related to work Im doing may domay not do or indeed what was in the tea I had at lunchtime today Its about real problemsthat the project faces real problems that the project has brought upon itself You cantescape them by inventing excuses about outside influence the problem stems from within To the politically obsessed give it a break if you can No the project isnt a lemonadestand anymore but its not a worldspanning corporate juggernaut either and some of the moregrandiose visions going around are in need of a solid dose of reality Keep it simple stupid To the grandstanders the prima donnas and anyone that thinks that they can hold the projectto ransom for their own agenda give it a break if you can When the current core were electedwe took a conscious stand against vigorous sanctions and some of you have exploited thatA new core is going to have to decide whether to repeat this mistake or get tough I hope theylearn from our errors Future I started work on FreeBSD because it was funIf Im going to continue it has to be fun again There are things I still feel obligated todo and with any luck Ill find the time to meet those obligations However I dont feelan obligation to get involved in the political mess the project is in right now I tried Iburnt out I dont feel that my efforts were worthwhile So I wont be standing for electionI wont be shouting from the sidelines and I probably wont vote in the next round of ballots You could say Im packing up my toys Im not going home just yet but Im not going toplay unless you can work out how to make the project somewhere fun to be again
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.