This page aims at collecting ideas about tcl bytecodes and the parsing and execution framework of the core.
Karl Lehenbauer started this with a post to Usenet asking about a Tcl Assembly Language, essentially an assembler for tcl bytecodes. The following url references my answer as Karl's post didn't make it into Deja.com, just my answer [L1 ]. Please add the reference when it becomes available.
(The complete thread, except for Karl's original post, is at [L2 ]. One of the replies includes a long quotation from his message.)
Obvious additional extensions would be a disassembler and a decompiler, the latter converting bytecode back into a halfway readable Tcl script. This would devalue? all the Tcl compilers aiming at hiding script code, of course. (LV: Only if the recreated code was usable for much of anything...)
Paul Duffin asked for a mechanism for me to be able to byte compile my own commands. This needs the ability to register a byte code as mine, with associated callbacks etc and be called when my byte code is executed with full access to the execution framework.. Couldn't find Paul's post on Deja too, so please add the reference when it becomes available.
Andreas Kupries: The only thing existing in this area is my ParseTools package [L3 ] which makes the basic parser of Tcl available at the script level. An obvious extension would be a parser using this to recurse down into subscripts (if, while, ...). Preferably configurable via a script defining the argument types of the available commands and not having this hardwired into it.
Andreas Kupries: Now that TclPro is open source its tclparser package is another possibility.
XOTcl experiments with certain byte-code extensibility [L4 ].
Joe English has ideas on byte-code optimizations, as of spring 2002.
MS too, see MS's bytecode engine ideas.
KBK also, see The anatomy of a bytecoded command.
KBK: "Believe it or not, Tcl's regular nature means that saving byte codes isn't actually a win; reading byte codes using the loader is actually slower than generating them afresh from Tcl code.
Nevertheless, the byte code dump/load process is useful for those who don't wish to divulge their Tcl source code."
AK: Note that the TclPro bytecode dumper/loader converts a lot of the binary structurues using a variant of the ascii85 encoding, thus burning cycles which could be spent better. Because of this it is not yet definitive to me that "saving bytecodes is no win".
elfring 2003-11-04 How do you think about a compilation into the code format ".NET intermediate language" [L5 ]? Would you like to cooperate with the projects DotGNU [L6 ] or Mono?