On Tue, Jul 11, 2000 at 03:14:59PM -0500, John Towler wrote:
> I looked at the sbcl materials and am interested. My primary machine
> is a sun4c. Offhand, is there any reason why I can't lift the
> relevant assembly stuff from the cmucl-18* src and try to build the
> system. (Are there hidden/x86 specific dependiencies which would lead
> to known problems?)
It would probably require some fiddling to get it to work. It
shouldn't require much inspiration -- I'd expect that with a running
copy of CMU CL for Sun and another for X86, and a running SBCL for
X86, it should be fairly straightforward to find some comparison which
shows you what the hangup is when something doesn't work in the SBCL
port to Sun. But I don't know whether it'd be 5 hours of work or 50.
The biggest gotcha that I'm aware of is that in the CMU CL codebase
that SBCL came from, there are two different garbage collectors with
slightly incompatible interfaces, GENGC, used for all the ports other
than X86, and GENCGC, used for the X86 port. (GENGC is a generational
garbage collector, GENCGC is a generational conservative garbage
collector.) SBCL uses GENCGC. The incompatibilities are scattered
throughout the code in a fairly disorganized way (e.g. various
#+GENCGC and #+GENGC in the original CMU CL source) and I haven't
tried to test the code on any non-X86 system, or even systematically
reviewed the dependencies, so it would be rather miraculous if the
SBCL code worked with GENGC without some testing and cleanup.
A few of these incompatibilies might be a little bit tricky. In
particular, I noticed at least one place where the CMU CL code
conditionalization depends on build order (something like (DEFUN FOO
..), followed by #+GENGC (DEFUN FOO ..) in a later file, where the
second definition is some incompatible definition which is intended to
overwrite the first definition. SBCL's build order is necessarily much
different from CMU CL's, since in SBCL everything has to be defined
before we use it. (CMU CL just uses the definition from the previous
build until a new definition is finished.) Thus, if there are any
other GENGC-only build order dependencies floating around, it's quite
likely that they'll have been broken by the build order rearrangements
that I did, and I won't've found them in my (X86 only) testing.
There are also some other places where I didn't completely understand
the code that I was rewriting, and I may have inadvertently messed
something up for the other ports. One place where this could easily
have happened is the byte ordering stuff in the dumper. (CMU CL's
dumper is written in terms of CMU CL's own low-level implementation;
SBCL's dumper is a major rewrite for portability, so that it can run
in any ANSI CL cross-compilation host, not just under itself.)
Also, there are a few places where I've changed the interface myself.
For example, the CMU CL way is for the (user-visible) function EXT:GC
to have different arguments depending on whether the system was built
with GENGC or GENCGC. I think that's broken, so I'd like GC to have
the same arguments no matter what. So some (small) tweak might be
needed to fit this to the old, unmodified GENGC code.
(I supposed it might also be possible to just use the GENCGC code on
the Sparc, but my impression is that GENGC is better as long as you
have enough registers that partitioning them between tagged and
untagged data isn't too painful.)
> I am not yet a subscriber, and I haven't yet
> tried this, a private mail response would be most helpful at this
> point.
I'd really like discussions like this to make it into the mailing list
archives, for the convenience of other people with similar questions,
so I've done this through the mailing list and cc'ed you explicitly.
--
William Harold Newman <william.newman@...>
software consultant
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C
|