Package for compiling Tcl bytecode into LLVM IR (and hence to native code). Depends on llvmtcl. (Used to depend on tclbdd during the development of some of the compiler reasoning engine; now removed.) May form the basis for the fastest path of the Tcl execution engine in 9.0; performance is good, but dependencies are complex.
Note that the aim is to try to avoid most of the compromises that other compilers have had to put up with. It does this by starting from the same bytecode that Tcl code already compiles to, and by leveraging the same runtime that the standard Tcl uses. Instead of needing lots of explicit type hinting, it instead tries to work out what is going on at the type level by examining the types that are implicitly present. When coupled with a modern compiler/optimisation engine core (LLVM) this can produce pretty good code, yielding native machine code on the platforms supported by both Tcl and LLVM (a substantial overlap).
New location: https://core.tcl.tk/tclquadcode
Old location: https://chiselapp.com/user/kbk/repository/tclquadcode
This package can sometimes make code that is stunningly faster than standard Tcl. Seriously fast. It depends on what the code is doing though.
|Performance Category||General Speedup Expected|
|Numeric code: integers||20 to 25 times|
|Numeric code: floating point||around 10 times|
|String code||often about 50%; sometimes less|
|Structure code: lists and dicts||around 2 times|
|Error handling||around 2 times|
|Global variables||probably no big change|
|I/O code||no significant change (not a design objective)|
Note that optimisations can also be applied between procedures (provided all relevant procedures are compiled at once). This may make some code get an even greater acceleration.
One of the things we're doing is working out a type system for Tcl.
The ovals contain the discriminating operations -- they correspond to particular bytecodes even though they're not described as such -- and the rectangles contain the concrete types.
The key concrete types in practice are:
We don't yet distinguish between strings and lists and dicts and so on because they all currently resolve to a Tcl_Obj anyway.
ak - 2016-08-25 19:55:37
Is it possible to add a legend to the image ?
DKF: Not to the image (which is just converted from SVG) but I've added some notes above