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.
Why not to use primitives? There are some free numbers (20-39) for this purpose and if it's faster then everybody will want it. And I don't see any image or sources size problem for these additions.
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.
I wanted to know if anybody just works on this additions to avoid superfluous work and to strenghten my motivation!
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?
My opinion: - it's worthable for many people because doing that improves fundamental data types; - I see a chance for me to be successful in not so long time; - I'm learning much about calling C-routines from Squeak, what can be useful for more specialized purposes, too.
Stephan