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.
A nice thing about the new installation procedure is
that it compiles and installs the supplied bootstrap compiler
generated at ICSI (which is a fast one) as your Sather
compiler, without needing too much memory.
The exact requirements to compile an own Sather compiler depend
on the tools and installation you choose. If you just do not want to
use the supplied boot compiler as your Sather compiler, you will need
about 45MB virtual memory for a start.
Moreover, if you want to have the fastest compiler possible and
do not want to use the supplied boot compiler,
different optimizations and static analyses will require about
60MB.
If you are running out of memory you can separate the Sather->C
compilation from the C->object Code stage, you might try
something like "
At the end of this file you'll find a note about (experimental)
incremental garbage collection which could
also help. Once again, if memory resources are scarce, you are
probably better off with the default installation. Full installation
may be very useful when porting the compiler to a new platform to
make sure the port is successful.
cs .... -only_C && make -C foo.code
"
to shut down the Sather compiler before C compilation starts.
MAKE_COMMAND
if you
have one. If you are lucky you might not have to change anything.
"/usr/gowda/Sather"
Otherwise, go to the top directory and type `make'. That should do the following things:
If you are porting the compiler to a new platform or simply feeling adventurous, you may want to compile Sather compiler sources using the boot compiler and install the resulting compiler as your Sather compiler. See memory requirements above. You need to type 'make full-install' which repeats the steps above up to compiling the boot compiler. Then it does the following:
A common problem is for the tests of the IEEE extreme cases (such as 0.0/0.0) to not come out right. If these fail on your system, it's not a big deal and won't keep you from using the compiler.
If you want to do a stress test compiling the new compiler with
itself, do a `make testfull
'.
SATHER_HOME
and is not "burned in".
-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:
System/Platforms/X/Platform.module
and
System/Platforms/tcltk/Platform.module
and change them to find your own include files and libraries.
System/Platforms/dualgui/dual_gui_server
.
Systems/Platform/<your platform>/Platform.module
.
Library/System/Gui
by using the option (when compiling) of -gui
. You can
get at the dual gui (if it the server has been installed) by
using the compiler option -dualgui
. More details may be
found in: Gui/index.html
Bin/bs
. Compile time errors can be related
to
System/Platforms/X/Platform.module
and
System/Platforms/tcltk/Platform.module
and change them to find your own include files and libraries.
../Browser/README
and tcl_tk_notes.
for more information.
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
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.mapConfiguring 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.
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