[Richard Suchenwirth] 2007-10-09 - tcltcc is a Tcl extension wrapping [tcc] (the tiny [C] compiler), which was modified by [MJ] so it: * can do file I/O via [VFS] * is loadable as a Tcl extension * uses Tcl's ck* memory allocation commands LGPL, download at http://code.google.com/p/tcltcc/ . Like [Odyce], it also comes with a partial [Critcl] API emulation, so hopefully (at least some time in the future) people can just code against a subset of the [Critcl] API and run it with any of the three :^) For one example usage, see [ci - a tiny C interpreter]. [MJ] 2007-10-09 - Tclcc now also builds and works (passes the testsuite) on Linux ---- The first (and pretty unique) use case for tcc is that it can compile directly into memory, even in an interactive session. Example: ~ $ tclsh % packa re tcc 0.2 % tcc::cproc sigid {int i} char* {return Tcl_SignalId(i);} % sigid 4 SIGILL is always included, so if you run into an interesting C function, it's evidently extremely easy to wrap it up and try it out. Like in [Odyce] (which also builds on [tcc]), even simple things can substantially reduce runtime if done in C: % tcc::cproc cadd {double a double b} double {return a+b;} % proc tadd {a b} {expr {$a+$b}} % time {cadd 1.2 3.4} 1000 19.777 microseconds per iteration % time {tadd 1.2 3.4} 1000 43.138 microseconds per iteration ---- '''Simple API for building DLLs''' [RS] 2007-10-13: Since a couple of days, tcltcc can also build shared libraries (currently only DLLs for Windows, tested on [Windows 95]). Here's a cute and simple API for that: package require tcc set n [tcc::dll ?name?] Prepares the making of a DLL. Name is generated if not given, and in any case returned. $n ccode string Adds the string (which can be many lines) to the source buffer. Useful for #include/#define etc. preprocessor directives, static internal functions, etc. $n cproc name argl rtype body Creates code to implement a Tcl command ''name'' with typed arguments ''argl'' of C return type ''rtype'' with the specified C ''body'', and appends that to the source buffer. $n write ?-name str -dir path -code string? Produces the DLL $path/$name[[info sharedlibextension]] by compiling the source buffer, creating an Init function which registers the commands as specified by ''cproc'' calls, and optionally adding the initialization code in ''string''. After this call, no other ccode/cproc/write calls are useful. Working example (from the test suite): test tcc-10.3 "new DLL interface" { set d [tcc::dll] $d ccode {static int fib(int n) {return n <= 2? 1 : fib(n-1) + fib(n-2);}} $d cproc fiboy {int n} int {return fib(n);} $d cproc hello {} char* {return "world";} $d write -name fiboy -code {Tcl_Eval(interp,"puts {hello Fiboy!}");} load fiboy[info sharedlibextension] list [fiboy 20] [hello] } {6765 world} For [introspection] and debugging, no cleanup takes place yet. You can see the generated code with set tcc::dll::${n}::code Ah, tcc is great fun... :^) - In the [Tcl chatroom], [Gerald Lester] asked for the converse functionality: wrap Tcl code into a C function that relieves the user of explicit [Tcl_Eval]. See [Tcl to C functions] ---- [RS] 2007-10-15: current tcltcc passes all tests (tcc.test, pingpong.test) on W95 and Win XP. ---- See also: [Critcl] ---- [Category Package]