[PicForth] compact object code ?

[easlab at absamail.co.za]

There's been some talk here about 'minimum sizing the obj code'...

I came across: ---------- start of extract ---------

   Newsgroups: comp.compilers,comp.lang.misc
   From: Chris F Clark <c... at shell01.TheWorld.com>
   Date: 30 Dec 2004 01:05:45 -0500
   Subject: Re: virtual machine efficiency

   > I have developed a simple stack based virtual machine. I would like
   > it to be as efficient as possible, in terms of both speed and object
   > code size. Size, as in size of the object code the VM processes
   > (byte-code), and not necessarily the size of the VM.
> ... <alignment problem>....

a... at mips.complang.tuwien.ac.at (Anton Ertl) replied:
 <plenty of references> ...
    annote =         "Interpreter performance is optimized by combining
                     operators during code generation, when they are
                     still organized as trees. So a different, optimized
                     interpreter
                     is used for each program. Speedups of 1.8--3.1 are
                     achieved, but this is probably strongly dependent on
                     the original set of operators. The paper uses lccs
                  intermediate code operators \cite{fraser&hanson91a}."
...
    abstract =         {Embedded systems often have severe memory
                    constraints requiring careful encoding of
                    programs. For example, smart cards have on the order
                    of 1K of RAM, 16K of non-volatile memory, and 24K of
                    ROM. A virtual machine can be an effective approach
                    to obtain compact programs but instructions are
                    commonly encoded using one byte for the opcode and
                    multiple bytes for the operands, which can be
                    wasteful and thus limit the size of programs
                    runnable on embedded systems. Our approach uses
                    canonical Huffman codes to generate compact opcodes
                    with custom-sized operand fields and with a virtual
                    machine that directly executes this compact code. We
                    present techniques to automatically generate the new
                    instruction formats and the decoder. In effect, this
                    automatically creates both an instruction set for a
                    customized virtual machine and an implementation of
                    that machine. We demonstrate that, without prior
                    decompression, fast decoding of these virtual
                    compressed instructions is feasible. Through
                    experiments on Scheme and Java, we demonstrate the
                    speed of these decoders. Java benchmarks show an
                    average execution slowdown of 9%. Compression
                    factors highly depend on the original bytecode and
                    the training sample, but typically vary from 30% to
                    60%. }
--- end of extracts ---

The point is:
  picforth is 'based' on gforth  [probably a very good idea],
and gforth is written/maintained by the above author: Anton Ertl.

And I'm guessing that Anton Ertl is a top specialist is 'code compaction'.
So you/we've come a full circle.

Best try to learn/copy from those who've done the research already ?

== Chris Glur.