So you're saying that virtual machines are basically like a different kind of assembler or compiler?
What exactly is a virtual machine and how does it fit into the programming hierarchy & computer architecture?
Interpreted languages like Python compile to special bytecode. This is not machine code - it can only run on the language's VM. The VM provides a fake "CPU" and memory model for the bytecode to operate on, divorced from the actual hardware implementation and semantics. In this way you can create a higher-level "base" for the language to work on.
Let me give you an example - a simple function implemented in C and in Python:
C:
int add(int a, int b) {
return a + b;
}
int main(int argc, char* argv) {
add(1, 2);
}
Python:
def add(a, b):
return a + b
def main():
add(1, 2)
We can obtain the C machine code by compiling the source and running objdump on the executable. Here's the assembly for the relevant functions:
Code:
add:
push rbp
mov rbp, rsp
mov DWORD PTR [rbp-4], edi
mov DWORD PTR [rbp-8], esi
mov edx, DWORD PTR [rbp-4]
mov eax, DWORD PTR [rbp-8]
add eax, edx
pop rbp
ret
main:
; unrelated stuff
mov esi, 2
mov edi, 1
call add
; yet more unrelated stuff
This is as bare-bones as assembly gets.
First it pushes the initial value of the stack base pointer (
rbp) onto the top of the stack. Then it moves the current stack pointer (
rsp) into the base pointer. This is called the
function prologue. Think of function calls (and their stack variables) as levels of a skyscraper:
rbp is the floor, and
rsp is the ceiling. The prologue essentially creates a new level in the call skyscraper by setting the "floor" of this call to the "ceiling" of the last one. This allows the rest of the function to ignore the stack frames above and below it.
The function then moves
edi and
esi (the registers containing the arguments) onto the stack, directly "above" the floor ("above" means a
negative offset - assembly likes to fuck with people like that). The arguments are then moved back into registers, this time
edx (no significance) and
eax (called the
accumulator, often used to hold return values). I have no idea why the arguments are moved from registers to the stack and back again, but compilers do lots of really weird things to make assembly code go brrr, and this is probably one of those things. The function (finally) adds
eax to
edx. Then it pops the value of the base pointer that was pushed in the prologue, and returns, jumping back to where it was called. You can see how the
main function moves the constants 1 and 2 into the argument registers, then calls the
add function.
If you don't get it, that's OK. I'm trying to make the point that machine code has to deal with a lot of low-level things that are irrelevant to the computation being done, like micro-managing registers and the memory layout.
Now let's look at the Python bytecode. We can do this with the
dis module:
Python:
>>> import dis
>>> dis.dis(add)
2 0 LOAD_FAST 0 (a)
2 LOAD_FAST 1 (b)
4 BINARY_ADD
6 RETURN_VALUE
>>> dis.dis(main)
2 0 LOAD_GLOBAL 0 (add)
2 LOAD_CONST 1 (1)
4 LOAD_CONST 2 (2)
6 CALL_FUNCTION 2
8 POP_TOP
10 LOAD_CONST 0 (None)
12 RETURN_VALUE
Coming from assembly, this is totally foreign. There are no registers, only a stack. Let's take a look at the
add function:
It calls the
LOAD_FAST instruction twice with variables
a and
b. This pushes them from the local namespace onto the stack. Then it calls
BINARY_ADD, which pops the top two values off the stack and pushes their sum. Then it returns. The return value is implicit: the main function puts the arguments on the stack for the function to use, and the return value is whatever's left on the stack when the function's had its way. Notice how, since there are no registers, everything centers around the stack. This makes bytecode programming and code generation easier, but at the cost of performance (using registers is orders of magnitude faster than getting all your data from main memory).
There's no actual computer that works like this. Hardware with that level of complexity would be impossible to produce at a reasonable price, and useless for most purposes. What you
can do is write a program in a low-level language (
like this one) that pretends to be a computer that works with this memory model and instruction set. This way, you can leave the nitty-gritty stuff to the low-level implementation, and your language's compiler only has to worry about producing good bytecode.
There's also a mixed approach called a
JIT compiler, which compiles the most heavily used parts of a high-level program into machine code.
PyPy is the most well-known one for Python. JIT compilers usually only work with a subset of the target language, and tend to open up
gnarly security issues.
