Installation Notes

NOTE: the installation procedure has changed slightly. Configuration information is handled in a very different way. Read on.


The default installation

Usually you just have to set the environment variabe "SATHER_HOME" to the base directory of the Sather package and then run "make". For the optional part you need to have Tk/Tcl and some kind of socket support installed. File System/Common/CONFIG.proto has default settings for many variables used during the installation (the name of a make utility, C compiler, etc). These may need to be modified if, for instance, you would like to use a parallel make utility or a proprietary C compiler.


Things you need to install the compiler


More detailed installation instructions

These are the recommended step to install the Sather compilers. Your system may have particular requirements; if I know these, they are listed later in this file. The default make rule then goes on to make the optional packages, the Browser, Gui and Graphical debugging.


Optional: Browser, Gui and Graphical Debugging

After completing the standard "make", the Makefile will go on to try and install some optional library, browsing and debugging aids (the -debug_graphical compiler option). The corresponding rule in the Makefile is "optional". For all of these you should have Tk4.0 and Tcl7.4 installed, and sockets available. Here are some useful sites for Tcl and Tk: Some notes on problems with Tk4.1 or Tcl7.5 are in tcl_tk_notes.html.


Problems you might encounter

Sometimes there are simple namespace conflicts. These can be permanently eliminated by having me add the offending identifier to System/FORBID, and in the meantime add it yourself and do a textual search-and-replace in the boot code to change it to something else.

If you have to modify the garbage collector, please send the changes to the author, Hans Boehm (boehm@parc.xerox.com), so he can include them in his next release. If one wants to encapsulate existing c++ classes for use with Sather, one would wish to have access to the c++ extensions in the GC library. This can be accomplished by changing "make" to "make c++" in the rule for "System/GC/gc.a". This does not hinder using straight Sather or Sather with external C code while enabling the use of the garbage collector with GC compliant c++ classes.

Beware the jabberwock: if you didn't have CPP set properly on your first make, be sure to delete any bogus empty System/CONFIG file that got created by the redirect. Otherwise make may not know to generate the good versions.

Be sure to let us know what you had to add to get things running so we can include them in the next release. Whether it works or not, let us know by sending mail to "sather-bugs@icsi.berkeley.edu". Good luck!

- Boris


Known changes necessary to compile on ported systems

Systems on which it runs without changes (there probably are many others):
    SunOS 4.1.3, gcc 2.5.8, gcc 2.6.0 gcc 2.7.2
    SunOS 5.4, gcc 2.5.8, gcc 2.6.0, gcc 2.7.2
    SunOS 5.5 gcc 2.7.2
    Ultrix 4.3
    Linux 1.0.8, gcc 2.5.8 and 1.1.x, libc4.6.x, gcc 2.6.0
	  1.3.35, gcc 2.7.0, i486-*-linuxaout
    HPUX 8.07, 9.05, using gcc 2.5.8

Ultrix 4.4, DEC cc 3.0 (C. R. Thewalt ):
    GC changes needed.
    In Makefile, CC= cc -std1 -G0 -w
    In System/CONFIG.proto, for debugging use "-g3"

IRIX:
    IRIX 6.2
        Goetz Isenmann  reports:
	The problem is the garbage collector (gc4.10). You can see this, 
	when you try a 'make test' in the GC directory.

	I asked Hans Boehm, the author of gc, and he suggested to use
	http://reality.sgi.com/employees/boehm_mti/gc_source/gc4.11alpha3.tar.gz

	With this gc version I was able to compile cs with the old compiler 
	model (cc -32 -woff 651,596,728), and compile the tests with cs.

    Christian A. Ratliff  reports that the
    GC will not build on SGI IRIX with GNU 'gas'; you need to use SGI 'as'.
    hinsenk@cyclone.ERE.UMontreal.CA (Hinsen Konrad) reported 4.0.5 needed:
	 make SHELL=/bin/ksh
	C_FLAGS= -G 0
	RANLIB=ar ts
    bolstad@vislab.epa.gov, says for 5.2 and 5.3:
	if your default shell is csh, then add SHELL=/bin/sh
	when using the native compiler:
	    CC= cc -woff 651
	    RANLIB= echo    # SGI does ship with ranlib
	also use pmake and not smake.
	Also reports native compiler under 5.2 or 5.3 can't handle
	1.0.6, but gcc works fine.
    However, isenmann@physik.tu-cottbus.de says for 5.3:
	CC= cc -woff 568,651
    rogoff@flamingo.Stanford.EDU needed for 5.3:
	SHELL = /bin/sh
    Mark Bolstad (bolstad@vislab.epa.gov) reported: function lgamma is 
	broken on the SGI running 5.3. 
		"I finally got SGI to come up with a solution to fix the 
	lgamma problem for IRIX 5.3 (it will be fixed in 6.2). The solution 
	involves a special flag to pass to the C compiler. The problem is, 
	defining the flag causes the GC code to have errors. So, here is my 
	Makefile on the SGI running 5.3:

	... Standard preamble ....	

	SHELL=/bin/sh       # Required if default shell is not Bourne Shell
	CPP= /lib/cpp -C -P
	CC= cc -woff 651,709 -D_XOPEN_SOURCE
	            # the -D... makes lgamma work on the SGI
	            # the 'woff's stop the C compiler from complaining about
		    # "incompatible pointer.." warnings and others
	CFLAGS= -O
	GC_CC= cc -woff 651,709 # -D_XOPEN_SOURCE breaks the GC code, so make sure its
	                        # not defined
	GC_MKFL= Makefile

	# You may set this to something faster than make, such as "pmake".
	#PARALLEL_MAKE= pmake -J 15 -L -4
	PARALLEL_MAKE= pmake  # smake doesn't work for this code
	... Other Stuff ...

SCO Unix 3.2.4, gcc 2.5.8: (Michael Arnoldus )
    CFLAGS = -O -DSCO
    In System/GC/Makefile:
	CC= gcc
	CFLAGS= -O -DALL_INTERIOR_POINTERS -DSILENT -DSCO
	SPECIALCFLAGS = -DSCO
    You'll need to get the GC mods too.
 
SunOS 5.3, cc:
    CPP = /usr/ccs/lib/cpp -C -P
    RANLIB = ar st
    CC = cc
    CFLAGS = -O -Xa -xcg92
SunOS 5.4
    Works for me (davids@icsi.berkeley.edu) vanilla.
    You may also try:
	CPP= gcc -traditional-cpp -x c -E -C -P
	RANLIB= ar st
    For the SunPRO C compiler, you'll need "-lsunmath" 

    Pentium, gcc 2.7.2
	"I had to redefine CPP to use gcc, and had to define SUNOS5
	so that the test would use pow() instead of exp10().
	Defining SUNOS5 resulted in numerous "redefining" messages
	during the GC compile, but at least the tests worked.
	Note that "gcc -E" will ignore files without ".c" suffixes,
	so I had to copy CONFIG.proto."

	edit Makefile
	old:
	CPP= /lib/cpp -C -P
	...
	$(CPP) ... System/CONFIG.proto > System/CONFIG

	   CPP= gcc -E -C -P -DSUNOS
	CC= gcc -DSUNOS5
	...
	cp System/CONFIG.proto System/tempa.c
	$(CPP) ... System/tempa.c > System/CONFIG

	Steve Sullivan    sullivan@mathcom.com

Alpha, DEC OSF/1 V2.0, V3.2, gcc 2.5.8:
    In top Makefile: Use 
	CPP= /usr/ucb/cpp -C -P -DALPHA
	CC= gcc -DALPHA
	GC_CC= cc (for some reason it breaks with gcc)

    On an alpha Sather INT is "int" instead of "long".  This seems to
    work under gcc, but not "cc -std -taso" which would be slightly
    safer.  I'd like to hear from somebody who can get 64 bits working.

    Under OSF/1 V3.0, stay away from the gcc 2.6.0 compiler; 2.5.8
    works.  (Frank Horowitz )

Linux 1.3.35, gcc 2.7.0, i486-*-linuxelf
    "I did have to make one minor change in the garbage collector source 
    (remove the leading underscore from _GC_push in machdep.c).(Note that 
    this change is specific to i486-*-linuxelf and does not include 
    i486-*-linuxaout which compiles without changes on the same version of 
    all involved compilation utils.)"
					Thomas Marsh, amadeus@bga.com

NetBSD 1.0:
	CPP= /usr/bin/cpp

NetBSD 1.2_BETA:
    In Makefile use:
        CPP= /usr/bin/cpp -C -P
	CFLAGS= -O2 -fno-strength-reduce
        
NetBSD/i386 1.0a: Alistair G. Crooks (agc@uts.amdahl.com)
	CPP=/usr/bin/cpp -C -P

FreeBSD 1.1.5.1, FreeBSD 2:
    In Makefile, use "CPP= cpp -C -P"
    mal@algonet.se (was d87-mal@nada.kth.se) found floating
    point exception handling that stopped the test program; just
    delete the floating point tests.

NeXTStep 3.2, 3.3:
    CC= cc -traditional-cpp
    Colin Perkins :  This runs the GNU cpp, rather
    than NeXT's extended version.

    There might be some minor floating point result differences in the
    tests.  This is caused by a bug in NeXT's printf, which doesn't do
    "%g" correctly.

OS/2, emx 0.8h, gcc 2.5.7:
    Install other additional utilities: GNU make, GNU fileutils,
      bash (any sh-compliant shell), cmp (not essential)

    Modify the top-level Makefile:
      CPP= /emx/bin/cpp -C -P
      RANLIB= ar s
      CS= cs.exe
      TEST= test.exe
      GC_MKFL= EMX_Makefile
      Escape `"' quotes in CONFIG_* vars with a backslash `\'.

    Run command "set COMSPEC=bash.exe". Continue installation normally.
    Questions to Ari Juhani Huttunen .

HP-UX 9.03 using HP's cc 9.61:
    Use cc flags -Aa -D_HPUX_SOURCE
    Colin McPhail : "The one quirk was
    that when the boot compiler called 'make' to build cs the make
    terminated immediately for no apparent reason.  However, running
    make by hand from cs.code worked just fine."

HP-UX 9.05 using gcc V2.5.8
    gcc version 2.7.0 seems to be a problem for GC

RISC/os 5.01, gcc 2.6.2 (configuration: mips-mips-riscos5bsd, ported by
    yoshida@agusa.nuie.nagoya-u.ac.jp):
	CC= gcc -G 80 
	CONFIG_CC2= "-Wl,-nocount %/System/GC/gc.a -lm"
	CONFIG_PROLIX= "-v -Wl,-v"


Windows 3.5, Visual C++ 2.0, nmake 1.50:
    This port is not stable yet; Robert Storlind (robert@crclund.abb.se)
    was working on it.  Here are my guesses:
	CC= cl /nologo /DWIN32 /Za /w
	CONFIG_CC2= "\#/System/GC/gc.lib"
	CONFIG_OPT= "/Od"
	CONFIG_DEBUG= "/Od"
	CONFIG_MAKE= "nmake"
	CONFIG_EXEC= "/Fe"
	CONFIG_OBJ= ".obj"
	CONFIG_LIB= ".lib"
	CONFIG_SEP= " && "


