Re: Anybody has experience with SLIM BINARIES?

Our esteemed moderator writes:
>[I would carefully investigage the many failed UNCOL projects over the
>past 40 years to be sure you understand why creating and using a
>common intermediate code is much harder than it looks. Slim binaries
>are a fine idea for Macs where you have different instruction sets
>with identical operating systems and data formats. As soon as you
>have more moving parts, the idea starts to collapse. -John]


While I agree with the cautions expressed by John, I would like to
point out that Slim Binaries suffer no more in this respect than the
Java virtual machine. The portable execution domain popularized by
Java byte-codes is sufficiently constrained to enable the creation of
a reasonable intermediate form which runs on all systems. The trick,
alluded to by John, is the common virtual machine. Under the auspices
of the Oberon system (which can be considered a high-level virtual
machine), slim binaries have made it possible to run the same
"executable" on PowerPC, M68K, and Intel based machines.


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. The difference is
largely the amount of high-level vs. low-level information retained in
the intermediate form (a fact which may have ramifications for
optimization.) The fact that it has not been developed to the extent
of the JVM is more a function of insufficient marketing and
development than of actual technical failings.


Mark


--
Mark K. Gardner (mkgardne@cs.uiuc.edu)
University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--

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