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 [http://x60.deja.com/getdoc.xp?AN=633778880&CONTEXT=960905848.1378353171&hitnum=0]. '''Please add the reference when it becomes available'''. (The complete thread, except for Karl's original post, is at [http://groups.google.com/groups?hl=en&threadm=m31z228vd2.fsf%40bluepeak.westend.com&rnum=1]. 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 [http://www.purl.org/NET/akupries/soft/ptools/] 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 [http://groups.google.com/groups?th=e5c3305c24c2964a]. ---- [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" [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netstart/html/cpcsvbvcjscript_start.asp]? Would you like to cooperate with the projects [DotGNU] [http://dotgnu.org/stereo.html] or [Mono]? [DKF]: I try not to think about .NET and related stuff (why not just run Tcl/Tk on the native machine and contact the .NET runtime via COM?) But don't let my opinions constrain you from reinventing the wheel here... ''somebody nameless'': Unfortunatelly .NET MSIL Code is not really language independant. You can use it for C, C#, Pascal, Forthan or Java but it will be not good for Smalltalk, Perl, Schema or Tcl (not to say about Prolog). You can write of course Tcl interpreter in MSIL but compile Tcl to MSIL is not possible. Or you would only compile parts of tcl code another were too dynamic (evals) and must be interpreted. MSIL do not support that all Tcl specific string operations, evals and other dynamic behavior of Tcl. MSIL whants type safe code and can use only it. There is are Smalltalk (smallscript) compiler for .NET (Smalltalk has also no types at compile time). It works so that it dupplicate all methods for every possible object type call. The idea to have one byte code for every possible language is not possible.