From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_MSGID, SUBJ_ALL_CAPS autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,9e20292f693f1408 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: ADA CORE TECHNOLOGIES ANNOUNCES GNAT-TO-JAVA SYSTEM Date: 1997/09/19 Message-ID: <5vt73c$3nk$1@goanna.cs.rmit.edu.au>#1/1 X-Deja-AN: 273734584 References: <34196E8E.1790@gsfc.nasa.gov> <341B2309.4A41@ibm.net> <34204085.5377@ibm.net> Organization: Comp Sci, RMIT University, Melbourne, Australia. NNTP-Posting-User: ok Newsgroups: comp.lang.ada Date: 1997-09-19T00:00:00+00:00 List-Id: 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.