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.
>>>>>>> 2.7
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/gui/XTclTkPaths.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/gui/XTclTkPaths.module
.
../Browser/README
and tcl_tk_notes.html.
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: 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 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/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= " && " 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