From pmai@acm.org Fri Feb 23 00:12:04 2001 Received: from knight.cons.org (knight.cons.org [194.233.237.86]) by mailhub.mclink.it (8.11.0/8.9.0) with ESMTP id f1MNNms14685 for ; Fri, 23 Feb 2001 00:23:48 +0100 (CET) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by knight.cons.org (8.11.1/8.11.1) with ESMTP id f1MNCHx08300 for ; Fri, 23 Feb 2001 00:12:17 +0100 (CET) Received: from fwd02.sul.t-online.com by mailout06.sul.t-online.com with smtp id 14W4uG-0007AU-02; Fri, 23 Feb 2001 00:12:16 +0100 Received: from dent.bln.pmsf.de (320001904523-0001@[217.80.21.184]) by fmrl02.sul.t-online.com with esmtp id 14W4u5-0XVlXkC; Fri, 23 Feb 2001 00:12:05 +0100 Received: from orion.bln.pmsf.de (dent@orion.bln.pmsf.de [192.168.42.10]) by dent.bln.pmsf.de (8.9.3/8.9.3/Debian 8.9.3-21) with SMTP id AAA03219 for ; Fri, 23 Feb 2001 00:12:05 +0100 Received: by orion.bln.pmsf.de (sSMTP sendmail emulation); Fri, 23 Feb 2001 00:12:04 +0100 Sender: dent@pmsf.de To: cmucl-help@cons.org Subject: Re: Bootstrapping References: <3A8C1A33.5AF4E009@home.com> <4nvgqbx192.fsf@rtp.ericsson.se> <3A927158.3AF4B001@home.com> <4nu25p326f.fsf@rtp.ericsson.se> <3A95931F.C4ADB9C@home.com> Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII From: "Pierre R. Mai" Date: 23 Feb 2001 00:12:04 +0100 In-Reply-To: "David A. Cobb"'s message of "Thu, 22 Feb 2001 17:30:55 -0500" Message-ID: <87k86imhx7.fsf@orion.bln.pmsf.de> Lines: 75 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Capitol Reef" X-Sender: 320001904523-0001@t-dialin.net "David A. Cobb" writes: > > I think a windows version of CMUCL is the most requested port. > > Unfortunately, I don't think any here has the knowledge or desire to > > do it. Having an x86 version already helps a lot in getting there, > > but I think it's still a lot of work. > > So, again, being slightly brain-dead; I don't understand how there > can be any port if the system cannot be bootstrapped. You have some > amount of 'C' code? Another language? Some Assembler? Would it > include the basic dumb lisp reader? You go about it the same way you'd bring up any compiler for language X which is itself written (mostly/wholly) in X: By cross-compiling from a supported platform. That's the same way that e.g. the first C compiler for most platforms (be it MS-DOS, Windows NT, Linux, what have you) has been brought up. In the specific case of CMU CL and Win32 on x86, the following things should be needed (rough outline, the specifics are somewhat complex, and should be enquired from someone who has actually done some cross-platform work with CMU CL. There is currently a port to LinuxPPC being undertaken by Eric Marsden, the fall-out of which you can watch on cmucl-imp ;): - Port the low-level C code of CMU CL (in the lisp directory) to Win32, and compile it using your favourite C compiler. - In the process of this, some information on the layout of the C code is generated, which you copy to your Linux or FreeBSD system. - Configure your CMU CL to cross-compile to a Win32/x86 target (if you are lucky, you might not even have to change the backend. Otherwise you might have to tweak it somewhat to conform to match your changes to the C code), and compile all the lisp files, and build a kernel.core. - Copy the resulting kernel.core (and all the other *.x86f files) to your Win32 machine, and you're ready to start your first lisp world using the lisp binary and your kernel.core. - Load the rest of the stuff as usual, and dump out a normal lisp.core You're done now, enjoy. Of course in reality, you'll iterate several times at each stage (and across all stages), working out all the stuff you failed to correctly change, the invariants you failed to keep, the bugs you introduced, etc. But in theory it is simple ;) > How, in theory, would one go about a port - specifically to Cygwin? As far as I'm aware, porting to Cygwin seems to be the wrong way to go about it: Since Cygwin's Unix emulation is not sufficient to really support CMU CL (problems with missing context information in signal handlers, etc. IIRC), you'll have to deal with Win32 API anyhow. And in that case it might be better to go the whole hog, rather than do it piecemeal, so you don't have to worry about three sets of semantics (Win32, Cygwin, and the one CMU CL expects). There are other POSIX/Unix Toolkits for Win32 (U/WIN? ...) which might be sufficient to support CMU CL, though it seems unlikely, since CMU CL is not the typical application that is ported using such toolkits. A native Win32 port is probably the best way to go. Regs, Pierre. -- Pierre R. Mai http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein