[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: hppa port of cmucl
Date: Fri, 03 May 91 15:04:55 EDT
We haven't made a decision about switching to CMU CL yet, but we've
decided to redirect my efforts from Python/gcc to doing an hppa port
of Python. We're going to borrow a sparc this summer on which we can
boot Mach and run CMU CL for real; however, if I think I'm ready to
start generating code long before then, I may get python running in
ucl and cross-bootstrap.
Sounds reasonable. Really, from my perspective, CMU CL is Python +
Debugger + Hemlock + Common Lisp + GC. If you don't want CL and you don't
want Hemlock, and you are using Python, then it is really mainly a question
of which debugger, object format and GC you are going to use. Of course,
you would need some CL support in your compiler Lisp to get Python to run.
If we use Python, I think we assume that the compilation evironment
will be full Common Lisp with some syntactic support for compiling and
debugging Concurrent Scheme programs. So, from our perspective, we are
interested in your CMU CL minus Hemlock. Concurrent Scheme's runtime
might be some subset of CMU CL, or completely different, but we don't
think that's very important.
By "cross-bootstrap" I meant generating a CMU CL + Python image with a
compiler and Genesis running in ucl. I don't know how practical that
is; anyway, I hope we get a Sparc before I'm tempted to do that.
On the RT, we use a pseudo instruction. See
rt_mach/alpha/compiler/rt/insts.lisp. We don't do any "optimal" branch
shortening. It is pretty worthless on modern architectures, as the
second-order effects are negligible unless your short branches are very
short (< 128 bytes).
It turned out to be fairly worthwhile on the 68k, because most
branches are 128 bytes are less.
Do you have a minimal list of vops needed for a port?
However, pretty much every VOP is in some sense necessary to compile our
OK. I thought you once said that some VOP's really were optional.