From: William H. N. <wil...@ai...> - 2000-07-15 00:35:54
|
On Sat, Jul 15, 2000 at 01:10:58AM +0200, Martin J. Laubach wrote: > I'm thinking about trying to port sbcl to NetBSD, but of course > have absolutely no idea whether (a) this is at all possible (I had > a brief encounter with CMUCL 18a source, and it wasn't all that > pleasant :), (b) where to start. I prefer to have discussions like this on the sbc...@li... list, so that others can participate and so that they're archived in case someone else wonders about the same thing later. Therefore, I've posted this to that list as well as sending you a copy. I'd expect that a port of SBCL to NetBSD should be quite possible. I'm not familiar with NetBSD, but I'd been thinking of porting to OpenBSD, and my impression is that the difference between FreeBSD and NetBSD is comparable to the difference between FreeBSD and OpenBSD. (The system already runs on FreeBSD, thanks to the porting work of the CMU CL folks and Raymond Wiker's work in cleaning up the patches for SBCL and for the changes in FreeBSD 4.0.) SBCL has a low-level part which will probably need some rewriting in order to run in NetBSD. There are at least four things which are likely to need tweaking: (1) differences in handling of UNIX signals (2) differences in handling of memory protection issues (3) differences in memory map (4) differences in calling conventions of system routines (since CMU CL, alas, hand-copied information from system header files into files like unix.lisp, and SBCL still uses the same system). The first 3 issues are in code in the src/runtime/ directory. The last issue is in the src/code/unix.lisp file. If you want to avoid looking at too much of the system, you can look at all the source files which have the string 'bsd' in their names, and also grep for "-i 'bsd'" in all the system sources. That should identify most of the dependencies. Note that I consider the existence of point (4) above to reflect a design decision which is not appropriate for SBCL. It may at one time have been appropriate for CMU CL, since it does have the advantage of allowing reduced overhead when calling into the OS and C library. However I don't think it's worth it today -- probably not even for CMU CL, since they've been unable to maintain it very well, and almost certainly not for SBCL, since I think it's important to make SBCL particularly clean and maintainable. (It'll take a while yet.:-) Anyway, if I do the port to OpenBSD, I might do it by rewriting the unix.lisp stuff with an extra layer of C wrapper code so that information from system header files doesn't need to be copied by hand into Lisp code. (You don't need to do this if you do a NetBSD port, just be aware that I think it would be good to do it sometime.) -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2000-08-04 00:48:38
|
On Sat, Jul 15, 2000 at 01:10:58AM +0200, Martin J. Laubach wrote: > I'm thinking about trying to port sbcl to NetBSD, but of course > have absolutely no idea whether (a) this is at all possible (I had > a brief encounter with CMUCL 18a source, and it wasn't all that > pleasant :), (b) where to start. > > What do you think? (I replied to this before, but I have more information now.) I've now ported SBCL to OpenBSD on my laptop. It seems to work OK -- it does warm boot successfully (building PCL, etc.), it runs the regression tests on my 5000+ line Go-playing program, and as I write it seems to be well on its way to recompiling itself from scratch. (Recompiling itself is a rather slow process on a P133 laptop with 48 Mb of memory, especially under OpenBSD, which doesn't seem to deal all that gracefully with heavy swapping.) To support the port, I did a major rewrite of the signal code. It now uses POSIX SA_SIGACTION-style handlers on all three supported OSes (Linux, FreeBSD, and OpenBSD). POSIXness was needed for the port to OpenBSD (which needed to use information from POSIX-style siginfo), and POSIXifying everything seemed to make the code much nicer. Hopefully it will also help make it more straightforward to port to NetBSD. I'm about to leave town for a week and a half (hence the urgency of porting to my laptop), and I won't really be able to get started on a release version of this until I get back. Since the OpenBSD port has a number of hacks which need to be cleaned up (e.g. defining both :FREEBSD and :OPENBSD-NOT-FREEBSD as target features in order to specify OpenBSD), and since I've committed to putting some other features in the next release, I don't expect the next release to be out until late this month. But when it is out, it will probably be relatively straightforward to do the NetBSD port, by looking for places which do things in a *BSD way or in two different ways depending on FreeBSD and OpenBSD, and adding a third case. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Martin J. L. <mj...@em...> - 2000-07-16 22:29:54
|
| I prefer to have discussions like this on the sbc...@li... | list Fine with me! So, confronted with the quite large sbcl sources, where is a good starting point? Or perhaps what are critical components, if I can't get those to run on NetBSD, I might as well not bother any further? Sorry to sound a bit unsure, it's just a bit overwhelming sourcewise... mjl |
From: William H. N. <wil...@ai...> - 2000-07-17 16:37:53
|
On Mon, Jul 17, 2000 at 12:29:32AM +0200, Martin J. Laubach wrote: > So, confronted with the quite large sbcl sources, where is > a good starting point? Or perhaps what are critical components, > if I can't get those to run on NetBSD, I might as well not bother > any further? Unfortunately, I don't think there aren't any good subsets of the system to try running in isolation. What you should probably do first is look at all the BSD-specific stuff in the sources, and make sure you understand it and are prepared to translate it. (For me, if I do an OpenBSD port, I'll have to review UNIX signals and learn about the memory mapping calls, because I've never worked with that stuff.) After that, you should probably make a first draft of all the modifications you think will be needed to run on NetBSD. Most everything which is currently compiled only on FreeBSD, because of #+FREEBSD or #!+FREEBSD conditionalization or because of FreeBSD in its filename, needs to either be enabled for NetBSD, or modified for NetBSD. Thus e.g. #+FREEBSD (DEFUN FOO () (BAR)) might become either #+(OR FREEBSD NETBSD) (DEFUN FOO () (BAR)) or #+FREEBSD (DEFUN FOO () (BAR)) #+NETBSD (DEFUN FOO () (BLETCH)) After that, you can begin testing by starting to compile the thing. If you already have an ANSI CL compiler for NetBSD, you can use that as a cross-compilation host. Otherwise, you can use a CL compiler running on some other system as a cross-compilation host. If you have to run on some other system, read the make.sh file carefully and decide which steps have to be done on which system. (E.g. the cross-compiler needs to be built on the host system, then sbcl.h needs to be copied to the target NetBSD system, where the src/runtime/GNUmakefile needs to be run to create sbcl.nm, which will be copied back to the host system, etc..) Feel free to ask for help, and please point out (or submit patches for) things which you think are unnecessarily unclear. Presently you'll get to the point where the src/runtime/ stuff builds successfully, the cross-compiler runs successfully on the entire system, and GENESIS can be used to make the initial core file. At that point you'll have something which can actually run on the target system, and you can start testing and debugging it. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |