Re: [gnugo-devel] new cache

[Dave Denholm]

Paul Pogonyshev <address@hidden> writes:

> Wolfgang Manner wrote:
> > i dont know how your linux box treats longlong. it still may be faster
> > to compare by yourself word 1 and if it disagrees: break
> > instead of comparing two longlong words
> > wolfgang
> 
> i'm not sure about other architectures than x86, but the latter simply
> cannot compare two 64-bit values in one operation.  in other word, on
> x86 `long long' is an abstraction - it is supported by compiler (gcc),
> not processor itself.  i'd guess that this is true for all 32-bit
> processors.
> 
> so it doesn't matter much what we use: `long long' or two `int's.  in
> terms of machine code on x86 (all 32-bit architectures).  but i would
> suggest two `int's simply because it's absolutely portable.
> 


Without having followed the discussion (so not knowing if you are talking
about time critical code), I'd say why not use long long
since there are already 64-bit processors around (sparc, alpha) and
intel can't be that far from going mainstream. If it makes no difference
on 32-bit architectures, why not choose the one that is better on
64-bit architectures.

I would have thought that gcc should be able to generate psuedo-64-bit
operations at least as efficiently as they can be hand-coded out of
two ints.


(rather than doing a branch after one comparison, it might be
 more efficient to OR together the two comparisons... best just
 to trust the compiler to do its job...)


BTW if you want a 64-bit integer, I'd recommend type-defing something
rather than assuming long long is 64 bit.

I think the pattern matcher once had a typedef for a 32-bit integer,
and did a compile-time assertion that it was exactly 32 bits.


dd
-- 
Dave Denholm              <address@hidden>       http://www.esmertec.com