List of platforms
-----------------

The Unix version of CLISP is known to run on a variety of machines
and operating systems. The following is a list of successful compiles,
in the format


hardware              OS             compiled by
date                  test-time      email address

(Test-time is the time needed for "make test". Measure user time.)


PC 486/33, 8 MB RAM   Linux 0.98     Bruno Haible
17.11.1992                  415 s    <haible@ma2s2.mathematik.uni-karlsruhe.de>
14.12.1992                  418 s
31.12.1992 (gcc233)         384 s
31.12.1992 (gcc233)         377 s
2.1.1993  (gcc233,shm)      359 s
2.1.1993  (gcc233,shm)      363 s
5.1.1993  (gcc233,486)      367 s
15.1.1993 (gcc233,486,shm)  356 s
15.1.1993 (gcc233,486,shm)  362 s
19.1.1993 (gcc233,486,shm)  360 s
29.1.1993 (gcc233,486)      366 s
10.2.1993 (gcc233,486,shm)  359 s
4.3.1993  (gcc233,486,shm)  351 s

PC 486/33, 8 MB RAM   Linux 0.99.7   Bruno Haible
18.3.1993 (gcc233,486,mmap) 337 s    <haible@ma2s2.mathematik.uni-karlsruhe.de>
5.5.1993  (gcc233,486,mmap) 346 s
5.6.1993  (gcc240,486,mmap) 366 s
17.7.1993 (gcc245,486,mmap) 368 s

PC 486/33, 8 MB RAM   Linux 0.99.12  Bruno Haible
22.9.1993 (gcc245,486,mmap) 464 s    <haible@ma2s2.mathematik.uni-karlsruhe.de>
4.11.1993 (gcc252,486,mmap) 453 s
1.1.1994 (gcc257,486,shm)   483 s

PC 486/33, 8 MB RAM   Linux 1.1.19   Bruno Haible
20.6.1994 (gcc257,mmap)     569 s    <haible@ma2s2.mathematik.uni-karlsruhe.de>
27.6.1994 (gcc257,mmap)     515 s
28.6.1994 (gcc257,mmap)     526 s

PC 486/50, 32 MB RAM  Linux 0.99.14  Marcus Daniels
25.1.1994 (gcc258,shm)      331 s    <marcus@ee.pdx.edu>
25.1.1994 (gcc258,486,shm)  319 s   

Sun 4/70 (Sparc 2)    SunOS 4.1.1    Bruno Haible
19.11.1992 (gcc23)       291 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
22.12.1992 (gcc23)       298 s
28.12.1992 (gcc23)       291 s
1.1.1993   (cc)          424 s
1.2.1993   (gcc23)       268 s
4.2.1993   (gcc23)       276 s
28.3.1993  (gcc23)       276 s
11.5.1993  (gcc23)       274 s
2.11.1993  (cc -O0)      600 s
2.11.1993  (cc -O1)      493 s
3.11.1993  (cc -O2)      649 s
3.11.1993  (cc -O3)      614 s
3.11.1993  (cc)          582 s
14.1.1994  (cc)          632 s

Sun 4/75 (Sparc 2)    SunOS 4.1.3    Marcus Daniels
25.1.1994 (gcc233)       492 s       <marcus@ee.pdx.edu>

Sun 4c (Sparc 1)      SunOS 4.1.2    Martin Sjlin
16.12.1992               679 s       <marsj@ida.liu.se>

Sun 4m (Sparc 10)     SunOS 4.1.3    Bruno Haible
16.1.1993 (gcc233)       208 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
17.1.1993 (gcc233,shm)   203 s
20.1.1993 (gcc233,shm)   186 s
26.6.1994 (gcc)          307 s

Sun 4m (Sun 4/600)    SunOS 4.1.3    Marcus Daniels
25.1.1994 (gcc233,shm)   453 s       <marcus@ee.pdx.edu>

Sun386i               SunOS 4.0.2    Bruno Haible
13.1.1993                            <haible@ma2s2.mathematik.uni-karlsruhe.de>

Sun 4m (Sparc 10)     SunOS 5.1 (Solaris 2)
21.3.1993                387 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
7.9.1993                 500 s

