3 ms·

"VM design is never 100% language-neutral." The goal for VMs should be to create a generic enough base machine infrastructure such that you end up with the sam

"VM design is never 100% language-neutral." The goal for VMs should be to create a generic enough base machine infrastructure such that you end up with the same capabilities and flexibility that the x86, PPC or any other hardware/microcode based architecture provides. VM design may not be language neutral, then maybe some VM designers could learn something from hardware/chip designers. The very reason we're having this discussion is because ANY language can be implemented on ANY of the general purpose hardware architectures available. The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. Associating a VM with a runtime also confuses the technologies; admittedly this is often done because the company pushing their VM product has a vested interest in also providing developers with the tools and the libraries and the UI they program to.

ars 18y ago
Second system syndrome? You are reimplementing x86 - with no gain. Just use the actual x86 language. Or if you need multiple machines use C. C is your new VM programming language.
- eru 18y ago
  GHC actually moved away from using C as a target language. They call it a dead end for whatever reason. (They seem to be going to C--.)
blasdel 18y ago
The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. That's just superficial stuff -- the real VM language constraints are things like: calling conventions, type-checking, data structure semantics (esp objects), GC, and module interfaces. These are the kinds of things you want to have shared among languages if you want a useful multi-lang VM. Otherwise what's the point?
- eru 18y ago
  Type-Checking in the VM? One would have to think hard to accomodate a diverse range of type systems on this level. (And the Haskell guys keep expanding their type systems all the time.)
  - blasdel 18y ago
    "Type-Checking in the VM" means support for runtime type-checks, which can take several forms. In Haskell, all that type-checking is happening only in the early stages of the compiler -- and then the types are erased in the later stages.
- thwarted 18y ago
  See, but C, and the x86 architecture, has none of that, or it all can be changed (like calling conventions), and yet all languages and VMs can be implemented in C. Despite the explicit lack of support for those things, many C libraries are available with specific language bindings. That being said, those things can be _defined_ for a VM that still uses a flat address space and direct memory manipulation model of the x86 architecture. There is no support for objects or garbage collection or module interfaces in assembly or C, yet those things exist on top of it in languages that are implemented in C and run on x86 (or any usable architecture). There has to be a superset of many languages' conventions that can be used to define the semantics of calls, types, data structures, objects, garbage collection, modules, dynamic dispatch. This already exists somewhat as the ELF (and other) executable formats for things written in C.

ars 18y ago

Second system syndrome? You are reimplementing x86 - with no gain. Just use the actual x86 language. Or if you need multiple machines use C. C is your new VM programming language.

eru 18y ago
GHC actually moved away from using C as a target language. They call it a dead end for whatever reason. (They seem to be going to C--.)

blasdel 18y ago

The problem arises when things like sandboxed execution and optimizations for a specific runtime or language come into play. These are the kinds of things that tie a VM to a specific language and platform. That's just superficial stuff -- the real VM language constraints are things like: calling conventions, type-checking, data structure semantics (esp objects), GC, and module interfaces. These are the kinds of things you want to have shared among languages if you want a useful multi-lang VM. Otherwise what's the point?

eru 18y ago
Type-Checking in the VM? One would have to think hard to accomodate a diverse range of type systems on this level. (And the Haskell guys keep expanding their type systems all the time.)
- blasdel 18y ago
  "Type-Checking in the VM" means support for runtime type-checks, which can take several forms. In Haskell, all that type-checking is happening only in the early stages of the compiler -- and then the types are erased in the later stages.
thwarted 18y ago
See, but C, and the x86 architecture, has none of that, or it all can be changed (like calling conventions), and yet all languages and VMs can be implemented in C. Despite the explicit lack of support for those things, many C libraries are available with specific language bindings. That being said, those things can be _defined_ for a VM that still uses a flat address space and direct memory manipulation model of the x86 architecture. There is no support for objects or garbage collection or module interfaces in assembly or C, yet those things exist on top of it in languages that are implemented in C and run on x86 (or any usable architecture). There has to be a superset of many languages' conventions that can be used to define the semantics of calls, types, data structures, objects, garbage collection, modules, dynamic dispatch. This already exists somewhat as the ELF (and other) executable formats for things written in C.