From owner-freebsd-small Sun Jan 31 18:09:59 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA01946 for freebsd-small-outgoing; Sun, 31 Jan 1999 18:09:59 -0800 (PST) (envelope-from owner-freebsd-small@FreeBSD.ORG) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA01928 for ; Sun, 31 Jan 1999 18:09:48 -0800 (PST) (envelope-from arg@arg1.demon.co.uk) Received: from localhost (arg@localhost) by arg1.demon.co.uk (8.8.8/8.8.8) with SMTP id CAA11704; Mon, 1 Feb 1999 02:08:16 GMT (envelope-from arg@arg1.demon.co.uk) Date: Mon, 1 Feb 1999 02:08:10 +0000 (GMT) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk Reply-To: Andrew Gordon To: Warner Losh cc: small@FreeBSD.ORG Subject: Re: compressed executables in low memory environements In-Reply-To: <199901300852.BAA75275@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 30 Jan 1999, Warner Losh wrote: > > Has any thought (or work) been given to being able to run compressed > executables basically in place? Right now the gzip device in FreeBSD > does almost this, but requires the entire program to be decompressed > before running. What I had in mind would be something that would use > fixed length blocks (not optimal for compression, but not bad either) > so that they could be "paged" into uncompress memory easily? Other systems have done this, one example being Acorn RiscIX (4.3BSD on the early ARM processors). The scheme there was to compress each page (ie. hardware MMU page) of the file separately, with the expectation that the compressed version would fit in fewer filesystem blocks than the original. Hence a 'squeezed' executable would have exactly the same file length as the original, but its allocation of disc blocks would be 'sparse'. A 'squeezed' executable was distinguished from a normal one by having a different magic number in the a.out header. This worked particularly well on the hardware in question due to a number of factors: - The hardware MMU page size was an unusually large 32Kbyte. - Discs were small, hence small filesystem block sizes, so there was a good chance of saving one or more filesystem blocks when compressing the 32K chunks. - The machines had a fast (for its day) CPU coupled to a slow I/O system, so the overhead of decompressing the data was comparable to that of bringing in an extra disc block - possibly even a performance gain. - The disc supplied with the base model machine would not hold the full OS distribution unless most of the executables were squeezed! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message