Sun 3                 SunOS 4.1.1    Bruno Haible
17.4.1993               2296 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>

Sun 4d                SunOS 5.[23]   Adam M. Costello
2.12.1993 (gcc245)       313 s       <amc@ecl.wustl.edu>

Sun 4m (2 cpus)       SunOS 5.3      Alva L. Couch
23.2.1994 (gcc258)       203 s       <couch@cs.tufts.edu>

i386                  Consensys 4.0  Bruno Haible
18.12.1992             --- (*)       <haible@ma2s2.mathematik.uni-karlsruhe.de>
7.9.1993               --- (*)

PC 486/33, 32 MB RAM  Consensys 4.2  Jean-Claude Beaudoin
21.9.1993                            <jbeaudoi@sobeco.com>

HP 9000/825           HP-UX 8        Bruno Haible
27.6.1994               2498 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>

HP 9000/835           HP-UX 8        Bruno Haible
27.6.1994               1203 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>

HP 9000/720           HP-UX 8.05     Bruno Haible
1.1.1993                 309 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
27.6.1994                335 s

PC 486/33, 8 MB RAM   Coherent 4.0.1 Bruno Haible
16.5.1993 (cc)           470 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
16.5.1993 (gcc140)       413 s

PC 386/33, 16MB RAM   UHC UNIX SysV.4   Blake McBride
20.3.1993 (UHC_1)       1125 s          <blake@netcom.com>
20.3.1993 (UHC_2)       1182 s

PC 486/33, 16 MB RAM  SINIX-Z V5.41  Manfred Weichel
29.7.1993 (gcc245)       383 s       <manfred.weichel@mchp.sni.de>

PC                    386BSD 0.1     Charles Hannum
26.3.1993                            <mycroft@gnu.ai.mit.edu>

DECstation 5000       Ultrix V4.2A   Benlu Jiang
5.5.1993                             <manager@csdeca.cs.missouri.edu>

SGI Mips              IRIX 4         Michael Stoll
11.6.1993                315 s       <michael@rhein.iam.uni-bonn.de>

SGI Mips              IRIX 5         Christian Moen
31.12.1993 (gcc)                     <christim@ifi.uio.no>

IBM Risc System 6000  AIX 3.2        Gabor Herr
22.9.1993                            <herr@iti.informatik.th-darmstadt.de>

DEC Alpha AXP         OSF 1.3        Bruno Haible
3.12.1993                141 s       <haible@ma2s2.mathematik.uni-karlsruhe.de>
8.1.1994                 145 s

PC 486/50, 16 MB RAM  Onsite SysV R 4.2   Sebastian Feldmann
30.10.1993 (cc)          429 s            <snfeldma@teebox.franken.de>
7.11.1993 (gcc233)       348 s
7.11.1993 (gcc245)       345 s

Amiga 3000            AMIX 2.1 SysVR4.0   Michel Loi
22.12.1993 (gcc255)                       <Michel.Loi@lip.ens-lyon.fr>

NeXT                  NeXTstep 3.1   Marcus Daniels
30.10.1993 (cc)                      <marcus@ee.pdx.edu>

NeXT (68040/25)       NeXTstep 3.2        Marcus Daniels
18.1.1994                751 s            <marcus@ee.pdx.edu>
(cc=gcc222)
18.1.1994                627 s
(cc=gcc-222+Mach-VM-singlemap)

Sequent PTX (386/16)  DYNIX/ptx V2.1.0    Marcus Daniels
(gcc233, mmap)          2232 s            <marcus@ee.pdx.edu>

PC                    UnixWare       Alexander Adam
24.1.1994                            <adam@is.informatik.uni-stuttgart.de>

Data General M88000   DG/UX          Pat McClanahan
3.2.1994                 539 s       <mcclanah@dlgeo.cr.usgs.gov>

PC                    BSDI/386 1.1        Atsuo Ohki
16.5.1994                                 <ohki@gssm.otsuka.tsukuba.ac.jp>


When you install CLISP on a machine not mentioned here, please send us a short
note containing the information mentioned above. If you didn't succeed in
building CLISP, please tell us the problems: we will try to make CLISP as
portable as possible.


