On Wed, Apr 25, 2007 at 09:48:55AM -0700, Andreas Raab wrote:
Hi David -
Looking over your changes I see two consistent patterns: One is to change all oops from sqInt to usqInt and the other one is to use the "special" unsigned comparison for pointers. Is my interpretation essentially correct?
Yes, exactly so.
There are only two real issues that I could see:
1) oop comparisons need to be done with unsigned values.
2) unwanted sign extension in pointerForOop() when the machine address size is 8 bytes and object memory word size is 4 bytes.
All oop arithmetic (e.g. adding to an oop) works fine regardless of signed or unsigned declarations. As an aside, whomever came up with the idea of twos compliment arithmetic deserves great credit for Doing Things Right In The First Place.
I thought that adding the four "special" comparison methods was somewhat less ugly than putting the casts into each impacted method throughout ObjectMemory and Interpreter. It also allowed me to add some method comments to explain why it was being done.
A related issue: It bothers me greatly how complex all of this stuff has become. The whole 32/64bit conversion (oopForPointer: etc) and now pointer comparisons (no longer using < or >) makes me wonder of how sustainable this is. Even I can't recall all the rules that have to be followed to write clean 32/64/2GB barrier code. I wish we had a way of getting back to a set of simpler rules... any ideas anyone? The one idea that I can think of immediately would be to support types in slang better and have a specific slang compiler which can (for example) catch signed/unsigned comparisons when you write them.
In my opinion, it is entirely sustainable. Assuming that my changes actually do something useful (which remains to be seen), I can say that it really did not take a great deal of time to do this. What did take some time is understanding the issues and figuring out how to deal with them without breaking the slang inliner. Putting these changes in place serves to document my understanding of the problem (again, assuming that I actually did understand it). In principle that should improve maintainability.
I'm open for any suggestions on how to improve this situation.
Two ideas:
1) If we could declare the return type of a method and still generate inlined code, then it would probably be possible to eliminate most of the type casting, and therefore also eliminate the four "special" comparison methods that implement the type casting.
2) It may be possible to write the conversion macros (oopForPointer: etc) in slang in such a way that they would be inlined in the generated code. If so, that would make the conversions considerably less opaque.
Dave