|[13 earlier articles]|
|Re: Do we really need virtual machines? email@example.com (2004-10-12)|
|Re: Do we really need virtual machines? firstname.lastname@example.org (2004-10-17)|
|Re: Do we really need virtual machines? Colin_Paul_Gloster@ACM.org (Paul Colin Gloster) (2004-10-21)|
|Re: Do we really need virtual machines? email@example.com (Paul Robinson) (2004-12-17)|
|Re: Do we really need virtual machines? firstname.lastname@example.org (glen herrmannsfeldt) (2004-12-19)|
|Re: Do we really need virtual machines? email@example.com (Tobias Bergmann) (2004-12-22)|
|Re: Do we really need virtual machines? firstname.lastname@example.org (2004-12-23)|
|Date:||23 Dec 2004 21:38:02 -0500|
|Organization:||AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com|
|Posted-Date:||23 Dec 2004 21:38:02 EST|
Paul Robinson <email@example.com> schreibt:
>A Virtual Machine solves one problem and only one: allowing a
>particular binary program to be operated in a non-compatible
I'd emphasize that a VM allows to run /any number/ of according
programs, on any machine where the VM is implemented. What's easier,
porting n programs or 1 VM?
>There are a number of areas that a virtual machine does not solve,
>including source portability (care to say that you are certain you
>can run a program unchanged on two different machines that use the
>same virtual machine environment?
IMO a carefully designed VM can be implemented on any appropriately
equipped target machine, regardless of the OS. Problems may arise from
libraries which bypass the VM and interact directly with the OS. A
portable VM is useless without a portable library!
>execution efficiency in critical environments
Should not be a problem, the environments become faster every day ;-)
>nobody writes a boot loader to run in multiple virtual machine environments)
>and graphics standardization
IMO every machine and OS allows to paint pixels on (part of) the
screen, so that this point is not a matter of compatibility.
>I don't think GCC would qualify as a virtual machine as I think code
>is generated to run natively, not to be interpreted.
As mentioned above, GCC can be considered as being a well designed VM, but
problems are near inevitable with the libraries :-(
>You would also have to rewrite the compiler's I/O routines to handle
>differences in file management.
That's not necessarily a big deal, in the easiest case the VM can come
with it's own file system. Then only the access to the file, that
contains the file system, has to be re-implemented for every target
Considering what I've said before, I think that a VM is only part of a
portable OS (VS = Virtual System). The VM has to be designed for
portability to a broad range of machines, and the VS accordingly
should be portable to as many OS as possible. It even may be possible
to define an abstracted hardware interface, so that the VM and VS can
operate on any machine for which the hardware interface can be
implemented, for the according CPU and devices. In a "native" port the
access to the devices should be no big problem, whereas in a "hosted"
port the access to the devices can be restricted by the hosting OS.
Return to the
Search the comp.compilers archives again.