What is a ``reflective'' system?
Reginald S. Perry
perry@zso.dec.com
Sun, 11 May 1997 18:09:11 -0700
>"Jordan" == Jordan Henderson <jordan@Starbase.NeoSoft.COM> writes:
> I think that perhaps the goal of full reflectivity is not best. If
> we could define a LispVM separately, perhaps with several
> implementations (C, JIT, interpreted Lisp for prototyping) then the
> rest of the system could be fully reflective assembling/compiling to
> this. It would require that a LispVM backend be written for CMU-CL
> eventually. I can see objections already. We have people who want
> to use CMU-CL with native compilation for everything, without regard
> to whether this is a good idea or not. I think these people have
> "come in late from the picture show" and didn't hear that we were
> going to have a LispVM.
I am not going to talk about the VM, but I think that there is
something people are overlooking in order to find the holy grail of
portability.
Every operating system I have used so far has had some small amount of
assembler to talk directly to the hardware. It would therefore seem
logical to me to clearly define the set of assembly routines we would
need that would allow us to implement the rest of the system in some
lisp dialect with extentions. There seem to be too many low level
things that we really need that would best be addressed in assembly
language. If we keep it small, we should be OK. Maybe define a sort of
HAL.
I think that someone said this before. While stack machines simplify
some things, every one that I have seen so far has mapped badly onto
the hardware leading to a slow implementation. Since all of the major
places we are planning to implement are register machines, we should
avoid the stack machine route.
-Reggie
-------------------
Reginald S. Perry e-mail: perry@zso.dec.com
Digital Equipment Corporation
Performance Manager Group
http://www.UNIX.digital.com/unix/sysman/perf_mgr/pmweb/index.html
My opinions are barely my own. Clearly Digital wants nothing to do with them