gull chess

[User923005]

Perhaps you meant this?
#define ExtFlag(ext) (((unsigned) ext) << 16)
#define Ext(flags) ((((unsigned) flags) >> 16) & 0xF)

[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).

[ThinkingALot]

Why do you have HASH_STORE undefined by default?

It activates "learning" (implemented via a "permanent" hash table saved to a file).

Perhaps you meant this?

"ext" is supposed to be a nonnegative integer < 8, so no need to make it unsigned.

I suggest to examine this:

Thanks!

LONG can become long long

And the same for volatile LONG lock in GOptex class?

[ThinkingALot]

LONG can become long long

Why use it then (instead of long)? These variables are supposed to be 32-bit integers.

[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?

[User923005]

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.

[lucasart]

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> ?

[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.

[User923005]

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."

[lucasart]

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".