SBCL on Win32
Thursday, July 8, 2004
I mentioned the other day that Carl Shapiro is working on a port of CMUCL to Win32. Well, as it turns out, there is a port of SBCL underway as well! Alastair Bridgewater announced progress on his port of SBCL to Win32 on sbcl-devel late last week:
"At http://www.dridus.com/~nyef/sbcl-0.8.9-win32-changes.tgz is a tarball containing diffs and new files between released 0.8.9 and my current working directory for win32. I haven't touched it in about two weeks, so I figured it was time to let someone else take a shot at it if they wanted.I exchanged emails with Alastair, asking him for some more detail on his progress, main outstanding problem areas and whether he foresaw any future collaboration with Carl Shapiro and the CMUCL port. Here's his reply:
Thus far, all compilation has been done using a mingw cross- compiler (gcc 3.3.1) on a Linux box and sbcl 0.8.5. You may need to modify the Config file for the runtime to suit the compiler you end up using.
Some of the (new) functions in wrap.c may be set up to print far more information than is necessary. write(), for example, could probably be unwrapped without too much trouble.
For some reason, the Win32 console likes to return a bad file descriptor error when writing to stdout or stderr. No doubt there is a good reason for this. Using cygwin rxvt or cygwin emacs around a bash shell will prevent this from happening.
There is still some sort of data corruption going on. During the final purify for the save-lisp-and-die in make-target-2 the control structures for malloc()/free() get corrupted. If you call (sb!impl::messagebox 0 'Foo' 'Bar' 0) from the repl, you get a crash somewhere in user32; but if you call (dotimes (i 2) (sb!impl::messagebox 0 'Foo' 'Bar' 0)), it works.
Oh yeah, and the wrapper for open() has a nasty hack in it. If it is passed an absolute path, it strips off the first #/, so as to turn it into a relative path (mostly so that the src directory didn't have to be C:src for warm init)."
"The basic system appears to be working, getting through warm init. Serve-event isn't working, the filesystem stuff has been badly hacked, there's some downright weird memory corruption going on (so far only noticed in the Win32 heap tracking structures and in user32.dll), none of the contribs have even been tested, and there's that strangeness with the bad file descriptor for stdout on the normal win32 console. You can see some of the details in my initial message on this subject.I tried out Alastair's port on my PC. It felt very snappy and I was able to run many small snippets of CL code; however, there is obviously quite a bit of work still to do. It was promising, though, to see how far Alastair has progressed. I look forward to following the progress of both the SBCL and the CMUCL Win32 ports.
I hacked in some primitive compiler stuff for stdcall, but I don't know how good it really is, and I didn't add any of the wrapper macros for generating ALIEN functions for it yet either. It's possible to use it without the wrappers, it's just more difficult (and can only link to functions referenced from the runtime, since I didn't fix up GetProcAddress() yet).
No, I haven't tried doing a native compile. Compiling C code on a windows box is fundamentally uninteresting, and I don't have a host SBCL system for windows either.
> Edi brought up a good point - cmucl and sbcl already
> do a lot of sharing of bug fixes and enhancements, are
> you and Carl Shapiro planning to do any collaborating
> on the Win32 support for cmucl/sbcl?
Not so far as I know. I'm presently unaware of us having so much as traded emails. We might well be able to trade parts of the system written in Lisp, but the runtime is probably a lost cause (the runtime is substantially different in the base systems, and we're using different strategies for porting it)."
