Moderators: hgm, Rebel, chrisw
Code: Select all
// Assertions
Assert(sizeof(CTByte) == 1);
Assert(sizeof(CTSByte) == 1);
Assert(sizeof(CTWord) == 2);
Assert(sizeof(CTSWord) == 2);
Assert(sizeof(CTDwrd) == 4);
Assert(sizeof(CTSDwrd) == 4);
Assert(sizeof(CTQwrd) == 8);
Assert(sizeof(CTSQwrd) == 8);
Yes, it is. I made yet another stupid mistake and copied the above code after I had fixed the bug. I had "typedef unsigned long uint32", and a "long", as you certainly know, is a 64-bit int on some systems (not on mine, though). I hope it makes sense now.Gerd Isenberg wrote:I think it is of general interest to post about such bugs here!Tord Romstad wrote:In the end, it turned out not to be a compiler error, but yet another stupid programmer error. It turned out that I had the following type declaration:hgm wrote:Well, then I would say this definitely is a compiler error.Which is of course incorrect when using GCC in 64-bit Linux!Code: Select all
typedef unsigned int uint32;
I really should learn to use GNU Autoconf and Automake in order to handle this kind of issues, instead of bothering this group with all my stupid questions.
Tord
And I still don't get it. What was wrong with the typedef?
Isn't sizeof(int) == 4 with your compiler?
He he he!Tord Romstad wrote: Yes, it is. I made yet another stupid mistake and copied the above code after I had fixed the bug. I had "typedef unsigned long uint32", and a "long", as you certainly know, is a 64-bit int on some systems (not on mine, though). I hope it makes sense now.
I apologize for the confusion.
Tord
Code: Select all
void UCIInputParser::skip_whitespace() {
while(isspace(this->inputLine[this->currentIndex]))
this->currentIndex++;
}
This is what vc2005 makes out of Tord's routine with 32*32-bit mul, shift right 26. It looses precision (as intended). The intermediate product is still 32-bit. I think this is specified by C and is not caused by compiler's ability to understand the semantic of the routinebob wrote:actually if you multiply two 32 bit ints, you get a 64 bit result. Always has been this way. But if you don't follow that with a divide, which also has a 64 bit dividend, then you lose the extra bits. This has been a hardware feature to prevent problems with things like
a = b * c / d;
if it was all done in 32 bits, you would need to know the actual values for a, b and c before producing the assembly language to execute the operations. the 64 bit multiply result (on 32 bit machines) nicely side-steps this issue. If it were not for this, you couldn't multiply two values where each might be more than 16 bits wide...
Code: Select all
static const int BitTable[64] = {
63, 30, 3, 32, 25, 41, 22, 33, 15, 50, 42, 13, 11, 53, 19, 34, 61, 29, 2,
51, 21, 43, 45, 10, 18, 47, 1, 54, 9, 57, 0, 35, 62, 31, 40, 4, 49, 5, 52,
26, 60, 6, 23, 44, 46, 27, 56, 16, 7, 39, 48, 24, 59, 14, 12, 55, 38, 28,
58, 20, 37, 17, 36, 8
};
Square pop_1st_bit(Bitboard *b) {
Bitboard bb = *b ^ (*b - 1);
uint32 fold = int(bb) ^ int(bb >> 32);
*b &= (*b - 1);
return Square(BitTable[(fold * 0x783a9b23) >> 26]);
}
b$ = 8
?pop_1st_bit@@YAHPEA_K@Z PROC
00000 48 8b 01 mov rax, QWORD PTR [rcx]
00003 48 8d 50 ff lea rdx, QWORD PTR [rax-1]
00007 4c 8b c2 mov r8, rdx
0000a 48 23 d0 and rdx, rax
0000d 4c 33 c0 xor r8, rax
00010 48 89 11 mov QWORD PTR [rcx], rdx
00013 48 8d 0d 00 00
00 00 lea rcx, OFFSET FLAT:BitTable
0001a 49 8b c0 mov rax, r8
0001d 48 c1 e8 20 shr rax, 32
00021 41 33 c0 xor eax, r8d
00024 69 c0 23 9b 3a
78 imul eax, 783a9b23H
0002a 48 c1 e8 1a shr rax, 26
0002e 8b 04 81 mov eax, DWORD PTR [rcx+rax*4]
00031 c3 ret 0
?pop_1st_bit@@YAHPEA_K@Z ENDP
Code: Select all
return Square(BitTable[fold * 0x783a9b23 / 0x04000000]);
Code: Select all
int32 a, b;
((int 64) a) * ((int64) b);
Code: Select all
int64 c; int32 d;
(int32) (c /d);
Code: Select all
a = (int32) ( ((int64) a) * ((int64) b) / d);
Actually, what I was quoting came from an old FORTRAN test. Where the compiler was smart enough to do the 2*32 bit multiply, and follow it up with the 64 bit divide, and then check for overflow after the divide. code looked like this (assuming a = b * c / d)hgm wrote:Indeed, I don't think Bob is right. He is right about that hardware allows you to do obtain double-length products and use double-length dividends, but the C standard forbids the compiler to make use of this hardware feature. int32*int32 should give you int32 with the high-order 32-bits clipped. If you loses high-order bits because of that, it is called integer overflow.
There is no C operator that directly uses the hardware feature of double-precision integer multiply/divide, just like there is no operator to use rotate or rotate-through-carry instructions. (The latter might be supplied as intrinsics.)
For multiplication you could use the expressionto force a 64-bit result, in the hope that the optimizer recognizes that it is not really needed to extend the precision of the factors before multiplication, but that it could use the 32x32->64 instruction. For division, you could inform the compiler tat you are not interested in the high-order 32-bit of the quotient by casting it to 32-bit:Code: Select all
int32 a, b; ((int 64) a) * ((int64) b);So to get the effect that Bob wants one should writeCode: Select all
int64 c; int32 d; (int32) (c /d);and hope for a smart optimizer. In 64-bit mode you could double all the lengths.Code: Select all
a = (int32) ( ((int64) a) * ((int64) b) / d);
Code: Select all
mov eax, b
imul c
idiv d
jo overflow
mov a, eax