Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM

[ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe)]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>There already one such thing. It's called slim binaries...

>Oh goodness, this is an OLD OLD idea, P-code is of course one of the earliest
>and best known attempts (there was a whole technology of native code 
>generators, and no doubt you could find a SMS sales person willing to make
>the same absurd claim of 100% portability with native performance that is
>always bandied about for such systems.

Nope.  "Slim binaries" are absolutely NOTHING LIKE P-code.
Slim binaries are based on two ideas:
    - source code compresses very well
    - IO is slow.

Slim Binaries are used in the Juice system, currently available for
PCs and PowerMacs.  The idea is very simple, and the implementation is
rather elegant.  The precompiler parses a source file, does all the
static checks, may make other completely portable transformations,
and then emits

    > compressed annotated abstract syntax graphs <

At run-time, the Juice system reads the slim binary, decompressing and
building the AST as it goes, and then runs a normal compiler back end
to generate native code.

>But there are literally dozens of designs and attempts in this direction,
>it is after all a perfectly obvious idea, closely related to the ancient
>UNCOL proposal.

Just how obvious is it?  Everybody else seems to have tried to invent some
kind of abstract machine.  The Oberon people seem to be the only people
who really noticed that source code compresses so well and discs are
(relatively) so slow these days that NOT having any kind of 'object' code
would yield a _faster_ system over-all.  They claim that they spend _less_
time decompressing and generating native code into memory than they used
to spend relocating conventional machine code, in large part because the
files are _dramatically_ smaller.

I have just spent a day trying the idea out for another language, and
gzipped stripped source code is about 7.5 times smaller than the existing
"portable object files" for this other language, to the point where the
great majority of modules take less than 8k.

With slim binaries, you get 100% of native performance BECAUSE YOU RUN
ONLY NATIVE CODE, generated by a perfectly conventional in-core compiler
back end.  If you look at a modern object file format like ELF, you will
appreciate that parsing object files is a non-trivial task, and that
object files are typically fairly large.  For example, a slim binary
doesn't _need_ a separate line number section, or a separate symbol
table, or a separate anything.

>For a slightly more credible attempt,

Slim binaries are as credible as anyone could wish for.
They apply well understood techniques in a novel way, and anyone
who wants to suck-it-and-see can download a copy of Juice and
measure loading times for himself.

-- 
Unsolicited commercial E-mail to this account is prohibited; see section 76E
of the Commonwealth Crimes Act 1914 as amended by the Crimes Legislation
Amendment Act No 108 of 1989.  Maximum penalty:  10 years in gaol.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.