Re: bigint/bugnum library
- Posted by jimcbrown (admin) Jul 13, 2013
- 1752 views
Right, on 32bit it's largely a non-issue. But on 64bit platforms, we need a floating point type that's bigger than the integer type, as stuff inside the interpreter and runtime library make this assumption, and though it's possible to rewrite the insides to avoid this, it'd probably mean a lot of Euphoria code would also need to be rewritten.
The real portability/compatibility problem comes from 32 vs 64 bit integers, instead of defining Euphoria integers as definitely one or the other.
I agree that this is a real portability/compatibility problem.
THAT's where the biggest incompatibility will be.
The way 4.1 is right now, I would agree. If we allow atoms to be smaller than integers, then I believe that this would become a bigger incompatibility - and having both would certainly make things no easier for anyone.
If we say that Euphoria integers are AT LEAST 64 bits (a performance issue only on 32-bit machines) then we should be okay.
Hmm. I confess that I really like the idea of having 64bit sized integers and 80bit atoms on 32bit 4.1 Euphoria. (Though this combination is not possible on ARM without some software emulation, as you pointed out.)
But if we say that integers are 32 or 53 bits on 32 bit machines, but 63 bits or 64 bits on a 64 bit machine, then we may have problems.
Future code can be ifdef'd to deal with this when necessary. I guess the big issue is porting existing code.
Aside from math libraries and low level code (e.g. the interface to C libraries), I was hoping that most code wouldn't care about the underlying size of an integer or an atom. But I can see this come back to bite us when we least expect it...
