From: | Rupert Brauch <brauch@hpp.stanford.edu> |
Newsgroups: | comp.lang.java,comp.lang.c++,comp.compilers |
Date: | 6 May 1996 23:21:07 -0400 |
Organization: | Stanford University |
References: | 96-05-036 96-05-038 |
Keywords: | Java |
>There is nothing to stop the C++ people from implementing their own VM
>and JITs and portable AWT after the manner of Java. However VM for
>C++ would need to be quite different. It would have to nail down the
>rules for embedding struct layouts precisely, and the internal formats
>for big-endianess and packing slack bytes. The Java VM does not have
>to do that. Java IS the end result of squeezing C++ into portable
>form, so you might as well fly with Java.
There's nothing particularly magical about a VM for C++. OmniVM
(Lucco, Wahbe, et al) is essentially a RISC style IR. Fault isolation
code is inserted at load time, when the VM code is translated. The
fault isolation code sandboxes the untrusted code, preventing it from
loading, storing, or jumping to, addresses outside its address space.
The VM is endian neutral, which means that the programmer isn't
allowed to make any assumptions about the endianness of the target
machine. That may seem like a pain, but I don't know of a way to
translate code that assumes one endianness to run on a machine with
another endianness.
There are a bunch of reasons why you wouldn't want to fly with Java.
You may have existing code that you don't want to rewrite in Java.
You may not be able to live with the overhead of interpreted code,
etc.
-Rupert
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.