On Sat, 2006-06-10 at 01:37 -0300, Iruatã Souza (muzgo) wrote:
> > * 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)?
Its not a silly question at all. There's much more to it than I was
able to cram into the above passage. For more details see this:
http://research.sun.com/techrep/2005/abstract-143.html
A very different approach for trying to treat memory as part of general
purpose virtual machine and make it do more than load/store has been
tried by Elbrus-3 (a second generation USSR super computer). And that
beast was the most fun to write compilers for. That is, until Itanium
came about. ;-)
>
> > * 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'?
Reading a bit further in this thread you can find an excellent summary
of what I meant by 'layer' and 'talk' in a posting from Roger.
> 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.
See, that's exactly the problem -- it *is* and emulator (and to my
knowledge there's no other way for LISP) and, as Roger quite elegantly
put it: "Lisp provides a very expressive framework, but it's too rich.
its very richness is an obstacle to the problem that 9p
solves - the component-level connection of software components."
Thanks,
Roman.
Thanks,
Roman.
