Concerning Time.TimeDiff

[Alastair Reid]

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