Version 11 of tclVM

Updated 2002-11-14 19:03:49

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 [L1 ]


AK: I should mention it, my platform is Linux.

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.

AK: Running it against 8.4, using the original sources ... compile is ok, load is ok, the result of the command 'instTable' looks ok. However the result of

 disasm {set x [clock seconds]}

is empty. Ditto for 'literals'. And running 'tclVM.tcl' still dumps core, but now in a way which suggests memory problems.

So, this extension is geared towards 8.4., and there seem to have been changes which prevents usage with 8.3., especially as it contains copies of internal tcl headers, like 'tclCompile.h'. ... Yes, the definition of the internal structure 'InstructionDesc' changed between 8.3 and 8.4.

AK: Crash - Yep, using tcl core with memory validation (CVS head), running 'tclVM.tcl', and seeing a high guard failure. No time to debug this, sorry.

... Removed reference to 'tclByteCodeType', and changed return value of disasm from 'string' to 'bytearry'. No crashing anymore after that. The crash was possibly due to misinterpretation of the bytecode as UTF8.


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