Re: lua and multithreading/pilot

[Dan Marks <dmarks@...>]

> >i486 under Linux for lua is 59,000 bytes, which
> >is not too hefty for a PalmPilot app, even
> >including libc and possibly libm.
> 
> if you don't use lmathlib, i think you can
> avoid libm.

I'll have to look into this.  The CPU of the Pilot
has no built floating point instructions, so they
must be emulated somehow.  Programmer's Calc uses
GNU libm, I'm not sure how RPN Calc does it.
RPN Calc is in particular very small, and I'm
not sure where the library routines for the numerics
fit in there.
 
> if you only run precompiled chunks, you can
> now have an interpreter that does not include the
> lexer or the parser. this would reduce the size of
> the interpreter quite a bit.
> to see how this is done, look at the end of the
> file lua/src/luac/stubs.c.

Is the code already separable so that one could
compile a lualib.a without the parser easily?
 
> but Lua does not depend on this.
> Lua only depends on having an ANSI compiler
> (that of course can generate ANSI semantics).

Doesn't lua use pointers interally?  Looking at
lobject.h (where I would guess most of the pointers
in the program would be associated with lua objects)
there are indeed plenty of pointers in stored
structures that would have to be traversed and
changed.  My hope was that the already present
garbage collection traversal method might allow
every pointer to be visited (because they have to
be checked for mark/sweep) and altered one by
one.

> you mean to say that there are no ANSI compilers
> for the PalmPilot?
> if this is the case, I'd say that porting Lua
> can be a lot of work.

There are ANSI compilers for the Pilot, but
I'm not sure exactly how malloc()/free()/realloc()
would work under a "handle" system like the Pilot
or Macintosh.  Because a program can arbitrarily
store pointers to data in the heap on the stack
or wherever, moving the memory around on the
program would be impossible.  This is why, for
example, garbage collection and compaction
is difficult under C and so-called conservative
garbage collectors are needed.  Of course, I
have little experience with the Mac and so I
don't know exactly how malloc()/free()/realloc()
works there....
 
BTW, the original reason I was interested in
such a port is that it seems to me that lua
could form the background to a pretty nice
calculator application.  Implementing objects
such as matrices, vectors, and possibly
algebraic expressions (which can be stored
themselves as lua bytecode) in lua, and
then storing their bytecode in the Pilot would
provide a powerful set of routines to use to
perform calculations.  Then one can
interactively enter expressions, or edit a
program in a Memo pad, the possibilities are
endless....

Dan Marks
dmarks@uiuc.edu