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
|