>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.

In theory this is great, but in practice I don't see how it can work. 
If you are going to use only the low 8 to 15 bits, it might work, but 
I don't see any real savings in speed deriving from that experiment. 
If you are going to use between 15 to 30 bits (SmallInteger only has 
30 bits for positive numbers), then you will have to deal, directly 
or indirectly with overflows for your multiplication operations, 
perhaps by breaking it up into pieces and shifting and stuff (slowing 
it back down), or using an underlying LargeInteger operation to fill 
in (same thing).

I think building a plugin instead, particularly because a great deal 
of the existing code in the image can be appropriated (the preamble 
code needs fixing, but the rest probably can be made to work) is 
probably not too difficult, certainly for the innermost loops.  A 
profile shows that for reasonably large numbers 90-98% is presently 
spent inside the innermost routines.

Thus, a plugin could in theory be built (without too much sweat) that 
wouldn't slow up the status quo much at all, and would run much 
faster with a plugin installed.

I believe that at the time Smalltalk-80 blue book was written, there 
probably wasn't much real need for big number computations, and the 
thing cranked just fine for the usual baby examples.  But crypto may 
be the "killer need" for good, fast, built-ins.  Particularly if we 
can make this seamlessly pluggable for more speed, perhaps this is a 
worthwhile project.

But we don't need to wait for CS, certainly for the simple 
undertaking to pluginize inner code for the private longInt routines 
for Number, if only to take the profiles to see if that is enough to 
make a real difference.

Of course, we could just write pluggable primitive code for each 
primitive directly (since they presently all just fail right now) 
without meaningful cost (although it would likely require some 
fiddling with Number and some of the coercion code to make 
SmallInteger + Large---Integer work fast.  But why do all that just 
now?