Page 10 of 16
Re: gull chess
Posted: Thu Dec 20, 2012 10:48 pm
by User923005
Perhaps you meant this?
#define ExtFlag(ext) (((unsigned) ext) << 16)
#define Ext(flags) ((((unsigned) flags) >> 16) & 0xF)
Re: gull chess
Posted: Thu Dec 20, 2012 11:41 pm
by User923005
You should do this:
typedef struct GProcessInfo {
volatile LONG searching;
volatile LONG flags; // for stop order & fail high signal
GMoveList MoveList[128];
} GProcessInfo;
because with intrin.h and 64 bit compile, LONG can become long long (examine the intrin.h header file and you will see routine versions with x64 name extensions that take long long).
Re: gull chess
Posted: Fri Dec 21, 2012 8:44 am
by ThinkingALot
User923005 wrote:Why do you have HASH_STORE undefined by default?
It activates "learning" (implemented via a "permanent" hash table saved to a file).
User923005 wrote:Perhaps you meant this?
"ext" is supposed to be a nonnegative integer < 8, so no need to make it unsigned.
User923005 wrote:I suggest to examine this:
Thanks!
User923005 wrote:LONG can become long long
And the same for volatile LONG lock in GOptex class?
Re: gull chess
Posted: Fri Dec 21, 2012 9:03 am
by ThinkingALot
User923005 wrote:LONG can become long long
Why use it then (instead of long)? These variables are supposed to be 32-bit integers.
Re: gull chess
Posted: Fri Dec 21, 2012 9:49 am
by User923005
Sometimes.
Consider, for instance this bit from Winbase.h:
#if defined(_WIN64) || ((_WIN32_WINNT >= 0x0502) && defined(_WINBASE_))
FORCEINLINE
unsigned __int64
InterlockedExchange(
__inout __drv_interlocked unsigned __int64 volatile *Target,
__in unsigned __int64 Value
)
{
return (unsigned __int64) InterlockedExchange64((volatile __int64*) Target, (__int64) Value);
}
#endif
If you define them as LONG, they will always become the right thing. If you don't you will get undefined behavior.
It's not crazy. It's Windows. Wait... it is crazy isn't it?
Re: gull chess
Posted: Sat Dec 22, 2012 2:28 am
by User923005
ThinkingALot wrote:
And the same for volatile LONG lock in GOptex class?
Yes.
Make it a SCREAMING long:
Code: Select all
typedef struct GOptex {
volatile LONG lock;
HANDLE semaphore[MaxPrN]; // handles for each process
} GOptex;
I know it looks silly, but what can you do.
It turns out that sometimes LONG will become long long.
It might seem strange, at first, but when I thought about it, it makes sense for Windows environment where long is only 4 bytes and an address is 8 bytes.
That way, a LONG can hold an address reliably, and Windows pulls that cheesy trick all the time. I don't know why they didn't just use actual addresses, but there we are.
Re: gull chess
Posted: Sat Dec 22, 2012 4:30 am
by lucasart
ThinkingALot wrote:User923005 wrote:LONG can become long long
Why use it then (instead of long)? These variables are supposed to be 32-bit integers.
Hello,
Really appreciate your engine Gull. Its code is apparently simple, yet very strong on the ELO scale. And it's certainly not a cheap rip-off from anything else, contrary to what some trolls have said. So a great contribution to the community!
Is there any poroject to make the code portable one day ? It seems that there is a lot of Windows/MSVC dependancy in there that could very easily be avoided. To begin with, how about using only portable types, as defined in <inttypes.h> ?
Re: gull chess
Posted: Sat Dec 22, 2012 5:12 am
by User923005
Since it is an open source project, it would be easy to fork it or to contribute to the existing project.
The oddball stuff is only needed for SMP, so a simple translation layer like so many other chess programs have for threading would do the trick.
Re: gull chess
Posted: Sat Dec 22, 2012 5:17 am
by User923005
lucasart wrote:ThinkingALot wrote:User923005 wrote:LONG can become long long
Why use it then (instead of long)? These variables are supposed to be 32-bit integers.
Hello,
Really appreciate your engine Gull. Its code is apparently simple, yet very strong on the ELO scale. And it's certainly not a cheap rip-off from anything else, contrary to what some trolls have said. So a great contribution to the community!
Is there any poroject to make the code portable one day ? It seems that there is a lot of Windows/MSVC dependancy in there that could very easily be avoided. To begin with, how about using only portable types, as defined in <inttypes.h> ?
Thinkingalot is a good example, as far as giving credit where credit is due. From his readme:
"A derivative of Gull 1.2 (program structure, board representation, move generators etc.) & Ivanhoe (versions 63 & 46: evaluation).
Whether future versions will retain Ivanhoe's evaluation is still undecided."
Re: gull chess
Posted: Sat Dec 22, 2012 5:28 am
by lucasart
User923005 wrote:Since it is an open source project, it would be easy to fork it or to contribute to the existing project.
The oddball stuff is only needed for SMP, so a simple translation layer like so many other chess programs have for threading would do the trick.
Yes, but the entire code is riddled with unportable things, in place where it is neither necessary nor useful (__int64 to begin with). And for SMP, there is absolutely no need to write unportable code. C++11 has all one needs to write it clean, portable, safe and simple code. In the C++11 branch of Stockfish, Marco demonstrates that fact with "maestria".