Something I've casually looked at is making LargeIntegers just be arrays of SmallIntegers. This way you leverage the SmallInteger primitives and should gain considerable performance -- even with a Smalltalk only implementation (a primitive or two might be desireable to make the shift from SmallIntegers to LargeIntegers and back more graceful). This approach has actually been used in the past in some Lisps (don't know if any still do this). One thing you could do is to simply make negation of a LargeInteger be the negation of each of its SmallInteger components -- which should allow combining LargePositiveInteger and LargeNegativeInteger into a single LargeInteger class, along with a few other nice side effects.
IMO, it just seems like a good first step to try before diving into creating the LargeInteger primitives, and should give good insight into handling larger "digits".
-- Dwight
Stephan Rudlof wrote:
Dear Squeakers,
I have changed my mind a little bit after studying some Squeak sources.
Now I plan to implement LargeInteger primitives (20-39) _without_ changing the representation of LargeIntegers by extending the Interpreter arithmetic primitives using the CCodeGenerator. This avoids some problems dealing with different platforms.
In a later step changing the representation to bigger 'digits' (16,32,.. bits?) _could_ be interesting.
What do you think?