Am 09.06.2011 19:44, schrieb Andrew Coppin:
On 09/06/2011 06:54 AM, Scott Lawrence wrote:
On 06/09/2011 01:47 AM, Jason Dagit wrote:
Have you checked this by looking at the generated assembly? I generated some assembly from GHC on windows. Here is what it looks ilke: http://hpaste.org/47610
My assembly-fu is not strong enough to tell if it's using 64bit instructions.
It would appear to be 32-bit. (pushl instead of pushq& no instances of aligning to 8-byte boundaries)
The general register naming scheme on x86 is:
AL, AH: 8 bits AX: 16 bits EAX: 32 bits RAX: 64 bits
There's a lot of code there, but from what I can see, it's all operating on 32-bit registers. So I'd say this is 32-bit code.
On the other hand, I still think it would be worth actually benchmarking this stuff to see how much difference it makes. Wouldn't surprise me if the CPU designers did some clever trickery with pipelining and superscalar execution to make two adjacent 32-bit instructions execute the same way as a single 64-bit instruction would...
(I've seen various sources claim that running software in 64-bit mode only gives you a 2% speedup. Then again, they presumably aren't testing with chess software which heavily utilises explicit 64-bit operations.)
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe For a chess engine this is for sure not true. I guess that this is one of very few domains where it really matters! The most (basic) operations with bitboards are anding, oring, xoring, shifting and (for magic bitboards) multiplying 64 bits values. When using 32 bits you need for some of these more then double time to achieve the same.
I was wondering if there is a possibility to support 64 bit native codes without other stuff (calling conventions, win64 specific system calls etc). This could be perhaps a first step to full 64 bit support. But from the code of ghc I could not understand what this would mean. Nicu