On Wed, Mar 01, 2000 at 10:39:22AM +0100, Raymond Wiker wrote:
> I've gotten a bit further, again: I switched on the sb-show
> feature in target-features.lisp-expr, and that pinpointed a problem
> with os-cold-init-or-reinit, which is only defined for linux. I
> "fixed" this by conditionalising the call to os-cold-init-or-reinit
> with #!+linux - is this right?
In my opinion, the best way to handle most differences between systems
is to have a set of abstract functions (and constants) which are
called for every system. Putting in a bunch of #!+/#!- or #+/#- code
is usually second best. It's like the difference between using OO
method dispatch or using switch statements -- by breaking down
dependencies into abstract functions, you can usually make the code
In the existing code, this model is not followed very consistently, in
part because I didn't write most of the existing code. But I'd like to
see SBCL move toward this model.
So the answer is, I believe it would have been cleaner for you to add
a definition a la
;; On FreeBSD, this is just a no-op.
(defun os-cold-init-or-reinit ()
to the appropriate file (freebsd-os.lisp?) instead of wrapping
the OS-COLD-INIT-OR-REINIT call with #+LINUX. But you can do
even better than that, because..
In fact, CMU CL did follow the OO-ish model that I advocate in the
case of the OS-COLD-INIT-OR-REINIT function, it's just that they
called the function OS-INIT instead. I renamed a number of functions
to try to make it clear whether they're used at cold init only or in
reinit too or only in reinit. I realize that I was causing friction,
and I regret that, but I thought it was worthwhile to avoid the
confusion of having FOO-INIT be used both at cold init and at reinit
while BAR-INIT is used only at cold init.
(In fact there are many, many renamed symbols in SBCL relative to
CMU CL, e.g.
PRIMEP to POSITIVE-PRIMEP
MAKE-KEYWORD to MAKE-KEYWORD-FOR-ARG
DUMP-SHORT-FLOAT to DUMP-SHORT-OR-SINGLE-FLOAT
special variables FOO to *FOO*
DEFUN FIXNUM to DEFUN FIXNUMIZE
C::MAKE-SEGMENT to C::MAKE-DEFAULT-SEGMENT
often to more correctly describe the meaning of the thing named,
sometimes to reduce package problems, sometimes for other reasons. I
think most of the changes were worth the friction that they cause, but
the ones which affect porting could cause a *lot* of friction, so
maybe they're an exception..)
So anyway, my recommendation is that you try using the OS-INIT
function from CMU CL's freebsd-os.lisp as your implementation of
> At the moment I get as far as the first call to gc, which
> crashes because an object (the first?) has a type tag of 0xbe (190),
> which is unknown to gencgc.c (via sbcl.h). The highest type tag in use
> seems to be scavenger_hook, which is 0xba (186).
> Is it possible that the :freebsd feature enables an additional
> type that is somehow not picked up by the code in genesis.lisp?
> (Either because it's placed in a different package or because it
> breaks with the "protocol" for primitive types.) I'll check this,
It is possible that somewhere someone has hand-coded a use of a
particular type code which isn't cleanly propagated into sbcl.h, and
that it doesn't come out in the Linux build. (I've never seen a
problem like this.) However, I suspect it's more likely that you're
seeing some grosser problem (memory corruption or something).
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C