Tcl '''bytecode''' is the instruction set targeted by [TAL]



** Documentation **

   `$[tcl_traceExec]`:   



** Reading **

    [http://en.wikipedia.org/wiki/Bytecode%|%Wikipedia]:   



** See Also **

    [Parsing, Bytecodes and Execution]:   

    [Playing bytecode]:   
        
        [Brute force meets Goedel]:   

    [Proc to bytecodes: when, how does it happen]:   

    [Commands affecting Bytecoding]:   

    [The anatomy of a bytecoded command]:   

    [Why compile to bytecode]:   

    [bytecode dissasembly and/or examination]:   

    [script compilation]:   



** Description **


[DKF] 2003-01-06 (from [.NET]):  

... the current Tcl [bytecode%|%bytecodes] are defined at a level that is meaningful to Tcl, not at a level that virtually any other bytecode operates at; very few bytecodes have an opcode for "increment-hash-entry-and-fire-attached-traces"!  Given that, you're either just producing another language reimplementation (like [Jacl]) or you're taking on the hard task of defining how to go from Tcl to the fairly-common low-level register-based bytecode engines that so many other languages use.  Which would be nice and useful, but is a really huge (and ''definitely'' complex and deep) task...



** Why Byte-Coded Commands Can Be Faster Than C-Coded Commands  **

Byte-Coded commands are sometimes faster than commands implemented in an
external language like [C].  [MS], [Tcl Chatroom], 2013-12-31, offered these
reasons:

   1.   Byte-coded commands access local variables directly, whereas commands implemented in C have to resolve them at runtime.

   1.   Dispatch to an external command is slower than dispatch to a byte-coded command
   
   1.   Often, only the most frequently-used code-paths of a command are byte-coded, and corner cases fall back to the C implementation of the command.


<<categories>>Internals