[virtmach] Definition a virtual machine ?

Dwight Hughes dwighth@ipa.net
Wed, 17 Nov 1999 18:18:36 -0600


I am very much on the side of the "language people" in my views of what
actually is or is not a "true" virtual machine. However, as for the
question of what is or is not topical for this list -- I would include
both viewpoints Ian describes of what a virtual machine is as topical. 

Since one big interest of mine is in running virtual machines (language
view) directly on the metal, the information and views on virtual
machines (OS view) are very much of interest to me, since I personally
view such things as a natural part/component of a true VM (my view).

-- Dwight

Ian Piumarta wrote:
> 
> > How would you define a virtual machine ?
[...some good comments snipped....]
> In general OS people tend to draw the "line" in a place that excludes
> the instructions used to execute user programs but includes changing
> the semantics of the physical resources of the machine without
> changing their surface characteristcs.  (But I vaguely remember that
> the 360 had something called "usercode" -- I think it was a
> "simplified" instruction set interpreted by the OS???)  Language
> people tend to draw it in a place that includes the instructions used
> to execute programs, but excludes fiddling with the meaning of
> physical resources such as memory.
> 
> I don't think it's possible (or even realistic) to try to define a
> virtual machine in terms of what it should or shouldn't have (complete
> instruction set in software, a virtual memory implementation,
> whatever...), since wherever you draw the line you'll be making
> someone unhappy.  The best we can do (and I think someone already
> hinted at this) is to say that a VM is *anything* that extends the
> programmer's view from that of running the bare hardware -- a
> definition which subsumes both the "OS" and the "language"
> interpretations of "virtual".  And like someone else already said, the
> existence of a rich, complete virtual instruction set -- bytecoded or
> otherwise -- is just an implementation detail related to where one
> chose to draw the line between abstract and concrete.