CMUCL on Win32
Tuesday, July 6, 2004
Luke Gorrie mentioned to me on #lisp that, a couple of weeks ago, Carl Shapiro had announced on the CMUCL developers list that he has been working on a port of CMUCL to Win32:
"For the past several weeks I have been working on a port of CMUCL to the Win32-family of operating systems. I have progressed to the point where CMUCL starts up and is able to perform simple interactive tasks. In the interest of advancing the port I have begun to a state where it is ready to be integrated into the CMUCL source repository, I would like to make an appeal to all Win32-savvy Lisp hackers to join me in my effort. More specifically, I would like to find developers who use and are familiar with the Microsoft Visual Studio compiler and debugger, are running a current--NT 5.1 or better--release of Windows, and have knowledge of Win32 systems-level programming.I exchanged a couple of emails with Carl and he provided some more detail about the project (which he agreed to my posting):
Every project needs lofty goals. Mine is to make CMUCL the best platform to develop and *deliver* Lisp applications on Windows. (I certainly hope that the UNIX ports can benefit along the way!)
If you are interested in joining me, please contact me privately be e-mail. I would like to begin sharing my work, at the latest, by this time next week."
"So far I have a mostly-working runtime and a fully working compiler, garbage collector, foreign-functions, etc.. A colleague of mine is working on various Lisp-level enhancements, most notably a Win32 file system interface which is cognizant of both DOS- and UNC-type paths. Alas, the non-working parts of the runtime include tracts of the exception handling facility and a few corner cases in the memory-management interface. Furthermore, many Windows 'creature comforts' have yet to be added to the runtime such as 'stdcall' and 'thiscall' calling convention support in the CMUCL FLI. Eventually, I hope to have my enhancements made suitable for inclusion in the CVS repository but I have no idea when this will happen. Interestingly enough, I was contacted by somebody at {NAME-DELETED} who claims they have a completed port and permission to release it to the community. I tried to contact the individual responsible for this work but as yet he has not replied to me.If Carl does get a CMUCL port running on Win32 (or the other port that he mentions is made available), it will be quite a coup. Since CLISP is the only major non-commercial, cross-platform CL that is currently supported on Win32, a CMUCL port that performs well will provide an interesting addition to the CL options available on the Windows platform!
FYI, many architectural changes will have to be made to CMUCL to support the Windows operating system as Corman Common Lisp and LispWorks do. Most notably, CMUCL images are not relocatable and the runtime makes poor assumptions when allocating memory. If you know anybody who doesn't mind stepping through assembler code in the Visual Studio debugger and wants to hack on the internals of a Lisp system, I would be happy to have their help.
On performance, CMUCL for Win32 should perform identically to CMUCL for FreeBSD as that is where I started deriving my work from. I know that's not the kind of information you would like to have, but it's all I can offer you at the moment! Although I am happy to compromise; if you have some benchmarks, I can run them for you. Unfortunately, while it is possible for me to produce a distribution of sorts, the runtime has so many deliberately open deathtraps that you probably wouldn't get very far running it. (I am doing some hairy stuff in the runtime right now, and I have not been keeping the sources in as complete a working state as would be required to send people working snapshots in order for them to return useful feedback. I hope to get around to that shortly.)
Visual Studio 6.0 may not be too terribly useful for doing CMUCL work right now. It doesn't understand the new symbol file format which is retrieved by the Microsoft Symbol Server (a truly wonderful service) so you will not get accurate back traces if you get stuck in an interrupt handler. You will need VS 7.0 or 7.1 to read those files. I am using 7.1, but I have not introduced any dependencies to the version 7 C runtime. In fact, I am working towards eliminating dependencies on the C runtime to get better control over the placement of the process default heap and shared libraries."
