Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!ncrlnk!ncr-sd!crash!pnet01!jdeitch
From: jdeitch@pnet01.cts.com (Jim Deitch)
Newsgroups: comp.os.minix
Subject: Compress
Message-ID: <4642@crash.cts.com>
Date: 16 Jul 89 17:16:15 GMT
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon CA
Lines: 32

ast@cs.vu.nl (Andy Tanenbaum) writes:
>
>I have gone through the net postings and found a number of useful programs.
>I have this fear that the next distribution is going to take 20 disks and cost
>$149.  I have also noticed that compress only seems to win a factor of 2.
>I wonder if better compression of C programs is possible.  In particular,
>suppose we had a two pass compression program.  Pass 1 collected all the
>strings in the program and their frequencies.  Pass 2 replaced the most
>important string by ASCII code 128, the next most important one by 129 etc,
>sort of like libpack.c does, only dynamically instead of using fixed strings.
>Most important means that the product of # occurences times length is
>maximum.  The compressed file would include regular ASCII characters 0-127,
>and 120 or so characters denoting strings.  The last 8 could be for
>1 tab, 2 tabs, 3 tabs, etc., and a two byte sequence for encoding runs of
>blanks.  The dictionary would have to go too.  One would also have to think
>carefully about what a string is, i.e., is "while" a string, or "while ("
>a better choice?  It is my suspicion that such a program could compress
>better than a factor of 2 on C programs.
>
>Does anyone know of such a program, or want to write one?
>
>Andy Tanenbaum (ast@cs.vu.nl)


Why not use a 16 bit compression?  I have a version that will compile on the
XT, AT under dos, and supports 16 bit.  Also, has anyone tried to port the
Atari 16 bit that went through the net awhile ago to the IBM?


UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jdeitch
ARPA: crash!pnet01!jdeitch@nosc.mil
INET: jdeitch@pnet01.cts.com