more emperical results from my hacks..

Alan Grimes alangrimes at starpower.net
Wed Apr 7 03:18:45 UTC 2004


Not being able to stay away from hacking the VM even to do my homework, 
I went and tried a few more permutations of my design... I got some 
really wierd results when I tried to get too clever... (the trashcan 
turning yellow and stuff..)

I ended up writing it to only accept short-ints and fail on everything 
else. This version worked stunningly well on shorts, ofcourse, and 
didn't do too horribly bad on longs either.

I went to investigate exactly how longs were being processed to see if I 
could goose them a little. I was stunned and ammazed by the results... I 
found a whole boatload of wierdness...

So here are some more peanut-galary comments about the interpreter:

1. Functions to control platform specific features such as power 
managment, sound IO, and some interfaces to the 3D accelerator are _IN_ 
the VM ***BUT*** primitives to process basic data structures such as 
float arrays and large integers are not...

Furthermore the Large Integer Plugin seems to be very stale. The code in 
the LargeIntegerPlugin seemed content to process a 64 bit int on a 64 
bit platform with a loop that processed 1 byte at a time!!! I have not 
really looked at it yet, I just discovered it this evening.

It tried to write a version of BitAnd etc... to process anything that 
could be thrown at it with one function. That effort showed that any 
solution that my meager skills colud write would be very awkward and 
slow... I think the best approach would be to simply attempt to do a 
small-int -- small-int  operation then put, as the first operation of 
the failue code, to simply swap the order of the first two items on the 
stack and re-attempt the same selector. That should have the effect of 
triggering the code that is more specialized for large ints... Large 
ints, in turn, would be rewritten to use different bytecodes by default. 
In my test image I simply deleted the stubs for the bit operations from 
the long int types, it works just fine and not terrably slow.

2. I have come across some downright silly code...

In Object memory there are a number of global variables such as:

"fooObj" which are constants assigned to some value say 6,

Then there is a method barObj which is written:

barObj
    ^ self  splObj: fooObj.

Finally, throughout the rest of the interpreter the constant fooObj is 
_ALWAYS_ used with the call self splObj but the method barObj is NEVER 
used.

I went through and deleted all such constants, put their values in the 
appropriate method and then replace all the calls to splObj with calls 
to their appropriate method...

In all, my changes to date have shrunk interp.c by 10% (or 60kb!!!)

My runtimes are pretty bad right now but I expected that, my purpose is 
to clean up as much as possible then look at making it work better.

3. It is annoying trying to keep the generated sources in sync with 
./Cross/vm/sqVirtualMachine.h  It would be much more convenient if the 
compiler generated the appropriate headers too. For example the compiler 
already writes prototypes for all functions.  It would make more sense 
to be able to declare some, as public by a method similar to the one 
used to control the inliner and the compiler would simply emit these to 
the common header which would save me alot of work cuz 
sqVirtualMachine.h seems very stale to me, I have already identified a 
number of problems and annoyances with it...



More information about the Squeak-dev mailing list