On Mon 30 Nov, Eliot & Linda wrote:
>  Have you copied the "encode short methods with SmallIntegers"
> idea from VisualWorks?  You should; (e.g. go measure the impact); we
> wouldn't mind.
Yup, I thought about that; I remembered it as yet another of those sneaky
ideas LPD taught me way back when. Trouble is, it's actually quite a tricky
thing to fit into the sq code without bigger changes than I could convince
myself to make just yet. Mostly it complicates the  activating of contexts
a bit.
Also, if I measured correctly, it would save only about 40kb or so. There's
something like 790 methods with no bytecodes I think. If the new format is
accepted for the future, I think it might be worth some rethinking, as it's
possible Ian's next run at the vm might make it less costly.
Another thing that keeps knocking gently at the back of my mind (with
accompanying hollow thuds) is the thought that we now have bunch of spare
bits in the method header that could do double duty for flagging some
common prim-failure cases (like 'self primitiveFailed' for example) and
thus allow nil bytecodes, which might be simpler still.

> Who is this Eliot idiot anyway?
Oh, he's just zis guy, y'know? :-)

Dwight just pointed out to me that the changes file zip was faulty - I've
replaced it and it seems to work for me, so hopefully it will be better
this time.  Just for easiness for anyone wanting to build the vm for
mac/unix/nintendo/whatever, I've also put a copy of the interp.c in the
directory http://sumeru.stanford.EDU/tim/pooters/SqFiles/deltas/

I do have one other potentially useful tweak worth considering - another
old idea, but still a good one, that of primitive error returncodes going
into a special temp var. It needs a tiny VM tweak forsupport, and a
recompile of any method calling a prim, but you get to return meaningful
information for the failure code to use, rather than guessing. I'll try to
package it tomorrow.

Unlike with the little endian bitblt, I'm not going to try and push this
stuff; if people want to use it, let's say so and do it, otherwise I'll
save my time for building airplanes. Since the 2.3 needs a new vm anyway,
and the source/changes files have got rather big, how about doing a big
cleanup, changing method format, clean out the split instvar numbering,
condense the sources and feel better for Solstice? Sort of make it all
squeaky clean :-) Oh yeah, all the non-essential prims should lose their
numbers and be named.

tim


-- 
Plan to be spontaneous tomorrow.
Tim Rowledge:  rowledge at interval.com (w)  +1 (650) 842-6110 (w)
 tim at sumeru.stanford.edu (h)  <http://sumeru.stanford.edu/tim>