Hi,
[Note to lurkers in this thread: scroll down to see an interesting
breakdown of the code size of the functional parts of the Lua core.]
Vijay Aswadhati wrote:
1) Is it possible to fit Lua interpreter in under 16KB?
This is a tough requirement. With a bit of effort you can get
the Lua core (sans compiler, sans core libraries, sans CLI)
down to around 34K on x86. Removing the debug API glue and the
opcode names, replacing all error messages with shorter codes
and some other stuff like that might save you another 5-10K.
OTOH you need to add some code for the specific libraries
to control the embedded system. And some parts of a standard
ANSI C support library (strchr and so on).
Ok, so 16 bit code is typically tighter than 32 bit code.
But I guess not by a factor of two ...
2) Any helpful hints that you can offer in achieving this?
Try compiling Lua for your target architecture. Start with
something along the lines of etc/noparser.c + etc/min.c
(but kick out lauxlib). Check if you are getting anywhere
near your target size before you continue.
If yes, ask for more hints. If no, pick a different platform. :-)
The inspiration comes from the LeJOS
project which has managed to embed a Java VM in under 16KB.
One reason why it's hard to compare this to Lua is because of
the different approaches to VM design.
The Java VM is very low-level and refers to library code
for anything more complex (like strings or hash tables).
The VM instruction decoder and the garbage collection probably
need most of the code space. Anything else is done in bytecode
pulled in from libraries (and statically linked to form
a single image in LeJOS).
The Lua VM operates at a higher level. Some bytecode instructions
translate to hundreds of CPU cycles. Stuff like strings and
hash tables form an integral part of the Lua core. This makes
it larger than a minimal Java VM. But if you are going to use
all of that anyway, the tighter integration saves space and
enhances performance, too.
Of course if you don't need hash tables, metamethods, coroutines
and so on, it's hard/unfeasible to remove this from the Lua core.
So Lua might not be the best choice for a really tiny embedded
system (less than 64K of memory and only primitive I/O).
But Lua is still an excellent choice for embedded systems with
at least 128K-256K of memory (FLASH+RAM) and advanced I/O
(like networking).
BTW: Here is a break down of the code size of the different
functional parts of Lua. This was measured on x86 (compiled
with -Os and with lua_Number = double) and for Lua 5.1-work6:
Essential Lua core (total 33.7 K):
+ 6.8 K bytecode interpreter plus glue code
+ 4.4 K stacks, frames, states (coroutine)
+ 2.8 K functions, metamethods, misc. object support
+ 0.6 K shared immutable strings
+ 3.0 K hash tables
+ 4.1 K GC, memory management
+ 4.8 K C API glue
+ 4.5 K C debug API glue, bytecode verifier, opcode names
+ 2.7 K bytecode loader, bytestream support (zio)
Compiler (total 19.0 K):
+19.0 K lexer, parser, code generation, bytecode dumper
Lua core libraries (total 32.7 K):
+ 4.4 K lauxlib, linit
+ 5.4 K base library
+ 2.1 K math library
+ 3.7 K IO library
+ 2.2 K OS library
+ 6.7 K string library (including regex)
+ 1.9 K table library
+ 2.8 K package/module library (loadlib)
+ 3.5 K debug library
Standalone applications (pick one):
* 3.1 K command line interface (lua)
* 4.3 K command line compiler (luac)
Yes, you will get vastly different numbers when compiled
with -O2 or even -O3. Also you'll see larger numbers for
other 32 bit or 64 bit architectures (*) and smaller numbers
for 16 bit architectures.
(*) See: http://lua-users.org/lists/lua-l/2004-11/msg00093.html
Bye,
Mike
