* there's no sane way to map LISP into modern hardware. Whether
we like it or not, the modern CPUs are really C language VMs
all the MMU business is there only to support a particular language
construct called pointers, yet let more than one process run
on a system. Sun has done some pretty cool things with trying
to build a hardware version of JavaVM and that thing had a
potential: no MMU, etc. but it got hit with a different evolutionary
artifact of the modern hardware -- the cache. Basically there
were no sane way to map the Garbage Collection into the hardware.
I don't know if this is a silly question but could you explain me
(privately if so you wish) what's is the big issue with that (GC
hardware mapping)?
* LISP makes it harder for nonLISP things to reuse system components.
Or at least it feels that way to me: suppose we end up with an ultra
efficient hardware implementation of a LISP system -- but can we build
a Java layer on top of it ? What about /bin/rc layer ? What about
awk layer ? How would these three talk to each other on such a system ?
What do you mean by 'layer'? Does a prolog interpreter written is Lisp
satisfies your definition?
I have somewhere in my bookmarks an emulator of the MIT CADR Lisp
Machine for x86 machines (for UN*X I guess).
Let me know if you want that link to answer some of your questions.
iru (muzgo)
