Author: José Carlos
Date: 07:35:07 12/10/02
Go up one level in this thread
On December 10, 2002 at 07:48:56, Gerd Isenberg wrote:
>>************************************************************************
>>
>> if (pPos->u64TorresN)
>> {
>> UINT64 u64Pieza = pPos->u64PeonesN;
>> UINT64 u64Vacias = BB_TABLEROLLENO;
>>
>> u64Pieza |= (u64Pieza >> 8) & u64Vacias;
>> u64Vacias &= (u64Vacias >> 8);
>> u64Pieza |= (u64Pieza >> 16) & u64Vacias;
>> u64Vacias &= (u64Vacias >> 16);
>> u64Pieza |= (u64Pieza >> 32) & u64Vacias;
>> fprintf(pFLog,"--- PI: %I64u\n",u64Pieza);
>> u64Pieza = u64Pieza >> 8;
>>
>> u64ColumnasAbiertas = u64Pieza;
>> fprintf(pFLog,"--- CA: %I64u\n",u64ColumnasAbiertas);
>> u64ColumnasAbiertas = ~u64ColumnasAbiertas;
>> fprintf(pFLog,"--- CA: %I64u\n",u64ColumnasAbiertas);
>> u64ColumnasAbiertas &= au64FrontalReyBlanco[u32CasillaRey];
>> fprintf(pFLog,"+++ CA: %I64u\n",u64ColumnasAbiertas);
>> }
>>
><snip>
>
>Hi José,
>
>that's strange. No idea so far.
>The problem seems to be the final shift right:
>
> u64Pieza = u64Pieza >> 8;
>
>Have you tried printf before and after that statement?
>Have you played with the optimization flags?
>Have you tried this one:
>
> u64Pieza >>= 8;
>
>or this one:
>
> u64Pieza /= 256;
Hi Gerd,
yep, I tried all those hacks. No one made a difference.
>May be a bug in the compilers 64bit shift intrinsics?
>What kind of compiler do you use exactly (Service Pack?).
MSVC 6, latest service pack (5 IIRC, I don't know for sure because I'm not at
home now) and processor pack.
>Can you post the assembler output of the release and debug version.
Got it at home.
The problem is that, when I copied that piece of code into a small project, it
worked perfectly no matter what optimizations I enabled.
It only fails inside the big program. I compiled that module without
optimizatios and the asm output was crytal clear, with the assebly code for
every C line. It worked. Then I enabled "global optimization" (/Og) and then the
asm was a big mess. It created an assembly code section for about 30 C lines or
so, and I couldn't understand what it was doing. So I gave up. If you think you
could understand it, I can post it here tonight when I get home.
Other optimizations like /Ox also generated messy (and wrong) asm.
>If nothings helps, you may try intel C++.
I only have MSVC, because that's the one we use at work. I think there's an
evaluation version of Intel C++. If so, I'll try it later on.
>I don't guess a side effect from
> fprintf(pFLog,"--- PI: %I64u\n",u64Pieza);
>but may be you try
> fprintf(pFLog,"--- PI: %04X%04X\n",
> (unsigned int)(u64Pieza>>32),
> (unsigned int)u64Pieza );
The fprintf was there only for seeing what was happening, but it didn't do
anything else. The code fails without the fprintf. The code fails with the
printf where I put it in my post. But if I post it one line earlier, the code
works. Sure the compiler is "optimizing" that temp result, and the printf causes
it to not "optimize".
>Cheers,
>Gerd
Thanks,
José C.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.