--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/README.Cray	Wed Dec 17 21:18:18 2003 +0000
@@ -0,0 +1,152 @@
+It should now be possible to compile and link Octave on the Cray SV1
+and perhaps other similar Cray systems using the following procedure.
+It even runs and seems to work, at least for the few small things I
+tried.
+
+  * Run
+
+      configure \
+	F77=ftn FFLAGS="-dp -O0" \
+	CC=cc CFLAGS=-O0 CXX=CC \
+	CXXFLAGS="-O0 -h new_for_init -h nomessage=76" \
+	--without-blas --without-lapack --disable-readline
+
+    The last to arguments tell Octave to use the reference blas and
+    lapack implmentation in Fortran and to not require the readline
+    library.  If you have the readline library, you can omit the last
+    option.  You can also try to use a vendor library for LAPACK and
+    BLAS, but how are those compiled?  You will need a version of the
+    library that is compiled for 64-bit double precision values, but
+    that uses the D and Z names (I'm not sure that this is the case
+    with the Cray librararies).
+
+    I'm using -O0 in an effort to speed up compilation.  If you want
+    an optimized version and have time to wait for the build to
+    complete, then use whatever -On option you like.
+
+  * Edit the generated Makeconf file and make sure that you have
+
+      FFLAGS = -dp -O0
+      CFLAGS = -O0
+      CXXFLAGS = -O0 -h new_for_init -h nomessage=76
+      FPICFLAG =
+      CPICFLAG =
+      CXXPICFLAG =
+
+    The first three should be handled automatically by the configure
+    arguments, but the others are not (yet).
+
+  * Edit liboctave/data-conv.h and force the definitions of
+    TWO_BYTE_INT and FOUR_BYTE_INT to be int.  These will have to be
+    fixed correctly later, but this fix will allow Octave to compile
+    and even run, though some things like saving and loading data with
+    some binary file formats will be broken.  Suggestions for a good
+    way to fix this are welcome.
+
+  * If building from CVS, you will need to have gperf installed, or
+    you can generate src/oct-gperf.h on some other machine and copy to
+    the src subdirectory in the Cray build tree.
+
+  * If you don't have TeX installed on your SV1, then edit the
+    generated octMakefile and remove doc from the SUBDIRS variable so
+    you won't try to run make in the doc subdirectory.  Otherwise, it
+    will fail because you don't have TeX installed (and why would
+    you?).  This is only a problem when building from CVS or if you
+    build from a distribution and configure with something other than
+    --prefix=/usr/local.
+
+  * Run
+
+      gmake -k omit_deps=true
+
+    and it should run all the way to creating an octave executable
+    (see below for why omit_deps=true is needed).
+
+
+REMAINING PROBLEMS
+------------------
+
+  * I tried to get dependency generation to work, but it seems there is
+    a bug in the C++ compiler because it keeps crashing with errors like
+    this:
+
+      making pathsearch.d from pathsearch.cc
+      CC-1353 CC: INTERNAL File = CColVector.cc, Line = 38
+
+	#include "oct-cmplx.h"
+			      ^
+
+      CC-2202 CC: ERROR
+	"/opt/ctl/CC_sv1/CC_sv1/lib/ccom" (pid 69504) was terminated
+         due to receipt of signal 06:  Abort (core dumped).
+
+    when I try to use the -M option.  Dependency generation is
+    relatively slow, so maybe it would be worth trying to speed it up
+    by using a simpler tool.  We are currently using the compilers to
+    build lists of dependencies that include system header files, but
+    maybe it would be good enough if we only listed the header files
+    that are included with the Octave sources.  In that case, we could
+    probably write a simple script that could do the job and that
+    could run much faster than the compiler.
+
+  * IEEE Inf and NaN (and Octave's NA value, which is a particular NaN
+    value) are all currently set to DBL_MAX since the SV1 doesn't
+    support IEEE floating point numbers.  Will this be true of future
+    machines from Cray?  I don't think it is possible to have a fully
+    functional version of Octave (or Matlab) on a system without IEEE
+    numbers.
+
+  * TWO_BYTE_INT and FOUR_BYTE_INT types, mostly used in load-save.cc.
+    This can probably be solved by using arrays of char values and
+    some masking, but it will probably be a bit tricky.  The problem
+    is that various binary data file formats are specified using
+    integer values of specific sizes, so we need to be able to read
+    and write integer values in 16 and 32 bit formats.
+
+  * The code in liboctave/mach-info.cc that determines the floating
+    point format used by the system assumes that a double is exactly
+    twice as wide as an int.  This should be fixed, since the Cray has
+
+      sizeof (char)   == 1
+      sizeof (short)  == 8
+      sizeof (int)    == 8
+      sizeof (long)   == 8
+      sizeof (double) == 8
+
+    For now, I forced the floating point format based on an #ifdef CRAY.
+
+  * Build a working readline library.  Probably not too hard but I
+    didn't think it was worth the effort yet.  I can't run Octave
+    interactively on the SV1 I have access to anyway, so command line
+    editing doesn't matter much.
+
+  * Build the FFTW library for better fft performance.  Without this,
+    we still have fft and ifft functions using FFTPACK.
+
+  * Build the HDF5 library to support loading and saving of HDF
+    files.  This is not necessary unless you need to access Octave
+    data files that have been stored in the HDF file format.
+
+  * Link with fast BLAS and LAPACK libraries for better performance.
+    There is a Cray library, but I'm not sure whether we can use it
+    directly.  Does DGEMM in the Cray BLAS library use double
+    precision, or is it compiled with the equivalent of -dp?  If it
+    uses double precision (i.e., 128-bit floating point values) then
+    it will take some work to make this functional for Octave, since
+    Octave uses the D and Z names and we would presumably need the S
+    and C names instead.
+
+  * Shared libraries.  Apparently this is not supported on the SV1, so
+    dynamically linked functions (.oct files) will not work on this
+    system.
+
+  * There are a few warnings when compiling glob/glob.c that should
+    probably be fixed.
+
+
+John W. Eaton
+jwe@bevo.che.wisc.edu
+University of Wisconsin-Madison
+Chemical & Biological Engineering Department
+
+Wed Dec 17 15:17:29 2003

--- a/scripts/control/system/sysupdate.m	Wed Dec 17 03:31:29 2003 +0000
+++ b/scripts/control/system/sysupdate.m	Wed Dec 17 21:18:18 2003 +0000
@@ -119,5 +119,4 @@
     sys.stname = __sysdefstname__ (sys.n, sys.nz);
   endif
 
-
 endfunction