Slim Binaries

Invented by Michael Franz for the Oberon system.

   http://caesar.ics.uci.edu/oberon/research.html#SlimBinaries

Because the above link doesnt seams to work I put it through the WayBack Machine: http://web.archive.org/web/20020617132121/http://caesar.ics.uci.edu/oberon/research.html

-Zarutian

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.

Title: Code-Generation On-the-Fly: A Key to Portable Software
URL: http://www.inf.ethz.ch/research/publications/data/diss/th10497.ps.gz
Alt.URL: http://www.ics.uci.edu/~franz/publications/V9403%20CodeGenOnTheFly.pdf

An essential reference from that paper is

Title: Universal Symbol Files
URL: http://www.ics.uci.edu/~franz/publications/J9310%20UniversalSymbolFiles.pdf

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

Juice [1] and
Mobile Code for Intrusion Tolerant Systems [2].

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 [3], 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 [4]. 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 :-).

BdT

AK: Reference list @ http://peoplecatcher.net/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 implementation, 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 [5], Oberon and slim binaries [6], Thesis contrasting Java bytecodes with slim binaries citing Franz [7] -- escargo

Zarutian 25. jan 2005: Here is a start on a probably nifty idea: syntax dictionary encoding and capabilities (Principle Of Least Access). I am still thinking how that can be implemented. To learn more about capabilities visit [8].

Regards -Zarutian

AK I went to the referenced site and it is not clear to me how it applies to the situation here. Can you elaborate ?

Zarutian 27. jan 2005: well it still half-baked (IS: hálfkák)

Zarutian 15. june 2005: hmm, apearently I was thinking about deploying crossplatform code (in syntax dictionary encoded form) which adhere to the Principle Of Least Authority (or Principle of Least Access namely not giving a program more authority or access than it needs to serve it's purpose) by the use of capabilities (actualy protected pointers similiar to Java's object references). That way, you dont need to grok (change) some security polices.