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@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 ___________________________________________________________________