> >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.
>
> Perhaps 16 bits, but unlikely 32.  How, for example, would you handle
> integer overflow when doing, say, the LargeInteger add?

My first idea was to take one small and one big C-integer type, represent
digits with the small and perform the operations with the bigger one. If the
bigger one is twice as big as the smaller there are no problems with mult.
I think on all machines with ANSI-C these conditions are met; at _least_ we
could take an 8 bit val for representation and make the computation in 16
bit, at best - so far - representation in 32 and computation in 64.
But here we introduce platform specific stuff, which has to be handled. By
using the Smalltalk to C compiler without changing the current
representation we are _totally_ platform independent (no #defines in C at
all) and in spite of this hopefully much faster than without compiling in C.

>  And how
> could you do the multiply without bit munging?  Is it possible that a
> straight loop with carry would be much faster than all the masking
> and shifting necessary to do a carry written in C?
>

That could be, but then you'd introduce assembler, what is _very_ platform
dependent.


Because I've never compiled a Squeak so far I think it's best for me first
to take the straigthforward approach and then to think of other
representations...


Stephan