PLATTS@Wharton-10 (12/20/82)
From: PLATTS at Wharton-10 (Steve Platt) ..yes, the standard trick is to use 4-byte aligned cells and steal the low 2 bits for something else. GC claims one; and that doesn't leave alot of room for expansion. That is how the second LISP I wrote was designed (we won't even talk about the first!). The current design is much more complex; actual cell accessing will be very much slower in some cases; faster in others. I have abandoned the principle of the 4-byte cell. I am sacrificing memory space for speed. Adding a 5'th byte, used entirely for flags, allows a *very fast* calculation of ATOM, NUMBER, expr/fexpr/subr/fsubr/param form packing, undefined, etc. Basically, using a BIT n,M instead of comparing a series of 16-bit values This also limits real memory even more, so we are going virtual. The remaining 4 bytes are all data (32 bit values for numbers, or 2 16-bit pointers... for now, continue with the pointers). The 16 bit pointer is split into page/offset of 9/7 bits leaving a max of 512 pages at 128 cells per page. Nice numbers, as 128 is the CP/M sector size. 64K cells at 5 bytes/cell leave 300K of memory; as previously stated, this is on disk, grind, grind. I'd love a warp drive to get it tearing along, eliminate the paging problem. Expanding from this point is a pain. 16 bits is a practical maximum: if one goes to 24 bits per cell (16 meg cells), one finds that the paging tables for virt->phys translation become unmanagable, taking up all of memory and reducing the available physical pages to the point where all you'd do is spend your time paging. With a 64K cpm system, allowing 20K for LISP and tables, this leaves roughly 40K for cells, or around 50 pages in memory (10K cells). I'd envision 30K cells a practical maximum (otherwise, you'd allocate forever and spend the afternoon GC'ing). Also, a practical offline compacting GC becomes a necessity. As to my previous systems, I'd rather not release them. They were learning projects and are not really good. -steve