Special hints for some platforms:
---------------------------------


On 386BSD 0.1:

386BSD can't identify itself. Before executing makemake, you need to create a
program called "arch" that outputs "386BSD". For example:
  $ cat > /usr/bin/arch <<EOF
  #!/bin/sh
  echo 386BSD
  EOF
  $ chmod a+x /usr/bin/arch

Add -DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE to the CFLAGS in the makefile. 386BSD
declares the shared memory and memory mapping facilities (shm*, mmap too?)
in the header files, but does not implement them in the kernel.

In unixconf.h change
  #define HAVE_SHM 1           to   #undef HAVE_SHM
  #define IOCTL_REQUEST_T int  to   #define IOCTL_REQUEST_T unsigned long
  #undef IOCTL_DOTS            to   #define IOCTL_DOTS


On a Sun4 (Sparc) under SunOS 4:

The Sun cc is usable only without the optimization flag "-O". (At least spvw.d
is compiled incorrectly when -O is used.)
It is best to get and install GNU gcc. (Gcc version 2.2 or later required.)


On a Sun3 (68020) under SunOS 4:

In the makefile, I had to add -DNO_MULTIMAP_FILE -DNO_MULTIMAP_SHM to the
CFLAGS, and change
     PACK = tar
to   PACK = /usr/local/gnu/bin/gtar


On a Sun4 (Sparc) under SunOS 5.2 or SunOS 5.3:

For the readline library, you *may* have to add -D_POSIX_VERSION to the CFLAGS
in the readline/Makefile, and modify the line containing SIGNALBLOCK_POSIX
in readline/config.h. I cannot tell anything definitely correct about this.

Make sure your PATH contains the X11/bin directory. Especially xmkmf must be
found. Make sure your LD_RUN_PATH contains the X11/lib directory. Otherwise
the shared X11 libraries won't be found.
For example, you may append ":/usr/openwin/lib" to your LD_LIBRARY_PATH and
replace "-Y P,/usr/ccs/lib:/usr/lib" in the makefile by
"-Y P,/usr/ccs/lib:/usr/lib:/usr/openwin/lib". To make sure these settings are
in effect every time clisp is run, it may then be useful to add the lines
    LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/openwin/lib"
    export LD_LIBRARY_PATH
to the /usr/local/bin/clisp script.

In the makefile, add -DNO_MULTIMAP_SHM to the CFLAGS. Thus prevent clisp from
using shared memory, because it tries to attach more segments that the default
limit (6). Alternatively, you may increase this limit: put the line
set shminfo_shmseg=200
into /etc/system, reboot, and continue installing clisp.


On a HP9000/8xx under HP-UX version 8:

If cc had no bugs:
  Choose "cc -Aa -z -D_HPUX_SOURCE" or "c89 -z -D_HPUX_SOURCE" as compiler.
  You need the -Aa flag resp. the c89 compiler because the normal "cc" does not
  expand macros with arguments within constant expressions in preprocessor
  commands like #if.
  Without the -D_HPUX_SOURCE flag many include files are incomplete. When using
  -D_POSIX_SOURCE instead, <errno.h> fails to define ELOOP.
  The -z flag is harmless.
Alas, cc and c89 initialize string arrays declared like
    static char* table[] = { 0?"a":1?"b":"", ..., 0?"x":1?"y":"", };
with NULL pointers!

So get and install GNU gcc. This works for sure.

If you get an error message "./configure: sh internal 1K buffer overflow"
the remedy is either to get and install GNU bash and replace the first line
of src/configure by "#!" and the full pathname of bash, or to replace the
first line of src/configure by "#!/bin/ksh".
An even simpler remedy to this is to enter
  CONFIG_SHELL=/bin/ksh
  export CONFIG_SHELL
before calling "target".

If lisp.run generates a core dump (SIGSEGV or SIGBUS) when called, the
reason is apparently a bug in the system's malloc() function. The remedy
is to get and build GNU malloc and add the suitable path ../malloc/gmalloc.o
to the OBJECTS in the makefile. (Note that HP-UX has two different malloc()
implementations. Both are broken. When used with CLISP, the one in the
default libc.a leads to a SIGSEGV, the one in libmalloc.a leads to a SIGBUS.)


