At 08:10 PM 10/24/98 -0500, Dwight Hughes wrote:
>... I do *not* like the idea of spending a lot of time and effort
>building tools directly on top of compiled methods. This ties a
>non-negligible amount of the image to a specific bytecode set and
>representation and could create considerable inertia to moving to new VM
>representations, new bytecode sets, native compilation,... if a lot of
>this must be recreated.

I too would prefer minimizing dependencies on the current bytecode set.
I've had a couple of alternative bytecode sets in mind for years. It might
be nice to actually try them on a complete Smalltalk system like Squeak.

For example, you could huffman compress the current bytecodes. As the
frequency of use is not at all even, the most common bytecodes could take
only a few bits. Huffman compressed bytecode dispatching for an interpreter
would not be much slower than for current bytecodes. You basically just do
a table jump on some chunk of the bitcode stream. Redundant entries in the
jump table essentially do the huffman decode as part of the table jump.
Additional bytecode data could also be of optimal length, instead of being
forced to a multiple of 8 bits. My guess is you could get significant
compression of a Smalltalk image with this kind of bytecode set. For
certain uses, size is rather important.

- Jan

___________________________________________________________________
            Paradigm Matrix Inc., San Ramon California
   "video products and development services for Win32 platforms"
Internet: Jan Bottorff janb at pmatrix.com
          WWW          http://www.pmatrix.com
Phone: voice  (925) 803-9318
       fax    (925) 803-9397
PGP: public key  <http://www-swiss.ai.mit.edu/~bal/pks-toplev.html>
     fingerprint  52 CB FF 60 91 25 F9 44  6F 87 23 C9 AB 5D 05 F6
___________________________________________________________________