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

Absolutely correct concerning image and source space.  And primitive 
number space is not an issue.  We are talking VM footprint.  Right 
now, others are pluginizing many existing VM primitives so as to 
reduce space, not because they are not useful, but because not 
everyone uses them all the time and VM size seems a concern for some 
applications.

Is it so clear that everyone will want to make the space-speed 
tradeoff that a VM change would require?  For many long integer 
performance is satisfactory, and even impressive.  (My only uses were 
to compute certain odds for my daughter relating to her Pokemon card 
game, lottery odds and the occasional "factorial" demo, and of 
course, behind the scenes intermediate computations from SmallInts 
that I hadn't noticed when doing 32-bit operations)

Footprint of the VM on PDA's is precious for some.  Doing it as a 
plugin (almost the same mechanism, by the way) permits those who want 
it to plugin and those who don't to pass.

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

I had actually done this for addition (by far the easiest operation) 
when testing the new plugin compiler.  If I can find it, I'd be happy 
to send it along.

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

Speed performance only -- functionality should remain identical. 
There is a need for more speed only for certain applications (like 
crypto).

>- I see a chance for me to be successful in not so long time;

True of both approaches.  (I believe that you will find the plugin 
route a faster path.)

>- I'm learning much about calling C-routines from Squeak, what can be useful
>for more specialized purposes, too.

Also true of both approaches.