Abstracted from Tcl 9.0 WishList in order to keep that page easier to read
Micro Tcl. It should be made easier to separate out features that are unlikely to be needed in embedded systems. Ideally, only a handful commands like set, while, proc, uplevel, upvar, catch, expr and a reduced version of load should be in the interpreter, with everything else linked in as static packages. The reduced load command could then be used to initialize all the other stuff as needed.
LV - I notice that there is a note at http://www.procplace.com/download.html that Karl Lehenbauer mentions they have a micro tcl, but that it isn't quite ready for prime time - perhaps we can once again borrow from the master (Karl was one of the two primary instigators who created Extended Tcl (TclX) and a number of features from that have made their way into Tcl Prime...
DKF - I looked into this once, and the problem is that a lot of the stuff you need to exclude to reduce the size is in fact the core code which can't be excluded anyway. You need namespaces, stubs, i18n, basic value parsing, variables and the interpreter to operate at all. While you could exclude some of it (top targets are the compiler, RE engine, and date string parser) I'm not sure that these would save you enough. Command load itself is not what you need to tackle, but rather functionality weight...
Volker - Ok, the bigger problem here is to leave out things that are hard to port, like i/o and (as you said) the time/date stuff. Leaving out the compiler would be nice to have but it's not a real show stopper when porting tcl to embedded systems.
Chang - My plan is to get all the commands out of the kernel. Then you could add commands in progressive way. parse, i18n, byte code compiler, stubs are included in the kernel.
Volker - Looks great! Then we could use the parser and set up our very own two or three supported user commands.
Vince - once the new VFS support has been added to the core (TIP 17), it should be very straightforward to remove all filesystem stuff from the micro-kernel.
JCW again - Now that Critcl exists, it has become easier to start modularizing the core. As an example, "xre" in CritLib [L1 ] takes all of the regex/regsub code out and turns it into a loadable extension. Names have been changed to xregex/xregsub. That's over 10,000 lines of C, and about 1/8th of the Tcl binary code. See http://www.equi4.com/critlib/xre.README
Larry Smith - It occurs to me that using tcc in a version of critcl along with a small core of functions would provide a tiny interpreter with the ability to bootstrap into today's tcl and beyond. The bytecode compiler could be eliminated. Anyone wishing speed would code in inline-C, most functions would simply be interpreted tcl.
PWQ 6 Dec 04 , There are two distinct classes of embedded system. The most common definition is a device with 64M ram, a 200MHz processor, running a multitasking OS like Linux or WinCE. In this case there is little point reducing the size of TCL. The effort would be better spent in making TCL faster on these systems due to the lower clock rate compared to desktop PC's.
The second are micro-processor systems with limited RAM (10K to 1M), a processor clocking at 4-20MHz, with RealTime OS or no os ar all.
In the latter case , there is no point trying to shoehorn TCL into these systems as they just won't fit. TinyTCL is more able to be accommodated due to the string based approach. However string manipulations are not going to cut it on a processor with such a slow clock rate.
These systems need a hand crafted interpreter optimized for the resource set and task at hand. The Tcl_Obj structure would need some serious trimming to make a practical application.
My own efforts have settled on a variable length header, much like that used in Smalltalk. This way we have the most efficient object store with only a small amount of extra processing.
UK PWQ your second is actually the third type. The second type has ~4-16M Ram and Flash and one of SC400/SC520 MC68000/10/20/30/40 or ARM7 or MIPS CPU. With Linux and one of the RealTime extensions these are perfect for net-enabled Instruments. I have build Spectrometers and Dish Antenna Controllers with these. A small footprint TCL would be perfect for these.
KJN A fourth type (not really embedded) is software that requires a scripting engine with minimal footprint. Some commercial games use Lua, which is even smaller than Tcl.
Steve Bennett Jim attempts to be a very modular Tcl. Many features considered core in Tcl can be built as loadable modules, or compiled out entirely.
./configure --help
...
--with-jim-ext="ext1 ext2 ..."
Specify additional jim extensions to include.
These are enabled by default:
aio - ANSI I/O, including open and socket
eventloop - after, vwait, update
array - Tcl-compatible array command
clock - Tcl-compatible clock command
exec - Tcl-compatible exec command
file - Tcl-compatible file command
glob - Tcl-compatible glob command
readdir - Required for glob
package - Package management with the package command
load - Load binary extensions at runtime with load or package
posix - Posix APIs including os.fork, os.wait, pid
regexp - Tcl-compatible regexp, regsub commands
signal - Signal handling
stdlib - Built-in commands including lassign, lambda, alias
syslog - System logging with syslog
tclcompat - Tcl compatible read, gets, puts, parray, case, ...
These are disabled by default:
bio - Binary I/O, mostly for bio copy/file copy
nvp - Name-value pairs C-only API
oo - Jim OO extension
tree - OO tree structure, similar to tcllib ::struct::tree
readline - Interface to libreadline
rlprompt - Tcl wrapper around the readline extension
sqlite - Interface to sqlite
sqlite3 - Interface to sqlite3For example, it is possible to build without I/O, array, regexp and exec. Here are the core commands when no extensions are configured:
alias append break catch concat continue curry dict env error errorInfo eval exit expr for foreach format global if incr info join lambda lappend lassign lindex linsert list llength lmap local lrange lrepeat lreplace lreverse lsearch lset lsort proc puts rand range ref rename return scan set source split stackdump stacktrace string subst switch tailcall time unset uplevel upvar while
Essentially the core has: list/dict/string support, core language features (proc, catch, for, foreach, while), expr, format, scan and subst
Certain features, such as support for references and UTF-8 can be enabled or disabled at compile time.