Slim binaries store an architecture-neutral representation of the program that can be efficiently converted to native machine instructions at load time. The representation is compact and loading times (from mass storage or networks) is good, compensating for the extra work required to generate the native instructions on the fly.
AK: 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 referring to the Oberon sources, a defunct reference to a slim binary decompiler [2 ], 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 [1 ]. 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. >:(
Ro: 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.
AK: 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.
Ro: Well hopefully you'll get an answer. Thanks for keeping us apprised of the situation ;)
AK: Ok, none of the people I have sent mail to have answered so far. Seems we are on our own in this.
BdT: 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 :-).
On one of the Oberon days in Zürich, Jürg Gutknecht mentioned that Michael Franz deliberately obfuscated the encoding scheme and this was the reason for being unable to extend the format.
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
Zarutian 2005-01-25: 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 [6 ].
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 2005-01-27: well it still half-baked (IS: hálfkák)
Zarutian 2005-06-15: 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.
GNU Lightning seems to be an implementation of a similar idea.