Is ScummVM not an Scumm emulator?
As I understood it the difference between a VM and an emulator is that a VM runs cpu instructions directly, which seems not to be the case here.
As I understood it the difference between a VM and an emulator is that a VM runs cpu instructions directly, which seems not to be the case here.
It doesn't really make sense to call it a SCUMM emulator, ScummVM has a reimplementation of the whole engine.
Of course there's also other engines in ScummVM, some based on the original source kindly donated to us by the developers, but most created by painstaking disassembly.
ScummVM does have emulation for various pieces of audio hardware but that's the only part I would consider emulation.
The language is bytecode based, and interpreters for bytecode are also called a "Virtual Machine".
And when does a game engine, become a language, become a (virtual) machine.
As I understood it, scumm was basically an interpreter, where the instructions don't really bare any resemblance to processor instructions, so a virtual machine is impossible (or the distinction meaningless).
DosBOX is an example of an emulator. It is not an implementation of DOS, it just pretends enough to trick games to run. Emulators usually just translate high level semantics without simulating the real system in any way.
This would be neither a Python implementation nor a Python VM - but it would be a Python emulator for the Ruby VM.
But if someone wrote their own Python interpreter, like PyPy, this is a new Python VM implementation.
Scumm as far as I'm aware never existed on ARM, ( or Risc V for the sake of argument), so ScummVM on those platforms are in a sense Python on Ruby.
This is of course hugely muddy. Nim for example can target C and Javascript, neither is an emulator, I'm not sure a 3rd target by a separate developer would be either?
A true Scumm emulator would translate Scumm script to another game engine like SGI (Sierras game engine), but of course due to the extremely high level nature of these game scripting engines finding direct translations would be near impossible.
- "Virtual machine" is a term that means a lot of things in different contexts. Your last example refers to hardware or operating system virtualization (VMWare, Docker, things of that nature). These VMs are intended to replicate a full computer system as a subprocess of another (physical) computer system. Typically this is not about replicating the direct hardware details: it would be odd to have an Ubuntu VM with 4GB of RAM directly specified. Rather there is a general Ubuntu VM and the user allocates 4GB of their own memory to the virtualization process.
- "Virtual machine" is also widely used for application virtualization: the Java virtual machine, for instance, and ScummVM. These VMs are not intended to replicate a full computer and exist to run applications in a way that abstracts away the hardware implementation details. For your second point, "VM" is arguably misapplied to things like JVM and Python VM, but I think the analogy is still useful, and regardless that battle was lost 40 years ago.
In practice "Application Virtual Machine" is taken to mean "compiler or interpreter for general purpose non-native code" but this does not have to be the case. There is nothing inherent about using a more limited set of instructions. Going left-right in terms of processor-level instructions, all of the following can be described as actions using VMs:
using Xen to virtualize a Unix machine - running Debian in Docker - running a web server in Java - scripting in Python - Day of the Tentacle
- An "emulator" is a computer program that models the hardware of another computer system and executes machine language written for that system. An emulator typically carries the hardware specifics of the system it is emulating - in industry emulators are widely used to test new hardware without having to waste physical resources, so having an exact replica is important. For gaming, I suppose it could make sense to double the RAM in an N64 emulator to reduce performance bottlenecks, but it wouldn't be a faithful emulation and would probably be nontrivial to implement without breaking existing games.
I agree that the differences between these are fuzzy. In some sense you can think of an "emulator" as an application virtual machine whose bytecode is the machine language of the hardware the emulator is emulating. I would go so far as to say there isn't a theoretical difference. In practice, the difference is that emulators are used to faithfully run existing compiled applications, including all the unreliable quirks - an emulator that fixes bugs which exist in the hardware is not a good emulator. Application VMs are used to reliably execute new applications (including updates designed to remove unreliable quirks). The use cases and requirements are different enough that I don't think there's much actual confusion.
In another sense emulators are performing hardware/operating-system virtualization into the older system. I think the most salient point is the importance of preserving existing hardware in an emulator. Theoretically you could see someone creating a VM image for KERNAL that can run Commodore 64 8-bit processes on a 64-bit architecture with an arbitrary amount of RAM. But in practice emulators that carry the C64's hardware restrictions are much more useful, since people writing code for C64 hardware typically want to run it on an actual C64.
As one last incredibly pedantic note: there is also genuine fuzziness between OS VMs and application VMs. You can think of the JVM or Python VM as "emulating" a hypothetical processor architecture with Java/Python primitives as fundamental machine-level operations - there used to be physical LISP machines designed like this. Since Java and Python are Turing complete and their bytecode sort of resembles a very verbose assembly, I think the analogy is in fact useful. But this analogy also extends to ScummVM - think of a hypothetical LucasArts arcade cabinet where SCUMM primitives are hard-coded into the processor.