On a HP9000/3xx under HP-UX version 8:

If you are using GNU gcc 2.4.5 with the HP-UX assembler, in the makefile add
-DHPUX_ASSEMBLER -DNO_ASM to the CFLAGS and remove -fomit-frame-pointer from
the CFLAGS. This way the best optimizations are disabled, but otherwise you
are risking core dumps.


On Consensys System V 4.0:

Choose "cc -I/usr/include" as compiler.
Otherwise /usr/ucbinclude/sys/sysmacros.h will be included instead of
/usr/include/sys/sysmacros.h, and this lacks the definition of ctob().

Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile. The shared memory
facilities of Consensys do not work as expected. This flag prevents CLISP
from using them.

(*) The lisp.run you get is a program that reliably crashes your machine.


On Consensys System V 4.2:

Add -DNO_MULTIMAP_SHM -DSVR4 -DUSL to the CFLAGS in the makefile.
Use "-O", not "-g", as compiler optimization settings in the CFLAGS,
otherwise the ISQRT function may not work.


On 386 UHC UNIX System V release 4:

Add -DNO_MULTIMAP_SHM -DSVR4 -DUSL to the CFLAGS in the makefile.


On Onsite System V 4.2:

Add -DUSL to the CFLAGS in the makefile.
Add -lsocket -lnsl to the LIBS in the makefile.


On UnixWare:

Add -DNO_MULTIMAP_SHM -DUNIX_SYSV_UHC_1 to the CFLAGS in the makefile.
This is because shared memory does not work, and malloc() returns
addresses in the range 0x080xyzzy.


On IRIX 3.2.1:

cc is too buggy: it dumps core when compiling spvw.i. You'll see a message
"Fatal error in: /usr/lib/ccom - core dumped".

Get and install GNU gcc.


On IRIX 4:

If you are using cc, choose "cc -ansi" as compiler. cc in non-ANSI mode
fails to expand macros with arguments within preprocessor directives like #if.
Since the compiler rejects 8-bit characters in strings, you will have to
convert the sources to plain ASCII first.
Add  -Olimit 3000  to the CFLAGS in the makefile. This ensures that the
bytecode interpreter will get optimized, which is crucial for performance.
If the compiler signals an internal error in unix.d, pointing to the line
"extern signal_handler signal (int sig, signal_handler handler);",
then comment out that line.


On IRIX 5:

Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile.
With IRIX 5.1(.0.1), it is necessary to add -D_POSIX_4SOURCE to the CFLAGS
in the makefile.


On DECstation 5000, Ultrix:

After executing "target ...", change the first line in makemake from
"#! /bin/sh" to "#! /usr/bin/ksh". /bin/sh apparently doesn't support
function definitions.
Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile. Shared memory
facilities do not work: even SHMLBA is not defined correctly in <sys/shm.h>.


On Apple Macintosh, A/UX:

Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile. Shared memory
facilities do not work: even SHMLBA is not defined correctly in <sys/shm.h>.


On an Amiga running AMIX 2.1 SVR4.0:

Add -DUSL -DSVR4 -DNO_MULTIMAP_SHM -DNO_MULTIMAP_FILE to the CFLAGS in the
makefile. If you don't have the GNU assembler gas, then add -DNO_ASM to
the CFLAGS in the makefile. You may need to add -lsocket -lnsl to the LIBS
in the makefile.


On Coherent386 4.0.1:

If you are using MWC cc:
  First convert the sources to plain Ascii. "cc" barfs on input files
  containing non-Ascii characters even though Coherent uses the PC character
  set.  "cd unix"  "cc -O cv-to-ascii.c -o cv-to-ascii"
  "cp cv-to-ascii to-ascii all-to-ascii /usr/local/bin"  "cd .."
  "all-to-ascii src/* utils/* doc/*"
If you are using GNU gcc:
  First convert the sources to the IBM PC character set Coherent uses.
  "cp dos/cv_lt_pc.c unix/cv-to-ascii.c"
  "cd unix"  "cc -O cv-to-ascii.c -o cv-to-ascii"
  "cp cv-to-ascii to-ascii all-to-ascii /usr/local/bin"  "cd .."
  "all-to-ascii src/* utils/* doc/*"

