While learning about the Tcl bytecode VM with Donal's disassembler, I've
accidentally run into another instance of a bytecode VM, which is rather
It is Flash Player's VM. The bytecode is produced by a Flash compiling
For a very well-written introduction to both the VM and a fabulous
assembler-disassembler allowing to incrementally modify an existing .SWF
file, see http://flasm.sourceforge.net .
What's the link with Tcl ?
First, the scripting language (based on ECMAscript) shares some key runtime
features with our beloved language: dynamic typing, automatic conversions,
exceptions, functions accessed by name.
Clearly the fit with Tcl_Obj's dual-ported representation would be perfect
(possibly even better than in the (undocumented, closed-source) Flash
player, whose degree of shimmering is unknown...)
Second, I find the VM's scarcity of primitives interesting when compared to
Tcl's 94+ ones.
I would love to hear the Tcl VM creators argue about this. From a cursory
reading, the generic recipe in Flash to avoid primitive proliferation is to
have *all* function calls made by name, like invokeStk1 in Tcl.
Of course this doesn't mean a hash lookup every time. The string constant
themselves are indices in the literals table (I'm translating to Tcl-core
terminology, they are named differently in Flash), so it would be quite easy
to cache a function address next to them.
Why didn't we do the same in Tcl ? Why do we have special bytecodes for
lappend etc... ? Speed ? No way to get 99% of this speed through smart
cacheing of integer indices or addresses ?
Another interesting aspect of this is the whole new branch of activity
opened by 'flasm': incremental modification of bytecodes for various
First obvious use is learning the mechanism. Second is tweaking hard-coded
strings (I came to it through that door). Third is optimization: people
hand-tune games -- the result is sometimes impressive !
Q: shouldn't we do the same in Tcl ? Or is the bytecode compiler already
making superhuman optimizations ?