update for 4.0
authorJay Lepreau <lepreau@ucbvax.Berkeley.EDU>
Wed, 18 Sep 1985 08:27:10 +0000 (00:27 -0800)
committerJay Lepreau <lepreau@ucbvax.Berkeley.EDU>
Wed, 18 Sep 1985 08:27:10 +0000 (00:27 -0800)
SCCS-vsn: usr.bin/compress/doc/README 5.3

usr/src/usr.bin/compress/doc/README

index 8e5797c..c5f146d 100644 (file)
 
 
-       @(#)README      5.2 (Berkeley) %G%
+       @(#)README      5.3 (Berkeley) %G%
 
 
-Compress version 3.2 enhancements:
+Compress version 4.0 improvements over 3.0:
+       o compress() speedup (10-50%) by changing division hash to xor
+       o decompress() speedup (5-10%)
+       o Memory requirements reduced (3-30%)
+       o Stack requirements reduced to less than 4kb
+       o Removed 'Big+Fast' compress code (FBITS) because of compress speedup
+       o Portability mods for Z8000 and PC/XT (but not zeus 3.2)
+       o Default to 'quiet' mode
+       o Unification of 'force' flags
+       o Manual page overhaul
+       o Portability enhancement for M_XENIX
+       o Removed text on #else and #endif
+       o Added "-V" switch to print version and options
+       o Added #defines for SIGNED_COMPARE_SLOW
+       o Added Makefile and "usermem" program
+       o Removed all floating point computations
+       o New programs: [deleted]
 
 
-       (a) portability mods for Z8000 and PC/XT
-       (b) default to 'quiet' mode
-       (c) unification of 'force' flags
-       (d) multi-file bug fix for USERMEM code
-       (e) decompress() speedup (5-10%)
-       (f) manual page overhaul
+The "usermem" script attempts to determine the maximum process size.  Some
+editing of the script may be necessary (see the comments).  [It should work
+fine on 4.3 bsd.] If you can't get it to work at all, just create file
+"USERMEM" containing the maximum process size in decimal.
 
 
-This is the baseline for both BSD 4.3 and netnews 2.10.3 from Rick Adams.
+The following preprocessor symbols control the compilation of "compress.c":
+
+       o USERMEM               Maximum process memory on the system
+       o SACREDMEM             Amount to reserve for other proceses
+       o SIGNED_COMPARE_SLOW   Unsigned compare instructions are faster
+       o NO_UCHAR              Don't use "unsigned char" types
+       o BITS                  Overrules default set by USERMEM-SACREDMEM
+       o vax                   Generate inline assembler
+       o interdata             Defines SIGNED_COMPARE_SLOW
+       o M_XENIX               Makes arrays < 65536 bytes each
+       o pdp11                 BITS=12, NO_UCHAR
+       o z8000                 BITS=12
+       o pcxt                  BITS=12
+       o BSD4_2                Allow long filenames ( > 14 characters) &
+                               Call setlinebuf(stderr)
+
+The difference "usermem-sacredmem" determines the maximum BITS that can be
+specified with the "-b" flag.
+
+memory: at least               BITS
+------  -- -----                ----
+     433,484                    16
+     229,600                    15
+     127,536                    14
+      73,464                    13
+           0                    12
+
+The default is BITS=16.
+
+The maximum bits can be overrulled by specifying "-DBITS=bits" at
+compilation time.
+
+WARNING: files compressed on a large machine with more bits than allowed by 
+a version of compress on a smaller machine cannot be decompressed!  Use the
+"-b12" flag to generate a file on a large machine that can be uncompressed 
+on a 16-bit machine.
+
+The output of compress 4.0 is fully compatible with that of compress 3.0.
+In other words, the output of compress 4.0 may be fed into uncompress 3.0 or
+the output of compress 3.0 may be fed into uncompress 4.0.
+
+The output of compress 4.0 not compatible with that of
+compress 2.0.  However, compress 4.0 still accepts the output of
+compress 2.0.  To generate output that is compatible with compress
+2.0, use the undocumented "-C" flag.
+
+       -from mod.sources, submitted by vax135!petsd!joe (Joe Orost), 8/1/85
+--------------------------------
 
 
-       --jaw  (June 7, 1985)
------
 Enclosed is compress version 3.0 with the following changes:
 
 1.     "Block" compression is performed.  After the BITS run out, the
        compression ratio is checked every so often.  If it is decreasing,
        the table is cleared and a new set of substrings are generated.
 
 Enclosed is compress version 3.0 with the following changes:
 
 1.     "Block" compression is performed.  After the BITS run out, the
        compression ratio is checked every so often.  If it is decreasing,
        the table is cleared and a new set of substrings are generated.
 
-       This makes the output of compress 3.0 not compatable with that of
+       This makes the output of compress 3.0 not compatible with that of
        compress 2.0.  However, compress 3.0 still accepts the output of
        compress 2.0.  However, compress 3.0 still accepts the output of
-       compress 2.0.  To generate output that is compatable with compress
+       compress 2.0.  To generate output that is compatible with compress
        2.0, use the undocumented "-C" flag.
 
 2.     A quiet "-q" flag has been added for use by the news system.
 
 3.     The character chaining has been deleted and the program now uses
        2.0, use the undocumented "-C" flag.
 
 2.     A quiet "-q" flag has been added for use by the news system.
 
 3.     The character chaining has been deleted and the program now uses
-       hashing.  This boosts speed , especially during compression of
-       large files.  Other speed improvements have been made, such as
-       using putc() instead of fwrite().
+       hashing.  This improves the speed of the program, especially
+       during decompression.  Other speed improvements have been made,
+       such as using putc() instead of fwrite().
 
 4.     A large table is used on large machines when a relatively small
        number of bits is specified.  This saves much time when compressing
 
 4.     A large table is used on large machines when a relatively small
        number of bits is specified.  This saves much time when compressing
-       for a 16-bit machine on a 32-bit virtual machine.
+       for a 16-bit machine on a 32-bit virtual machine.  Note that the
+       speed improvement only occurs when the input file is > 30000
+       characters, and the -b BITS is less than or equal to the cutoff
+       described below.
 
 Most of these changes were made by James A. Woods (ames!jaw).  Thank you
 James!
 
 Most of these changes were made by James A. Woods (ames!jaw).  Thank you
 James!
@@ -55,6 +117,7 @@ memory: at least             BITS            cutoff
    4,718,592                    16               13
    2,621,440                    16               12
    1,572,864                    16               11
    4,718,592                    16               13
    2,621,440                    16               12
    1,572,864                    16               11
+   1,048,576                    16               10
      631,808                    16               --
      329,728                    15               --
      178,176                    14               --
      631,808                    16               --
      329,728                    15               --
      178,176                    14               --
@@ -70,6 +133,8 @@ compilation time.
 If your machine doesn't support unsigned characters, define "NO_UCHAR" 
 when compiling.
 
 If your machine doesn't support unsigned characters, define "NO_UCHAR" 
 when compiling.
 
+If your machine has "int" as 16-bits, define "SHORT_INT" when compiling.
+
 After compilation, move "compress" to a standard executable location, such 
 as /usr/local.  Then:
        cd /usr/local
 After compilation, move "compress" to a standard executable location, such 
 as /usr/local.  Then:
        cd /usr/local
@@ -119,7 +184,7 @@ Here is the README file from the previous version of compress (2.0):
 >              The bug was in the different byte/bit ordering on the
 >              various machines.  This has been fixed.
 >
 >              The bug was in the different byte/bit ordering on the
 >              various machines.  This has been fixed.
 >
->              This version is NOT compatable with the original vax posting
+>              This version is NOT compatible with the original vax posting
 >              unless the '-DCOMPATIBLE' option is specified to the C
 >              compiler.  The original posting has a bug which I fixed, 
 >              causing incompatible files.  I recommend you NOT to use this
 >              unless the '-DCOMPATIBLE' option is specified to the C
 >              compiler.  The original posting has a bug which I fixed, 
 >              causing incompatible files.  I recommend you NOT to use this