Re: Compilers for ultra-compact byte code?

maatwerk@euronet.nl (M.M. van der Laan) wrote:


> We are working on a compiler that produces very compact bytecode.
> Some tests have indicated a compression ratio of 90% on C++-like code.
>
> Our runtime doesn't interpret the code, but generates machine language
> before it executes. This 'post-compilation' method is faster than
> interpretation, especially for loops. And because postcompiling is
> only done for modules currently executing, a program uses less memory.
>
> You might use a similar method for microcontrollers. In fact, we
> thought about it ourselves. However, the problem is the size of the
> interpreter. So in our view there is not much to gain.


I think Andy Wolfe wrote a paper in about 1992 (IEEE Micro ??) in
which the instruction cache in a HW CPU used a
more-or-less-general-purpose compressor (e.g., gzip) to decompress the
instructions before execution.


I think that some of the compressed VM's (RAMDoubler?) end up
achieving much the same result.


Many people on Unix systems which charge for storage but not for time
(e.g., Netcom!) set up little shell scripts for large executables that
uncompress them each time they use them.


If you _know_ that you will be running in a compressed VM system, you
can arrange things to compress more easily (more compactly), and much
of the 'ad hoc' byte encodings may make things worse than a completely
straight-forward encoding.


With such a compressed VM and 'car/cdr-coded' lists of the sort that
were used by some of the Xerox Lisp machines, I think that a
more-or-less vanilla Lisp interpreter running on explicit lists could
be very compact.


--
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
--

Return to the comp.compilers page.
Search the comp.compilers archives again.