VM h4x0r!ng Ctd.

Alan Grimes alangrimes at starpower.net
Sun Apr 4 20:53:47 UTC 2004


om,

I havn't been able to stay away from hacking on the VM. While my changes 
are of questionable benefit in some cases I still think I'm making 
progress towards preparing to refactor it into a paralellizable 
configuration.

I'm currently working on two issues:

1. cleaning up the basic bitwise operations.
2. working on Jim's request for a 64-bit compatible VM for Opterons, 
IA32+ and G5s...
(I'd really like to see what the K8's extra registers can do for the 
benchmark results.)


1. The current bitwise operations fail under either of the following 
conditions:
-- A negative number is passed.
-- An operand is longer than 32 bits is passed.

Also, in the case of any LongPositiveInteger, the VM will do an endian 
conversion on the operand before each operation. =\

My proposal, in keeping with the design patterns currently in use, is to 
change the above so that it will first detect the length of the operands 
to see that they are compatible then check their length. If they are 
32-bits then it will do it normally, otherwise it will coerce them to 
int64_t; and let the compiler figure out how to do the operation.

The assumption being it would be safe to pass back a 
largePositiveInteger regardless of the sign of the operands...


On the second front, there are two issues with implementing the changes 
I outlined the other night...
1. The image loader needs to be reconfigured to use relative addressing
2. The use of a base pointer is OK on 64-bit platforms because A. you 
need to, and B. 64-bit platforms have enough registers to use it 
efficiently. However, using a base-index system on 32-bit platforms 
would be a major pessimization... =\

What strategies would the people who actually know something about these 
issues suggest for cleanly switching between the two modes as appropriate?



More information about the Squeak-dev mailing list