Invented by Michael Franz for the Oberon system.
http://caesar.ics.uci.edu/oberon/research.html#SlimBinaries
This mechanism is a way to store optimized machine-independent code in such a way that loading can convert it to machine code while loading. Due to the compactness of the representation, loading times (from mass storage or networks) is actually extremely good, compensating for the extra CPU effort required to generate real code on the fly.
The key work is Michael Franz's PhD thesis.
An essential reference from that paper is
by the same author. Note that this PDF is hard to read, it seems to contain raster images, not encoded text.
It's also a (perfect) way to define a portable "almost-executable" software format. See
Scratch Pad and discussions. Data from below will filter upward, slowly.
Comments on slim binaries: I was unable to find a specification of the slim binaries used by Oberon. The best I got from goog'ling the web, news:comp.lang.oberon , and news:comp.compiler were the authors (Michael Franz, Thomas Kistler) simply refering to the Oberon sources, a defunct reference to a slim binary decompiler [L3 ], and a proclamation of the author of said decompiler that the format as-is is a total hack and writing up a formal specification for it would make no sense [L4 ]. All of that was in 1999 and I can't seem to find newer references.
So if the we truly want to use something like slim binaries we might have to come up with our own variant. >:(
-- AK
I remember reading about the AST that the Oberon slim binaries use. You might also want to check out the Oberon books, I think Wirth collab'ed with someone on one of 'em. I'm sure there are papers on it on the web... check out citeseer. Ro
The papers are easy to find. I have now a whole collection of them. But a specification, or a more detailed explanation of their algorithm ? Nope. Zilch. ... Yesterday I read a paper which mentionend a prototype written in Python. I have now sent a mail to one of the authors of said paper, asking for the sources. We'll see. - AK.
Well hopefully you'll get an answer. Thanks for keeping us apprised of the situation ;) - Ro
Ok, none of the people I have sent mail to have answered so far. Seems we are on our own in this -- AK.
Here is a reference to a an abstract of a MS thesis (german Diploma Thesis :-) implementing SlimBinaries on the Intel platform: http://www.cs.inf.ethz.ch/group/wirth/stud_work/96mfda01/ the referenced PostScript is in german and not a very good structured PostScript :-).
AK: Reference list @ http://greywire.8m.com/greywire/portable.htm
JBR: Can someone explain how slim binaries is different from forth?
AK: My understanding of SB's: They contain the abstract syntax tree of the sources in compressed form. At loading time the AST is uncompressed and compiled to machine code, on the fly. The AST never resides completely in memory. Forth code is not an AST, right ? Just a series of words which, when executed, perform the desired application.
JBR: Yes, forth is a series of "words", either bytecodes, addresses or jmp instructions depending on the implimentation, which manipulate the virtual CPU. I didn't understand the acronym AST. When a forth compiler is invoked the list can be radically optimized as target machine code fairly easily. I envisioned the scripted compiler as a classic translator C -> RPN -> machine code. RPN is essentially an AST laid down depth first order. - RPN in Tcl
Some additional references: slim binaries [L5 ], Oberon and slim binaries [L6 ], Thesis contrasting Java bytecodes with slim binaries citing Franz [L7 ] -- escargo