Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!uw-beaver!milton!ogicse!intelhf!ichips!inews!pima!bhoughto
From: bhoughto@pima.intel.com (Blair P. Houghton)
Newsgroups: comp.unix.internals
Subject: Re: executing a stream / a compressed file
Message-ID: <2575@inews.intel.com>
Date: 16 Feb 91 00:39:40 GMT
References: <1991Jan15.204849@IASTATE.EDU> <118868@uunet.UU.NET> <9950@dog.ee.lbl.gov>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 23

In article <9950@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
>In article <118868@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
>>I once suggested to Chris Torek that the kernel should execute
>>compressed programs. He groaned.
>
>Here is why:  A compressed file (that is, one which has had redundancy
>removed by the compress(1) program) is a variable-length bit stream in
>which the meaning of any given set of bits depends on an arbitrarily
>large number of preceding bits (well, up to the compression table
>sizes).  In other words, there is no way to tell that bit 71342 is the
>start of a 9 bit long field whose meaning is `the sequence "hello"'
>without starting at bit 0 and uncompressing until bit 71342 is reached.

One wonders if you guys saw the newgroup of
alt.comp.compression, the first article of which mentioned
an "unbalanced," "fractal" compression algorithm.  It further
said one needs a supercomputer to do the compressing,
but apparently an abacus and a microsecond for uncompressing.

If so, we may be on to something, here...

				--Blair
				  "Or not; as the dichotomy may eventuate."