The lisp system I work on, SBCL, sometimes shows its age. Although SBCL per se has only been around for five years or so, it is an evolution from CMUCL, itself an offshoot from Spice Lisp, which was started in the early 1980s, borrowing from the heritage of 1970s lisps.
Given this history, it's not entirely surprising that the codebase (200kloc of lisp, plus about 10kloc of C and assembler) isn't 64-bit aware. However, today's applications are definitely nudging the space requirements; Lisp is apparently "big in bioinformatics", and fairly obviously there they'll want to be dealing with large databases.
So, a couple of months ago, Dan and I had a quick hack at porting our existing alpha backend (which was originally crafted as a 32-bit application) to be fully 64-bit. We got far enough to be executing plenty of lisp code, but not quite up to the point that the REPL was functional.
Time passed. Various bugs in the alpha backend were fixed, and so (why not?) I tried again yesterday, merging the previous branch with CVS HEAD. After conflict resolution, the addition of the necessary specialized array types, and three or more bugfixes (plus commenting out of things that break weirdly):
/about to set up restarts in TOPLEVEL-REPL
* (* 2 3)
Waitaminute! That doesn't look nicely big enough for a 64-bit lisp. Well, not quite everything is working, despite getting to the REPL; here, the printing routines are slightly broken. The most positive fixnum is meant to be (1- (ash 1 60)) (leaving four bits for tagging objects); that number is 1152921504606846975. So, compare and contrast
Other things that appear not to work include the compiler itself; clearly, the utility of a compiler-only implementation of 64-bit lisp without a functioning compiler might be viewed as "limited". Since I'm technically unemployed at this point, I'm taking offers of funding...
Thesis minus 8 days.