PLATTS@Wharton-10 (12/17/82)
From: PLATTS at Wharton-10 (Steve Platt) ...I have been watching with some interest the current discussion of LISP on a micro-based system... in a relatively simple environment (no data types, just real, integer, string, atom, list builtin), what is a "reasonable" cellspace? I'm currently working on my third LISP, the closest to a *real* I intend to write. Previous attempt ran nicely, but was somewhat limited to around 10K cells in a 64K system (roughly)... by doing software paging and larger cells (5 bytes; 1 flag and 4 misc. data, like 2 addresses), a 64K cell system is possible, but this eats up over 300K of disk space. GC in this environment becomes a real-time coffee break if you aren't running memory-resident tdisks. Comments on writing lisp for a micro: it is trivial to fit it in <8k, at least a minimal core of almost everything. The minimal address space makes the stack, frames (for the debugger, etc), string spaces, and so on a bitch. The Z80 is a quite nice 16-bit processor. (As a joke, compare it with an LSI-11; you'd be surprised how nicely the Z80 comes out!) The main point of this: IN THE ENVIRONMENT IN WHICH A MICROCOMPUTER IS TYPICALLY USED, how large of a lisp space is desirable? Given the horsepower present in a micro (and this is important), what types of systems should we expect to run? Nobody solves 2000-piece finite element systems on micros; they just won't fit. This is no reason not to implement fortran on a micro; is there a similar analogy for LISP? More on this later, after I finish grading these $%#^& papers and the mass of finals I have yet to give... Oh Lauren etc.: did you ever find a nice public domain floating point package? I have every intention of doing IO through SYSLIB (with some possible low-level mods); any other libraries to ease the work would be welcome. --steve
mwm@Okc-Unix (12/17/82)
From: Mike Meyer <mwm@Okc-Unix> I don't see how you can get much more than 10K cells on a 64K micro. The technique I see a lot is to use 4-byte cells aligned on a 4-byte boundary. You then get to use the low order two bytes of pointers as flags re the things they point at. Given this, and assuming a 56K TPA, you get 12K cells on the system with an 8K LISP. On an 8086, on the other hand, you can use the aligned cells trick to get two bits per pointer, and use those to pick out a segment - cell space, FWS, or whatever, plus have a segment or two left over for stack & code. This gets closer to 16K cells, not counting FWS etc. The nicest way around this I know of is the TLC autoload feature. You can put AUTOLOAD on an atoms proplist, with values from KEEP/NOKEEP/SMASH/NOSMASH. This lets you play games with large systems by keeping the most of the code out on disk, and dragging it in when you need it. Of course, you garbage collect a lot, but over a small space. You mentioned that you had already built a couple of LISP systems, and were working on another. What is the availability of these? Can I get the old ones from somewhere? The new one? <mike