On Sun, Sep 30, 2001 at 09:16:52PM -0500, Nathan Froyd wrote:
> [non-sbcl source guru questions. approach with caution]
> In bignum.lisp there's many functions that follow the pattern:
> (defun %allocate-bignum (length)
> (declare (type bignum-index length))
> (%allocate-bignum length))
> (never mind weird ones like %FLOOR). Anyway, it seems as though this
> would get compiled as an infinite loop, but obviously that doesn't
> happen. I'm guessing that %ALLOCATE-BIGNUM is actually a routine that
> gets defined elsewhere and the compiler is smart enough to not compile
> it as a recursive call. Can somebody explain the magic (especially if
> it's a general principle behind SBCL) in something like this?
It's a definition of the out-of-line function in terms of the inline
expansion. It *is* sort of a general principle behind SBCL, and CMU CL
too: this same motif appears all over the place in the DEFUNs of
I thought I remembered seeing something about this on Dan Barlow's
SBCL internals CLiki,
but I can't remember where or quickly find it.
Forms, e.g. (FROB THING), can be defined in lots of ANSI standard
ways: macros and ordinary functions of course, and also inline
functions and compiler macros. Python, the CMU CL compiler now used in
SBCL, supports lots of internal ways of defining forms too. Off the
top of my head, DEFTRANSFORM and DEFINE-VOP are the really big ones,
but there are DEF-SOURCE-TRANSFORM and various others too.
The fundamental definition of SB!BIGNUM::%ALLOCATE-BIGNUM is in
(define-primitive-object (bignum :lowtag other-pointer-type
(digits :rest-p t :c-type #!-alpha "long" #!+alpha "u32"))
This tells the compiler how to expand it inline. The definition you
quote above is just to make sure that there's an out-of-line copy too, so
it defines the out-of-line function in terms of the inline expansion.
Probably no one would be twisted enough to do something like
(MAPCAR #'%ALLOCATE-BIGNUM MYLIST),
but out-of-line function definitions are useful for other things too,
like letting the late lamented byte interpreter compile macroexpansions
which include low level operations like this.
> Also, in the same file, at line 1174 or thereabouts, there's a comment
> and commented-out code that refers to numbers.lisp. This source file is
> nowhere to be found. Where has all that stuff moved to?
Probably most of what was in numbers.lisp at the time of the SBCL fork
is now in numbers.lisp. But..
* That looks like a pretty old comment (from before 1990, I'd guess) so
whatever it refers to might not have been in numbers.lisp at the time
of the split.
* Probably pretty soon it will be back in numbers.lisp. I've tried to be
consistent about naming things target-foo.lisp only when there's
also a corresponding foo.lisp or host-foo.lisp to be distinguished
from. Since these days there's no host-numbers.lisp or numbers.lisp,
I'll probably rename the current target-numbers.lisp to numbers.lisp
as part of the ongoing (though somewhat sidetracked due to the
ill-starred flaky5_branch) 0.pre7.x cleanup.
William Harold Newman <william.newman@...>
Where are we going and why am I in this handbasket?
-- Daniel Demus <demus@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C