Why do VMs need to be "stack machines" or "register machines" etc.?

Question

_{(This is an extremely newbie-ish question).}

I've been studying a little about Virtual Machines.

Turns out a lot of them are designed very similarly to physical or theoretical computers.

I read that the JVM for example, is a 'stack machine'. What that means (and correct me if I'm wrong) is that it stores all of it's 'temporary memory' on a stack, and makes operations on this stack for all of it's opcodes.

For example, the source code 2 + 3 will be translated to bytecode similar to:

push 2
push 3
add

My question is this:

JVMs are probably written using C/C++ and such. If so, why doesn't the JVM execute the following C code: 2 + 3..? I mean, why does it need a stack, or in other VMs 'registers' - like in a physical computer?

The underlying physical CPU takes care of all of this. Why don't VM writers simply execute the interpreted bytecode with 'usual' instructions in the language the VM is programmed with?

Why do VMs need to emulate hardware, when the actual hardware already does this for us?

Again, very newbie-ish questions. Thanks for your help

Answer 1

A machine, virtual or not, needs a model of computation which describes how computation is carried out on it. By definition, as soon as it computes, it implements some model of computation. The question then is: What model should we choose for our VM? Physical machines are constrained by what can be effectively and efficiently done in hardware. But, as you note, virtual machines have no such constraints, they are defined in software using arbitrarily high level languages.

There are, in fact, virtual machines that are high-level as you describe. They are called programming languages. The C standard for example dedicates the bulk of its pages to defining a model for the so-called "C abstract machine" which describes how C programs behave, and by extension (as-if rule) how a conforming C compiler (or interpreter) should behave.

Of course, we usually don't call that a virtual machine. A VM is usually takes to mean something lower-level, closer to hardware, not intended to be directly programmed, designed to be executed efficiently. This selection bias means that something that accepts high-level composable code (like what you describe) wouldn't be considered a VM because is executes high-level code.

But to get the to the point, here are some reasons to make a VM (as in, something targeted by a bytecode compiler) register-based or the like. Stack and register machines are extremely simple. There's a sequence of instructions, some state, and semantics for each instruction (a function State -> State). No complex tree reductions, no operator precedence. Parsing, analysing and executing it is very simple, because it's a minimal language (syntactic sugar is compiled away) and designed to be machine-read rather than human-read.

In contrast, parsing even the simplest C-like languages is quite hard, and executing it requires non-local analyses like checking and propagating types, resolving overloads, maintaining a symbol table, resolving string identifiers, turning linear text into a precedence-driven AST, and so on. It builds on concepts that come natural to humans but have to be painstakingly reverse engineered by machines.

JVM bytecode, for example, is emitted by javac. It virtually never needs to be read or written by humans, so it's natural to gear it towards consumption by machines. If you optimized it for humans, the JVM would just on every startup read the code, parse it, analyze is, and then convert it into an intermediate representation resembling such a simplified machine model anyway. Might as well cut out the middle man.

Answer 2

This answer focuses on the JVM, but in fact it applies to any VM.

Why do VMs need to emulate hardware, when the actual hardware already does this for us?

They don't, but it makes the VM much simpler and portable: A VM that emulates hardware can use the same computational model than any hardware CPU.

The JVM in particular was built with portability in mind, in fact it was built so it could even be implemented in hardware (it may be hard to believe today, but the origin of Java was in the embedded world - specifically, controllers for interactive television).

If you have a goal like this, it is desirable that the VM operates as close to a physical machine as possible, because translating to actual machine code becomes easier and thus faster. Once you have the opcodes of the VM, in theory, all you have to do is translate to opcodes of the CPU the program actually runs on. In practice it is not exactly that simple.

I mean, why does it need a stack, or in other VMs 'registers' - like in a physical computer?

Using a stack based virtual machine model has the advantage that it can be easily transferred to both register and stack machines, while the opposite is not necessarily true. A register-based VM would need to make assumptions about the number of registers, the size of the registers etc. With a stack machine, no such assumptions are necessary.

The underlying physical CPU takes care of all of this. Why don't VM writers simply execute the interpreted bytecode with 'usual' instructions in the language the VM is programmed with?

Well, that's what such VMs do, they interpret bytecode. Even the JVM actually does that, at least before JIT (just-in-time) kicks in: it interprets the byte codes and executes the statements in the language the JVM was written in (typically C or C++, but there is even one written in JavaScript, Doppio). Note, however, that even such statements were translated to machine code by a compiler and actually look very similar to what the Java compiler produces - namely, they use registers and the stack to perform their work. Note the use of "interpreted" v.s. "compiled" languages becomes somewhat blurry at this point.

Answer 3

Why do VMs need to be “stack machines” or “register machines” etc.?

They do not. If you need a virtual machine, it may be anything.

The existing virtual machines have appeared as solutions to the situations like: A really brilliant idea has come to my head, I have invented a new programming language! But I have to generate code. (What a boring task!) But I do not want to generate i8086 code because it's ugly, and I do not want to generate 68k code because everyone else is using Intel. There's also VAX, but I don't have any VAX, neither a computer nor a VAX book. Therefore I will generate code for some processor that does not physically exist and implement that processor in software. The spec of that VM will make a chapter in my thesis. In theory, it will be possible to compile it to native code of any processor, but that will not be me.

On the other hand, the notation like "2+3" probably will not be used by VMs in foreseeable future because it implies doing a lot of transformation before something may be executed.

Answer 4

To answer the actual question that was asked. The term "virtual MACHINE" means that ALL software/hardware are simulated/emulated. If you use the underlying software/hardware to execute the instructions then you do not have a VM, you have a compiler/interpreter.