3

Many VMs execute a language of binary form, knows as 'bytecode', which is assembled down from a human readable 'assembly' language.

For example the assembly instructions push 1 push 2 add are translated (I think) to a series of ones and zeroes, which is then executed by the VM.

Why? Why don't VMs, and the JVM as an example, execute the assembly instructions directly?

They don't have the limitation of physical computers that can only handle ones and zeroes. The JVM can very well take textual instructions such as push 1 push 2 and execute them as they are. Why the additional step of compilation?

Improve this question
4
  • The M in VM stands for machine, which means they do have the limitations you describe. Anything else would just be an interpreter.
    – Blrfl
    Aug 4, 2014 at 0:45
  • 4
    Whenever someone uses the phrase "ones and zeros" 99% of the time they are confusing whatever they are trying to describe. Don't think of "ones and zeros", everything is in bytes.
    – whatsisname
    Aug 4, 2014 at 2:19
  • 2
    There is no additional step of compilation. The textual representation is a ad-hoc debugging help for humans, the only canonical representation is the binary representation. (This is yet another difference to most real machines.) Code generation for the VM doesn't produce strings like push 1 push 2, it produces the "ones and zeros" right away.
    – user7043
    Aug 4, 2014 at 4:36
  • 1
    read wikipages on bytecode, JIT compilation, interpreter, compiler, JVM
    – Basile Starynkevitch
    Aug 4, 2014 at 8:08

4 Answers 4

Reset to default
7

Here are a couple of reasons to think about:

Using human readable assembly language would waste space on disk and in memory. That has an impact on caching, and therefore on performance. In your example the instruction 'push' takes up four bytes. Why not compress the program by using one byte tokens for all instructions instead of the human readable strings?

It wastes cycles on the processor. Your VM probably has at least two instruction mnemonics that start with 'p'. In order for your VM to figure out whether an instruction is 'push' or 'pop' it has to compare at least two bytes. It's much more efficient if each instruction can be uniquely identified by looking at single byte. The argument to your instructions is a string representing a number. The string has to be converted to a binary format appropriate for they underlying CPU before it can be used in arithmetic. That conversion will take dozens of instructions all by itself. Why do that every time the program is run? It's much more efficient to do it in a one-time pass when the byte code is created.

Improve this answer
8
  • Finding a single byte processor would be somewhat unusual today, and I don't know of one that supports a Java VM (or a Java VM using 8 bit words). Perhaps the question could be "why don't the instruction codes encompass a full word that coincidentally renders as PUSH or pop?" And many CPUs already have variable-length opcodes, so that's hardly new. x86 uses 1-4 bytes now. And the reason not to do that with x86 is backwards compatibility.
    – Móż
    Aug 4, 2014 at 1:01
  • @Ӎσᶎ, I believe the OP is talking strictly about the representation of the code for the VM, not the native processor. The byte code instructions for the JVM are mostly 1 byte, with a few 2 bytes.
    – Charles E. Grant
    Aug 4, 2014 at 1:24
  • Thanks, I wasn't certain that JVM has variable-length opcodes and couldn't find a link.
    – Móż
    Aug 4, 2014 at 1:28
  • 1
    It's worth noting that disassembling an executable (translating back to assembly language) is a trivial operation. So not only is it slower, but it is pointless.
    – Gort the Robot
    Aug 4, 2014 at 4:45
  • 1
    @Ӎσᶎ x86's maximum instruction length is 15 bytes, not 4 stackoverflow.com/q/14698350/995714
    – phuclv
    Aug 4, 2014 at 9:23
8

Assembly is not binary code. Assembly is a textual representation of binary code. In order to execute it, you have to first run it through an assembler that generates byte code or machine code, and that takes time.

Although it is possible to assemble a byte-code program from a byte-code assembler, most programmers don't do it. Instead, they use a high-level language which compiles to byte-code, directly.

Consequently, the assembly step is not needed.

Byte code is not the same as the processor instructions that actually execute your program. The VM must translate the byte code into processor instructions first, and then those processor instructions are executed. It is done this way because byte code is machine-independent; you can use the same byte code on processors having a completely different instruction set, so long as you have a VM for that processor.

Improve this answer
5
  • Thanks. A question: "The VM must translate the bytecode into [the underlying physical] processor instructiona first, and then those processor instructions are executed." - this is the case if the VM does JIT compilation of the code, but not the case if it simply interprets the bytecode as it is (like in older JVMs) right?
    – Aviv Cohn
    Aug 4, 2014 at 9:26
  • Translation occurs in both cases.
    – Robert Harvey
    Aug 4, 2014 at 13:32
  • Ah why? I mean 'interpretation' simply means "read code, act accordingly". So say the VM reads push 2 (in byte-form ofcourse), it simply pushes the number 2 on it's stack. Why translate to instructions on the physical CPU, how is it relevant if we're not JITing?
    – Aviv Cohn
    Aug 4, 2014 at 14:56
  • It still ultimately resolves to machine language, whether you're JITting or interpreting. I'm not sure what fine line you're trying to draw.
    – Robert Harvey
    Aug 4, 2014 at 14:57
  • 2
    @RobertHarvery I appreciate you're trying to help but I'm just getting more confused: I thought the difference between interpretation and JIT compilation is that interpretation means the program executes the statements itself, and JITing is compiling each statement for the underlying CPU to execute. Why does a VM that does only simple interpretation need to translate to machine language? I understand that umtimately everything comes down to machine language, but that's not the job of the interpreter. Are you saying that a VM that simply interprets code also translates it to machine language?
    – Aviv Cohn
    Aug 4, 2014 at 16:18
2

The bytecode is more efficient to store and easier (hence faster) to parse for the VM.

The textual representation of the bytecode (the "assembly" language) is mainly used for understanding the internals of the bytecode compiler and/or for analyzing the optimization passes. As Robert Harvey said, the majority of programmers will never deal with the bytecode directly so there is little reason to do this.

Improve this answer
0

Because of different architectures and a common format that can be adapted to the platform at hand.

And possibly because of the vm code being less than comparable platform machine code if scripting language engine codes for garbage collection, hashes and stacks are also included that are referenced in.

Oh and as mentioned: single byte bytecodes instead of more complicated byte or word codes, easier to design.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.