This page is for discussion of, and hopefully eventual documentation of the tcl Virtual Machine. - [CmCc] ---- ''Some interesting/funky stuff about the tcl VM'' * tcl's compiler does lazy compilation. The compiled object has a component called the literal table in which it stores string literals ''including'' the bodies of things like foreach and if commands. I'm not yet sure how, but it would seem that when the foreach is evaluated, it can compile its body from the literal table entry, and then substitute the resultant compiled object into the literal table of the compiled object in which it occurs. I consider this quite funky. ---- There's recently been some discussion about using Parrot for tcl, and it seems as well that we should start to gather some discussion about what we've got before we worry too much about Parrot. To kick this off, I've put up some tools and toys I've been using to explore the tclVM. It can be found here [http://sourceforge.net/projects/libtclpq/] ---- [AK]: Got me the tclVM tools. I found one problem. My tcl8.3.so does not have a public variable 'tclInstructionTable'. This prevents tclVM.so from loading. I did the following changes to get it loading: * renamed the variable (slashed off the 'tcl' prefix). * Added code to 'tcl_InstTable' to initialize the now internal variable, using the private tcl API 'TclGetInstructionTable ()'. Notice I said loading. It does crash somewhere during execution. ... Hm, got a NULL-pointer. Hm, maybe this is 8.4 specific. Will have to play more. ... [AK]: Ok, in my system the variable in the tcl library is 'instructionTable' ... And the moment the code tries to initializes its data for the second instruction it dumps core. --- It consists of the following commands: compile string: takes a string, representing a tcl expression, and returns a Tcl_Obj of the compiled object type. disasm compiled_obj: returns the bytecode component of a compiled object. literals compiled_obj: returns the literal table of a compiled object instTable: returns a list of the names of all opcodes and their operands, in opcode order. Each opcode has an entry in the list as follows: {opcode name, number of bytes in the opcode, stack effect of opcode, number of operands, optype, ...} Each optype is one of: * none * int1 - one byte signed integer * int4 - four byte signed integer * uint1 - one byte unsigned integer * uint4 - four byte unsigned integer ---- Will there eventually be eight-byte signed and unsigned integers? ''[escargo] 13 Nov 2002''