Re: Anybody has experience with SLIM BINARIES?

mkgardne@cs.uiuc.edu (Mark K. Gardner) writes:


{stuff deleted}
> While Java is compiled to a low-level intermediate form and translated
> to machine code during loading (a.k.a., just-in-time translation),
> slim binaries are compiled to a high-level intermediate form and
> likewise translated to machine code during loading.
{stuff deleted}


I wouldn't characterize the Java Bytecodes as "low-level" in any sense
of the word. The byte codes are really very close to being just a
compact representation of the AST of the program. The fact decompilers
can convert byte-code back very readable Java source from .class files
should tell you something about the JVM. Shipping .class files around
is not that much different from shipping your source code. This of
course opens up lots of opportunities to do link time optimizations
and whole program optimizations.


The OmniVM (See PLDI 96) is a much better example of a low-level
"intermediate" form. If I remember correctly they retargeted gcc and
compiled several programs from the SPEC suite with it. They got very
good performance on lots of processors. (%5 worse than binaries
produced directly from gcc on Sparc, MIPS, x86, and PowerPC) I even
saw a demo of MS Word being dynamically translated to x86 code from
OmniVM (see PLDI 97). You couldn't tell the difference between the
OmniVM version and the native version. I think it's quite possible to
have an UNCOL like language today. The OmniVM is proof. The only
really hairy issues are the system level ones. (i.e. standardizing
APIs....)


Considering DEC has technology to translate VAX, x86, and MIPS
binaries to native Alpha code. Not to mention the fact the MacOS
emulates M68K code. I think there's even a MIPs to Sparc
translator. You ought to get the hint that processors architectures
aren't all that divergent.


Of course you do pay a performance penalty for the portability. I'd
claim it's small enough not to worry about for the majority of
consumer software.
[Danger! UNCOL alert! When you don't try to do very much, UNCOL-ish
approaches work. That's why they're so seductive. The DEC and MacOS
translators are working with fixed operating systems and data formats,
so they work well. The SPEC suite has very simple interactions with
the operating system, so they're easy to port. Dunno about MS Word,
but its targets are limited, too, Windows and Mac. Just don't think
this approach generalizes farther than it does. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.