[Vm-dev] gcc -Wall -pedantic (was: sweep failed to find exact
end of memory)
David T. Lewis
lewis at mail.msen.com
Wed Apr 25 21:23:13 UTC 2007
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
> I'm open for any suggestions on how to improve this situation.
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.
More information about the Vm-dev