Re: Anybody has experience with SLIM BINARIES?

Paul van der Valk wrote:
> Portability, I guess,
> mostly boils down to how abstract (system-indepent) you define the
> API. Java seems to be doing pretty well on N platforms these days.
> Something similar could be done using slim binaries, only without the
> JVM overhead.


I completely agree with Paul. Portable transportability schemes are
only applicable if every target platform offers the same well defined
(syntactically and semantically) API.




Paul van der Valk wrote:
> I wonder how much effort it would take to create a (f.e.) BeOS
> backend [...]


IMO, the BeOS would not benefit from using any portable transportability
scheme at all, since its API is only available on PowerPC machines.
In contrast, Apple's upcoming release of Rhapsody would be perfectly
suited for Slim Binaries (or any equivalent technology) since it will be
available on different architectures (Intel, PowerPC) and offers an API
(Yellow Box) that is equivalent on all target platforms.




Daniel Wang wrote:
> 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.


I keep wondering then, why we go through the laboriously process of
compiling the source program into Java bytecodes, and reconstructing
the source code again from the bytecodes at load time if we could ship
the source code from the very beginning (which is basically what the
Slim Binary approach does). I know that some people argue that this is
all for the sake of interpretation but do we really need interpretation
on today's PC's?




Michael C. Werts wrote:
> As I understand them,
> slim binaries are not really an intermediate form at all, they are
> simply a compressed representation of the source program. Writing a
> loader for slim binaries would be essentially the same as writing an
> Oberon compiler (with some differences in parsing).


Slim Binaries are not really a compressed version of the source program,
but rather a compressed version of the parse-tree. The difference is, that
the latter case does not require re-parsing the program again at load time.




Paul van der Valk wrote:
> While on Slim Binaries: I agree that it's a great concept, but
> unfortunately progress seem to have stagnated a bit. At least I've
> seen little traffic around SlimBins on the net for half a year or so.


We are currently working on a Java front end for Slim Binaries to show
that our approach is not restricted to the language Oberon, but can be used
with most of toady's imperative programming languages.




Mark K. Garnder wrote:
> The fact that it [Slim Binaries] has not been developed to the extent
> of the JVM is more a function of insufficient marketing and
> development than of actual technical failings.


The main reason why we did not develop it to the extent of the JVM was
the lack of manpower. As a research project, our main goal was to show the
feasibility and practicability of the concept, rather than marketing and
selling a product.




Paul van der Valk wrote:
> [...] and if this is legally possible.


Slim Binaries and Juice are research projects of UCI. The source code is
freely available from our sites.




Thomas Kistler
(Author of Juice, the PowerPC and Intel Slim Binary loader)
--

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