On Wed, Feb 21, 2001 at 10:48:28PM +0100, Arthur Lemmens wrote:
> I've started trying to port SBCL to Windows.
> I'm using the 0.6.19 sources, with Lispworks as the host compiler.
What fun! not only a new target OS, but a few extra idiosyncrasies
from a new cross-compilation host Lisp..
I don't have a Windows machine to test with right now, but no later
than this summer I should have a new laptop, with a shiny new multi-Gb
drive so that it should be pretty painless to leave a few Gb for
Windows when I install OpenBSD or Linux. The only reason I'm delaying
is that that way Moore's Law should give me a few more CPU at the
Computer Go contest at the AGA Congress,
If you can make a Windows port which is worth merging, I'll stop
procrastinating and get the laptop right away, so that I can work on
merging the port and testing the merged result.
(I hope you'll use, or at least support, a free C compiler for the
src/runtime/ stuff, so that I can build the system without spending a
significant fraction of the cost of my new laptop for Windows-only
> Here's what I've done so far:
> - rewrote make.sh, make-config.sh and make-host-1.sh in Lisp,
> skipping the part where the "target"-named symlinks are created.
> Windows doesn't know what a symlink is anyway.
> - setup a few logical-pathname-translations, and replaced the Unix-
> specific pathname namestrings with logical-pathname namestrings
> (mostly in the files in src/cold, but also in src/misc.lisp, and
> of course in stems-and-flags.lisp-expr)
> - replaced pathnames of the form "..;target;.." by "..;x86;..".
> That should take care of the missing symlinks.
> - defined an address space in compiler;x86;parms.lisp
> - tried to get Lispworks to load and compile everything, starting
> from make-host-1.lisp. With a bit of cheating, Lispworks is willing
> to compile up to the file "compiler;info-functions.lisp".
I'm not sure how I feel about turning make.sh into Lisp. It doesn't
seem like a particularly good idea in Unix. I have a little experience
with Windows, but not enough to have a strong opinion whether it's a
good idea there. If the Windows port becomes stable enough to be
merged into the main distribution, I guess I'll have some thinking to
do on this.
The pathnames stuff sounds reasonable. If the Windows port becomes
stable enough to be merged into the main distribution, the symlinks
and physical pathnames should probably go away completely. I can't say
I look forward to that, but in principle it seems to be the right
> And here are a few things I'm wondering about:
> - The type SAP-INT-TYPE is used in cross-sap.lisp and target-sap.lisp.
> But it's defined in compiler;x86;vm.lisp, which is too late
> (according to the order defined in stems-and-flags.lisp-expr).
> Lispworks complains about this, and I think it's right. So I just
> copied the type definition from vm.lisp to cross-sap.lisp. But I
> wonder how this could have worked using another host compiler.
> Or is this a leftover of those famous bootstrapping cross
> dependencies I keep reading about?
> Would there be a better solution than my stupid copy&paste hack?
This works when cross-compiling under SBCL (or CMU CL) because of late
binding, not AFAIK because of any weird cross-dependency. SBCL does
complain about the type not being defined at the time the function is
compiled, issuing warnings at build-the-cross-compiler time. But as
long as the types are defined by the time the functions are executed,
everything works. It's probably inefficient, though, since it probably
compiles into a full call to TYPEP at runtime.
When you say that Lispworks complains, do you mean that it issues
warnings or that it fails?
It should be possible to rearrange things so that the type
declarations appear before cross-sap.lisp and target-sap.lisp. As far
as I can see there's not much point in worrying about cross-sap.lisp,
since a slight efficiency hit at cross-compilation time is no big
deal. But target-sap.lisp stuff ought not be compiled unnecessarily
inefficiently. I'll make a note to look at this. (It's probably easy,
but it goes in the queue sometime behind MNA's big PCL patch and,
probably, the release of 0.6.11, so it might wait a week or more.)
> - I seem to be having the same kind of problem when compiling
> compiler;info-functions.lisp. It needs some definitions from
> class.lisp, which seems to need stuff from globaldb.lisp, which
> seems to need stuff from info-functions.lisp.
> Is that correct? Do you have suggestions for solving this?
What kind of definitions? Type definitions or other definitions?
And what kind of problem? Warnings or failures?
I spent a long time, a long time ago, untangling the order of things
enough to let the system build itself without ever trying to use
something which wasn't defined yet. I left many places where it
compiles a forward reference to something which isn't defined yet, and
at least some of those should be untangled, since such forward
references can be much less efficient than the optimized/inlined
version. But as far as I know everything should work, even if not
always as efficiently as possible.
> - The file Ugliness says that one of the assumptions about the
> cross-compilation host Common Lisp is:
> SINGLE-FLOAT is distinct from DOUBLE-FLOAT.
> I believe that, in Lispworks, SINGLE-FLOAT and DOUBLE-FLOAT are
> not distinct. Could you give me an indication where this would
> bite me, and what I could do about it?
It might bite you in constant folding in the cross-compiler. If so, it
might be fixable by suppressing constant folding at cross-compilation
It will probably be a problem when dealing with DEFCONSTANTs of
floating point values in the ordinary style like this,
(defconstant pi 3.14159265358979323846264338327950288419716939937511L0)
but I notice that most of them seem to be in another style,
(defconstant least-positive-double-float (double-from-bits 0 0 1))
and that style should be OK as long as DOUBLE-FROM-BITS isn't
constant-folded. So if necessary, you can probably hack things
like DEFCONSTANT PI into this form as well and make stuff work.
A similar problem would arise if there are any other places where the
cross-compiler wants to dump DOUBLE-FLOAT values. I can't think of any
offhand, but it might happen that the cross-compiler generates a
DOUBLE-FLOAT value and dumps it, expecting the distinction between
DOUBLE-FLOAT and SINGLE-FLOAT to be preserved in the cross-compiler
and appear in the target.
It might in principle be a problem in optimization of DOUBLE-FLOAT
expressions at cross-compile time, since the compiler tries to do
clever things like trying to infer the type of the results of some
functions from the types of their arguments. However, in practice I
doubt that's a problem, since I can't think of any place in the build
process where the cross-compiler processes expressions subject to that
kind of optimization, and the cross-compiler doesn't need to be
correct for all possible Common Lisp input, only for the subset of
Common Lisp which is actually used to define SBCL itself.
Those are all the gotchas that I can think of, but without testing it,
it's hard to be sure that there aren't any more. If you're worried
about it, you could probably test it (without mixing up too many
Windows interface issues) by using Lispworks as a cross-compilation
host for a Unix version of SBCL, and make sure that that works.
William Harold Newman <william.newman@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C