|Do we really need virtual machines? Nicola.Musatti@ObjectWay.it (2004-10-02)|
|Re: Do we really need virtual machines? firstname.lastname@example.org (Scott Moore) (2004-10-02)|
|Re: Do we really need virtual machines? email@example.com (Dobes Vandermeer) (2004-10-02)|
|Re: Do we really need virtual machines? Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2004-10-02)|
|Re: Do we really need virtual machines? firstname.lastname@example.org (Basile Starynkevitch \[news\]) (2004-10-04)|
|Re: Do we really need virtual machines? email@example.com (Joan Pujol) (2004-10-04)|
|Re: Do we really need virtual machines? firstname.lastname@example.org (Scott Moore) (2004-10-04)|
|Re: Do we really need virtual machines? email@example.com (John Slimick) (2004-10-04)|
|[12 later articles]|
|From:||Scott Moore <firstname.lastname@example.org>|
|Date:||2 Oct 2004 16:17:54 -0400|
|Posted-Date:||02 Oct 2004 16:17:54 EDT|
Nicola Musatti wrote:
> Maybe it's just because when I learnt programming the p-machine was
> considered an interesting oddity, but with the exception of code that
> really must run unchanged on unknown platforms, I fail to see what do
> I gain from a virtual machine that I don't already get from a good old
> compiler/runtime support/standard library chain.
There is no requirement to virtualize code in order to gain
portability. Quite the contrary, what the JVM and other
implementations do is perform reference checking, and JVM even tries
to do that before running the code (virtually or not) in order to
enhance performance. Further, a good virtual memory implementation can
perform complete reference checking as well.
To be fair, I don't think anyone from the JVM or .net crowd is
claiming that virtualization is required for portability, otherwise
the just in time compiler ideas make no sense (I don't believe .net is
even has a virtual machine implementation).
100% portability with standard compilers is a worthwhile study (I
define 100% portability as recompile only). I would divide the
portability problem into sematics and enforcement. Semantics is having
the same code perform the same action on different implementations,
enforcement is making sure the program does not violate the rules
under which the sematics are garanteed to be correct. There seems to
be lots of agreement on sematics, but not much on enforcement.
Samiam is Scott A. Moore
Return to the
Search the comp.compilers archives again.