# Concerning Time.TimeDiff

**Alastair Reid
**
alastair@reid-consulting-uk.ltd.uk

*Thu, 19 Jun 2003 16:51:08 +0100*

On Thursday 19 June 2003 2:59 pm, Ketil Z. Malde wrote:
>* What about CPUs with only native 32bit support,
*
All you need to implement arbitrary sized N-bit arithmetic is a CPU which
provides 'add with carry', 'subtract with carry', etc. All CPUs I have every
used provide these operations and I think it's a safe bet that all future
CPUs will provide them.
>* What about computers with a >64 bit native type?
*
Processors which provide 2*N*8-bit arithmetic sometimes provide N*8-bit
arithmetic too (e.g., 32-bit processors sometimes provide 16 bit arithmetic
too) so, if their native type is a power of 2 times 64, we should be ok.
For any other processors, we can implement it the way 8 and 16-bit arithmetic
is currently implemented on Hugs: we coerce the operands to 32 bits, perform
the 32-bit operation and coerce the operands back to the desired result size.
Coercing up takes, at most, a register-register move and coercing down takes
an and operation.
>* ...and I don't think it's entirely given that two 64 bit numbers will
*>* be faster than one Integer.
*
I do. the implementation of Integer requires traversing additional
indirections to an array of bits, reading the size of the operands,
allocating space for the result, etc. It's a lot of work even if the
arguments and result are simple values like 0 or 1.
I suspect Integer could be optimized (by recognizing that most uses of Integer
are for values that fit in 31 bits) so that the difference is pretty minimal.
but this would have limited effect on a date like 19 June 2003 which is (very
roughly) 2^69 picoseconds since the epoch.
Which is all to say that whatever sound reasons may exist, future portability
concerns or performance are not reasons to prefer using a single Integer or a
Rational.
--
Alastair Reid