Then execute the configure scripts using ksh instead of sh.
"cd src"  "ksh configure"  "cd readline"  "ksh configure"

Fix the readline/ subdirectory Makefile: remove the two lines with
the .c.o rule, and set the CFLAGS line to "CFLAGS = -O -DVI_MODE".
"vi Makefile" ... "cd .."

Then execute the makemake script using ksh instead of sh.
/bin/sh doesn't support function definitions.
"ksh makemake > makefile"

Add -DNO_MULTIMAP_SHM to the CFLAGS in the makefile. Shared memory
facilities do not work: even SHMLBA is not defined correctly in <sys/shm.h>.

Then "make". If you are using MWC cc and it stops saying
"Fatal error: EOF in midline", then simply retry, perhaps with less machine
load.


On SINIX-Z (a System V Release 4 Unix):

Add -DUSL to the CFLAGS in the makefile.


On AIX:

You can't use "cc" as compiler since it wants more than 64 MB RAM to compile
eval.d. You will use GNU gcc without regrets.
Choose "gcc -Dunix" as compiler.

Add -DNO_SINGLEMAP -DNO_MULTIMAP_SHM to the CFLAGS in the makefile.


On Sequent ptx:

Add -lsocket -linet -lnsl to the LIBS in the makefile.


On Atari ST/TT running MiNT:

Use "gcc -Dunix -U__TOS__" as compiler. The "-Dunix -U__TOS__" flags make
CLISP forget that it will be running on an Atari. MiNT is treated like any
other Unix operating system.

If you are on an Atari TT, add -DATARITT to the CFLAGS in the makefile.
This is because ST and TT have different address space layout.


On DEC Alpha AXP running OSF 1.3:

If cc had no bugs:
  Add  -Olimit 1500  to the CFLAGS in the makefile. This ensures that the
  bytecode interpreter will get optimized, which is crucial for performance.
Alas, I didn't succeed in building a working lisp.run with cc. cc cannot
compile package.d correctly.

So get and install GNU gcc (version 2.5.5 or newer).

Add -DNO_SINGLEMAP -DNO_MULTIMAP_SHM to the CFLAGS in the makefile. Neither
mmap() nor the shared memory facility is usable: mmap() returns errno=ENOMEM,
shmget() works only for segsize < 4112 KB, shmat() returns errno=EINVAL.


Hints for porting to new platforms:
-----------------------------------

Choose a reliable C compiler. GNU gcc is a good bet.

Has your machine a weird address space layout?
CLISP assumes that the code and data area as well as the area of malloc'ed
memory have addresses in the lower 16 MB, that is, addresses occupying
only the lower 24 (out of 32) address bits. This allows CLISP to use the
upper 8 bits as tags, for encoding the run time type of Lisp objects.
In case this assumption does not hold, either
* find a way to store 6 tag bits and an address in a 32 bit word, and
  modify lispbibl.d appropriately - not a trivial task -, or
* add -DWIDE to the CFLAGS. This will cause 64 bits (instead of 32) to be
  allocated for every pointer to a Lisp object: 32 for the address, the
  remaining for the tags. This will severely degrade CLISP's efficiency: memory
  consumption will grow by 60% or more, speed will be lowered by 30% or more.
  You will need a C compiler that provides 64 bit integer types; one such
  compiler is GNU gcc (version 2.3.3 or later).
No assumptions about the stack area are made.

Has your operating system shared memory or memory mapping facilities?
CLISP tries to use them to save the time for stripping off the tag bits (see
above) before memory accesses. If you get an error message concerning shared
memory, you should add -DNO_MULTIMAP_SHM to the CFLAGS and recompile.
Doing so introduces a speed penalty of about 6%.

If interpreted.mem was successfully generated, but lisp.run dumps core when
loading .fas files, you should add -DSAFETY=3 to the CFLAGS and recompile.
Find out which is the least SAFETY level that produces a working lisp.run and
compiled.mem, and tell me about it.

