LargeInteger is broken

[GoogleCodeExporter]

Introducing some basic strongtalk maths: 

1'836'311'903 + 2'971'215'073 = 512'559'681

or maybe not.

I found it while i was toying around, running some smalltalk code (which is
basically a translation of a ruby snippet i read), and wondering if it
would work with large integers flawlessly (i'm afraid it does not)

|x| x := 0 ,, 1.
1 to: 50 do: [ :i | "too lazy to write timesRepeat: ..."
  Transcript print: x at2; cr.
  x := x at2 ,, (x at1 + x at2)
].

i ran this with the compiler off btw (not that it matters, LargeIntegers 
are dealt with by primitives anyway)

[ot ps: when is the wiki going to appear ? wasn't it "Real Soon Now" last
month ? :)]

Original issue reported on code.google.com by [email protected] on 2 Apr 2007 at 7:02

[GoogleCodeExporter]

Original comment by [email protected] on 26 Apr 2007 at 4:46

• Changed state: Accepted

[GoogleCodeExporter]

Fixed.
Carry propagation was broken in the assembly code.

I fixed the problem when i converted the bignum code to C for better compiler
portability.

note: LargeInteger>>test doesn't test for carry propagation, and there's no 
code for
long/negative division. 

Overall this bignum implementation is quite weak, and given the VM performance, 
i
think it should be written in smalltalk, like Self bignums. What do you think ?

It would make good testing material for 32/64/128 bit primitives and escape
analysis/stack allocation (Which i'm interressed in implementing)

Original comment by [email protected] on 29 Apr 2007 at 11:07

[GoogleCodeExporter]

Take a look at IntegerOps::unsigned_cmp for a really obvious bug. The 
LargeInteger
primitves are really broken ...

Original comment by [email protected] on 6 Aug 2007 at 6:21