Here are some notes for installing Sather onto a Debian GNU/Linux system generously provided by Alexander Blazej alexb@csua.berkeley.edu ** How to install Sather 1.1 on a Debian GNU/Linux 1.3.1 system *** Introduction ---------------- I made some notes while installing Sather 1.1 and present them here as a guide in the hope that they will help others with their installation. I have a Debian 1.3.1 GNU/Linux installation on an Intel 686 CPU (i.e. Pentium-II) system. My Debian installation is vanilla except I replaced the Linux 2.0.29 kernel with 2.0.33 to make my Ethernet card happy. I have the gcc which comes with Debian 1.3.1; running "gcc -v" gives "gcc version 2.7.2.1". After following this installation everything should work except the Sather browser "bs" emits this harmless (I hope) warning on startup: Browser ignored option:-I/opt/Sather/System/Common But otherwise everything seems to work fine. I don't know how to make the browser happy. If you do please let me know. *** Step 1: Unpacking the Sather distribution --------------------------------------------- Obtain the Sather distribution from either: http://www.icsi.berkeley.edu/~sather/Getsather/getsather.html ftp://ftp.icsi.berkeley.edu/pub/sather or one of the Sather mirror sites. Since Debian currently does not offer a Sather installation package, as user "root" do the following "mkdir /opt", "mv Sather-1.1.tar.gz /opt", "cd /opt", "tar -xvzf Sather-1.1.tar.gz", and (for tcsh) "setenv $SATHER_ROOT /opt/Sather". To see why I choose to install to "/opt", see "http://www.pathname.com/fhs/" and read the File Hierarchy Standard 2.0 . Make this link so it is easy to reconfigure your system when you upgrade to X11R7: "ln -s /usr/X11R6 /usr/X11". The configuration files I give below assume this link. The Sather programmer's manual is in Post-Script format in $SATHER_HOME/Doc/programmer-manual.ps, it's 256 pages. I suggest running lp $SATHER_HOME/Doc/programmer-manual.ps now to give your printer a head start. Look in $SATHER_HOME/Doc. Read the "Installation" file. In this file another Linux user wrote that they had to "remove the leading underscore from _GC_push in machdep.c" to make the garbage collector compile. I did not and the collector still compiled without complaint. *** Step 2: Set Up Optimization -------------------------------- Skip this step if you are installing for a 386 or 486 CPU. If you have a 586 (Pentium) or better CPU, you can follow the instructions in this step if you want to compile code which will consume more memory but will execute faster. Warning: Programs made with these optimizations might not run on 386 CPU systems. Make the Sather compiler faster but larger. ------------------------------------------- In both $SATHER_HOME/System/Platforms/linux/Makefile and $SATHER_HOME/System/Common/Makefile Comment out the line: GC_CFLAGS=-O3 -DSILENT -DNO_SIGNALS with a "#" and add below it this line (which should actually be one long line) GC_CFLAGS=-O3 -DSILENT -DNO_SIGNALS -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 Make Sather produce optimized executables when given the "-fast" option. ------------------------------------------------------------------------ In $SATHER_HOME/System/Common/CONFIG.proto Comment out the line: CC_OPTIMIZE_FLAG: "","-O2"; with a "-- " and add below it this line (which should actually be one long line): CC_OPTIMIZE_FLAG: "","-O3 -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2"; *** Step 3: Ensure You Have the Correct Versions of Tcl/Tk ---------------------------------------------------------- Run the command: dpkg --list 'tk40*' You should see one or both of the following lines: ii tk40 4.0p3-5 The Tk toolkit for TCL and X11 v4.0 - Run-Ti ii tk40-dev 4.0p3-5 The Tk toolkit for TCL and X11 v4.0 - Develo If you don't you need to run "dselect" as user "root" to install "tk40". Run the command: dpkg --list 'tcl74*' You should see one or both of the following lines: ii tcl74 7.4p3-5 The Tool Command Language (TCL) v7.4 - Run-T ii tcl74-dev 7.4p3-5 The Tool Command Language (TCL) v7.4 - Devel If you don't you need to run "dselect" as user "root" to install "tcl74". *** Step 4: Modify Configuration Files to Fit a Debian System ------------------------------------------------------------- To satisfy the tcltk Platform.module, as user "root" do this: cd /usr/lib ln -s libtk4.0.a libtk.a ln -s libtcl7.4.a libtcl.a Rename your old $SATHER_HOME/System/Platforms/tcltk/Platform.module and put the section below in its place --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< -- Tcl/Tk platform.module -- Specifies paths where various tk/tcl libraries may be found -- -gui -dualgui and the Browser all rely on these paths -- Depends on and requires the X platform -not_a_real_platform $(SATHER_HOME)/Library/System/TclTk/TclTk.module -- ---------------------------------------------------------------------------- -- Default Settings. -- -- -C_flag -I/usr/local/X11/include/ -- Expected to contain tk.h -- -C_flag -I/usr/local/include/ -- Expected to contain tcl.h -- -C_flag -L/usr/local/lib/ -- Expected to contain libtk.a -- -C_flag -L/usr/local/lib/ -- Expected to contain libtcl.a -- ---------------------------------------------------------------------------- -- Debian GNU/Linus 1.3.1 settings. -- -C_flag -I/usr/include/tcl -- Expected to contain tk.h -C_flag -I/usr/include/tcl -- Expected to contain tcl.h -C_flag -L/usr/lib/ -- Expected to contain libtk.a -C_flag -L/usr/lib/ -- Expected to contain libtcl.a -- ---------------------------------------------------------------------------- -C_flag -ltk -C_flag -ltcl -X --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< And also... To satisfy the X Platform.module, as user "root" do this: cd /usr/lib ln -s libX11.sa libX11.a Rename your old $SATHER_HOME/System/Platforms/X/Platform.module and put the section below in its place --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< -- X platform module -- Specifies paths where various X libraries may be found -- Gui, DualGui and the Browser all rely on these paths -not_a_real_platform ---------------------------------------------------------------------------- -- Default Setting. -- -C_flag -I/usr/local/X11/include/ -- Expected to contain X11/ headers -- Debain GNU/Linus 1.3.1 setting. -C_flag -I/usr/X11/include/ -- Expected to contain X11/ headers -C_flag -lm ---------------------------------------------------------------------------- -- Default Setting. -- -C_flag -L/usr/local/X11/lib/ -- Expected to contain libX11.a -- Debain GNU/Linus 1.3.1 setting. -C_flag -L/usr/X11/lib/ -- Expected to contain libX11.a -C_flag -lX11 -- If setting these -L flags does not work correctly, it might be -- because your version of gcc has some built-in paths which over-ride -- these paths. If this is the case, try modifying the platform module -- itself. For instance, you could change -- -C_flag -ltk -- to: -- -C_flag /usr/local/X11/lib/libtk.a -- Likewise, you could change the paths to header files, but these are -- harder to find. The -H flag in gcc can be useful for debugging --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< To integrate the Sather info files into the system, as user "root" do this: cd /usr/info ln -s $SATHER_HOME/Emacs/sather.info ln -s $SATHER_HOME/Emacs/sather-tutorial.info ln -s $SATHER_HOME/Emacs/sather-mode.info Edited /usr/info/dir, under the line: * Menu: The list of major topics begins on the next line. add the following text: --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< Local Menu Items ================ Sather Development * Sather: (sather). The Sather Specification. * Sather Tutorial: (sather-tutorial). The Sather Eclectic Tutorial. * sather-mode: (sather-mode). The Sather Emacs Programming Environment. Debian Supplied Menu Items ========================== --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< If you use GNU emacs follow the directions at the top of: $SATHER_HOME/Emacs/sample.emacs then skip to the next step. However to setup for xemacs (aka Lucid emacs), ignore the "sample.emacs" instructions and do as user "root": cp $SATHER_HOME/Emacs/sample.emacs $SATHER_HOME/Emacs/xemacs Add to the end of your ~/.emacs file: (load (expand-file-name (concat (getenv "SATHER_HOME") "/Emacs/xemacs"))) Modify $SATHER_HOME/Emacs/xemacs as follows, comment out (defvar sather-use-highlight-package 'hl319 with a "; " comment, and add below it: (defvar sather-use-highlight-package 'font-lock In the same file, comment out ((eq sather-use-highlight-package 'hl319) with a "; " comment, and add below it: ((eq sather-use-highlight-package 'hlThreeNineTeen) If you don't make that last change, when you start xemacs you'll get the error "Args out of range 33554444, 32, 127". *** Step 5: Change "sh" Temporarily ------------------------------------ Do an "ls -lAF /bin/sh". If you get: lrwxrwxrwx 1 root root 4 Feb 1 10:13 /bin/sh -> bash* you need to change "sh" to point to "ash" (or similar). As user "root", "cd /bin", "rm sh; ln -s ash sh". If you don't make this change before running make (described in the next step), then you'll get this error: make[1]: Entering directory `/opt/Sather-1.1/System/Common' Creating Common/CONFIG... make[1]: Leaving directory `/opt/Sather-1.1/System/Common' Making serial library: Base Math System Socket Gui Demos DualGui TclTk Ext IO Strings Views Containers Graphs /bin/sh: -c: line 1: syntax error near unexpected token `done' /bin/sh: -c: line 1: `CC="gcc" RANLIB="ranlib" CPP="/lib/cpp -C -P" MV="mv" AR="ar" RM="rm -f" LN="ln -s" CP="cp" export CC RANLIB CPP MV AR RM LN CP ; echo; for i in "BOOT","li nux"; do echo Making platform $i...; (cd System/ Platforms/$i; make;) done ' make: *** [SYSTEM] Error 2 BUT, remember to change it back (see *** Step 7: Changing back "sh"). I initially didn't, and when I rebotted my system I got these complaints: VFS: Mounted root (ext2 filesystem) readonly. INIT: version 2.71 booting trap: Illegal number: INT Loading /etc/kbd/default.map Configuring serial ports..../etc/rc.boot/0setserial: 1: Syntax error: Bad fd number run-parts: /etc/rc.boot/0setserial exited with return code 2 When I changed sh to point to bash and rebooted, everything was again fine. *** Step 6: Run Make -------------------- As user "root", "cd $SATHER_HOME". If you use csh/tcsh run: make clean >&! makeClean.out&; tail -f makeClean.out make full-install >&! makeFullInstall.out&; tail -f makeFullInstall.out make optional >&! makeOptional.out&; tail -f makeOptional.out If you have 60MB or more virtual memory, you can execute this next *optional* "testfull" make. If you have less than 60MB of virtual memory "testfull" might fail do to lack of memory. This "testfull" command will take a long time to complete even on a fast system: make testfull >&! makeTestFull.out&; tail -f makeTestFull.out& While running the "make" commands you can start reading the programmer's manual you started printing in Step 1. *** Step 7: Changing back "sh" ------------------------------ If you changed your symbolic link to "sh" in Step 5, now is the time to change it back. As user "root", do cd /bin rm sh; ln -s bash sh *** Step 8: Shell Configuration ------------------------------- For csh/tcsh setup, as user "root" add to /etc/csh.login --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< # ----------------------------------------------------------------------------- # Support for packages in /opt # This points to where the Sather compiler is installed. setenv SATHER_HOME /opt/Sather setenv PATH $SATHER_HOME/Bin:$PATH --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< And for "sh" users, add to /etc/profile --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< # ----------------------------------------------------------------------------- # Support for packages in /opt # This points to where the Sather compiler is installed. SATHER_HOME="/opt/Sather" PATH="$SATHER_HOME/Bin:$PATH" export SATHER_HOME PATH --%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%<--%< *** Step 9: Be Happy -------------------- Share your joy by sending a postcard to: The Sather Czar International Computer Science Institute 1947 Center Street, Suite 640 Berkeley CA 94709-1198 If you have ported it successfully to a system, send the changes to "sather-bugs@icsi.berkeley.edu" so I can incorporate them; or let me know that it runs without changes.


Enabling incremental garbage collection

Incremental collection is not enabled by default in the Boehm collector; this results in the greatest portability. On some platforms, incremental collection may dramatically improve memory consumption and general performance. Here's a note from Steven Buytaert about this; use at your own risk. In a future release Sather will use a custom garbage collector, so this is only of temporary significance. - Dave

During my experiments with Sather-1.0.8p0 (that I downloaded from ftp.icsi
without permission, I hope you forgive me...) on both my Linux machine I
found out the following:

  Machine = Linux 1.3.13
	     486DX2
	     31 Bogomips
	     32 Meg phys
	     80 Meg swap
  cs 1.0.8p0 compiled with
	     -fast
	     -no_check

  As benchmark I used to compile the Sather compiler itself without
  optimalisation and without compiling the generated C code (only_C).
  (I erased the code directories after each test, of course...)
  I got the following interesting timing results (seconds);

	Pass     | cs with incremental GC | cs without incremental GC
    -------------+------------------------+----------------------------
      Parse      |              26        |               23
      Find...    |              31        |               25
      graph...   |               0        |                0
      Check...   |             238        |              393
      Headers... |             367        |              579
    -------------+------------------------+----------------------------
      Time       |      11 minutes        |       17 minutes
      Max Swap   |      37 Meg Swap       |       44 Meg Swap

  So the incremental version gave me both a speed and memory
  consumption advantage.  When issuing 'make test' in the GC directory
  and the test starts with 'switching to incremental collection' (or
  something alike), the GC can be used incrementaly. One then just has
  to add the call:

    GC_enable_incremental();

  just before the first allocation, in the file system.c. For cs, just
  before 'main_ob = ...'.

    -- 
    Steven Buytaert
    home : buytaert@clever.be
    work : buytaert@imec.be