magic/lisp
R. Timothy Edwards 516c9d7635 First cut of pulling the TT_SIDE bit out of the tile database
and forcing it to be passed as an argument to all the callback
functions for the search routines that require it.  Magic now
compiles and runs with the new code, but there are a number of
known issues that need to be fixed up.  Committing now so that
I can rebase on the last update to the master branch.
2026-01-09 12:05:03 -05:00
..
scm
Makefile
README
lisp.h
lispA-Z.c
lispA-Z.h
lispArith.c
lispEval.c
lispFrame.c
lispGC.c
lispIO.c
lispInt.h
lispMagic.c First cut of pulling the TT_SIDE bit out of the tile database 2026-01-09 12:05:03 -05:00
lispMain.c
lispParse.c
lispPrint.c
lispString.c
lispTrace.c
lispargs.h

README

This is a mini-scheme interpreter, even though the files are all named
lisp*.{c,h}.

This interpreter is *extremely* slow. I can think of lots of ways to
improve its memory usage and performance (a factor of 5 improvement
seems easy), but it is very robust and it works. :) Besides, it turns
out that the bottleneck in most common tasks is magic itself, not the
interpreter.

The memory usage of this interpreter is ridiculously high. Collect garbage
often. :) Garbage collection is done automatically based on the
variable scm-gc-frequency at the top-level . . . i.e., when you see
magic's ">" prompt. To collect garbage at intermediate points in the
computation, you have to call "collect-garbage" explicitly.


-Rajit Manohar <rajit@csl.cornell.edu>
 Computer Systems Laboratory
 Cornell University
 Ithaca NY 14853
 http://www.csl.cornell.edu/~rajit/

$Header$