4 ms·

This appears to be very heavily influenced by x86. Why would a VM built in 2011 use an ISA stuck in the 80's? EDIT: I'm not trolling, I'm seriously wondering.

by maaku 15y ago

This appears to be very heavily influenced by x86. Why would a VM built in 2011 use an ISA stuck in the 80's? EDIT: I'm not trolling, I'm seriously wondering. There's plenty of literature out there on the advantages of three-operand instructions, large register spaces, and RISC-type instructions. Was there a reason that x86 was used as a basis?

aninteger 15y ago
I'm not the author but I guess there would be a few reasons: 1. Familiarity with x86 assembly. It's probably the assembly language that the majority of people who write assembly language know. 6502 probably being 2nd place 2. Easier to port small x86 assembly programs 3. Even if it's stuck in the 80's it's the most widely used assembly language and there are dedicated online communities of people still writing x86 asm today in 2011.
- xyzzyz 15y ago
  2. Easier to port small x86 assembly programs I seriously doubt that people will do it. If people write assembly, they mostly do it either because of speed, or because it's impossible to do in any other way. None of the reason is relevant in context of VM assembly, which is usually meant to be a compiler's target.
  - carbonica 15y ago
    Yeah - the vast majority of x86 assembly written today is written to take advantage of specialized instructions that aren't available in this VM.
carbonica 15y ago
The instruction set is vastly simpler than x86, but it does inherit some limitations for no reason. x86 had 8 named registers for so long because the mod_rm byte in x86 only has 3 bits for each operand. Adding the REX prefix byte in x86=64 complicates things a bit, but isn't too tough. This VM doesn't have a particularly compact in-memory encoding - it uses an entire `int` for each argument! They could double the number of registers and the entire register set would fit in a cache line (except for EIP) at 4 bytes apiece. I guess it is nice that all 9 fit in one line now, but I doubt that was considered.
sb 15y ago
Well, at least in the area of virtual machines and interpreters, the usual argument goes like this: A stack-based virtual machine architecture has compact code representation (only bytecodes) where operands are pushed onto and popped of the corresponding argument stack. Register based VM-architectures require you to encode source and destination registers into the operations. IIRC, for Java bytecode, going from a stack-based representation to a register-based virtual machine grew the code size by more than 40%. But on the other hand interpretation got more efficient, since you have less instructions overall and thus fewer instruction dispatches. If you want more details I'll gladly point you to the excellent and canonical reference for this: Shi, Casey, Ertl and Gregg: "Virtual machine showdown: Stack versus registers." TACO http://dl.acm.org/citation.cfm?id=1328195.1328197 http://dl.acm.org/citation.cfm?id=1328195.1328197 (There is also the journal article's predecessor from VEE05, https://www.usenix.org/events/vee05/full_papers/p153-yunhe.pdf https://www.usenix.org/events/vee05/full_papers/p153-yunhe.p...)

by maaku 15y ago

aninteger 15y ago

I'm not the author but I guess there would be a few reasons: 1. Familiarity with x86 assembly. It's probably the assembly language that the majority of people who write assembly language know. 6502 probably being 2nd place 2. Easier to port small x86 assembly programs 3. Even if it's stuck in the 80's it's the most widely used assembly language and there are dedicated online communities of people still writing x86 asm today in 2011.

xyzzyz 15y ago
2. Easier to port small x86 assembly programs I seriously doubt that people will do it. If people write assembly, they mostly do it either because of speed, or because it's impossible to do in any other way. None of the reason is relevant in context of VM assembly, which is usually meant to be a compiler's target.
- carbonica 15y ago
  Yeah - the vast majority of x86 assembly written today is written to take advantage of specialized instructions that aren't available in this VM.

carbonica 15y ago

The instruction set is vastly simpler than x86, but it does inherit some limitations for no reason. x86 had 8 named registers for so long because the mod_rm byte in x86 only has 3 bits for each operand. Adding the REX prefix byte in x86=64 complicates things a bit, but isn't too tough. This VM doesn't have a particularly compact in-memory encoding - it uses an entire `int` for each argument! They could double the number of registers and the entire register set would fit in a cache line (except for EIP) at 4 bytes apiece. I guess it is nice that all 9 fit in one line now, but I doubt that was considered.

sb 15y ago

Well, at least in the area of virtual machines and interpreters, the usual argument goes like this: A stack-based virtual machine architecture has compact code representation (only bytecodes) where operands are pushed onto and popped of the corresponding argument stack. Register based VM-architectures require you to encode source and destination registers into the operations. IIRC, for Java bytecode, going from a stack-based representation to a register-based virtual machine grew the code size by more than 40%. But on the other hand interpretation got more efficient, since you have less instructions overall and thus fewer instruction dispatches. If you want more details I'll gladly point you to the excellent and canonical reference for this: Shi, Casey, Ertl and Gregg: "Virtual machine showdown: Stack versus registers." TACO http://dl.acm.org/citation.cfm?id=1328195.1328197 http://dl.acm.org/citation.cfm?id=1328195.1328197 (There is also the journal article's predecessor from VEE05, https://www.usenix.org/events/vee05/full_papers/p153-yunhe.pdf https://www.usenix.org/events/vee05/full_papers/p153-yunhe.p...)