Crafty 23.6 on ARM problems

[Max]

I'm trying to compile Crafty 23.6 on a Samsung ARM Chromebook running Ubuntu 13.04 with gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3, but faced this issues.

- SMP support seems to be asm-optimized for x86:

Code: Select all

user@localhost:~/Downloads/src/crafty236$ make arm
make target=LINUX \
		CC=gcc CXX=g++ \
		CFLAGS=' -w -O2' \
		CXFLAGS=' -w -O2' \
		LDFLAGS=' -lpthread' \
		opt=' -DCPUS=4' \
		crafty-make
make[1]: Entering directory `/home/user/Downloads/src/crafty236'
make[2]: Entering directory `/home/user/Downloads/src/crafty236'
gcc -w -O2 -DCPUS=4 -DLINUX -c crafty.c
In file included from chess.h:99:0,
                 from search.c:1,
                 from crafty.c:13:
thread.c: In function ‘ThreadStop’:
lock.h:64:3: error: impossible constraint in ‘asm’
lock.h:81:3: error: impossible constraint in ‘asm’
make[2]: *** [crafty.o] Error 1
make[2]: Leaving directory `/home/user/Downloads/src/crafty236'
make[1]: *** [crafty-make] Error 2
make[1]: Leaving directory `/home/user/Downloads/src/crafty236'
make: *** [arm] Error 2
user@localhost:~/Downloads/src/crafty236$

- Crafty 23.6 compiles without threads, but terminates at runtime on ARM:

Code: Select all

user@localhost:~/Downloads/src/crafty236$ make arm
make target=LINUX \
		CC=gcc CXX=g++ \
		CFLAGS=' -w -O2' \
		CXFLAGS=' -w -O2' \
		LDFLAGS='' \
		opt='' \
		crafty-make
make[1]: Entering directory `/home/user/Downloads/src/crafty236'
make[2]: Entering directory `/home/user/Downloads/src/crafty236'
gcc -w -O2  -DLINUX -c crafty.c
g++ -c -w -O2  -DLINUX egtb.cpp
gcc -o crafty crafty.o egtb.o  -lm  
make[2]: Leaving directory `/home/user/Downloads/src/crafty236'
make[1]: Leaving directory `/home/user/Downloads/src/crafty236'

user@localhost:~/Downloads/src/crafty236$ ./crafty 
unable to open book file [./book.bin].
book is disabled
unable to open book file [./books.bin].

Crafty v23.6 (1 cpus)

White(1): go
ERROR white occupied squares is bad!
- - - - - - - -     X X X X X X X X 
- - - - - - - -     X X X X X X X X 
- - - - - - - -     - - - - - - - - 
- - - - - - - -     - - - - - - - - 
- - - - - - - -     - - - - - - - - 
- - - - - - - -     - - - - - - - - 
X X X X X X X X     X X X X X X X X 
X X X X X X X X     X X X X X X X X 
ERROR  material evaluation is wrong, good=4150, bad=44435
ERROR!  bitboards/board[48] don't agree!
ERROR!  board[48]=255, should be 0
ERROR!  board[49]=255, should be 0
ERROR!  board[50]=255, should be 0
ERROR!  board[51]=255, should be 0
ERROR!  board[52]=255, should be 0
ERROR!  board[53]=255, should be 0
ERROR!  board[54]=255, should be 0
ERROR!  board[55]=255, should be 0
ERROR!  board[56]=252, should be 0
ERROR!  board[57]=254, should be 0
ERROR!  board[58]=253, should be 0
ERROR!  board[59]=251, should be 0
ERROR!  board[60]=250, should be 0
ERROR!  board[61]=253, should be 0
ERROR!  board[62]=254, should be 0
ERROR!  board[63]=252, should be 0
processor id: cpu-0
current move:
move=  piece=0, from=0, to=0, captured=0, promote=0

       +---+---+---+---+---+---+---+---+
    8  |RQK|np*PNBRQK*12345678/|kqrbnp*PNBRQK*12345678/| PNBRQK||kqrbnp*PNBRQK*12345678/|np*PNBRQK*12345678/|RQK|
       +---+---+---+---+---+---+---+---+
    7  |NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|
       +---+---+---+---+---+---+---+---+
    6  |   | . |   | . |   | . |   | . |
       +---+---+---+---+---+---+---+---+
    5  | . |   | . |   | . |   | . |   |
       +---+---+---+---+---+---+---+---+
    4  |   | . |   | . |   | . |   | . |
       +---+---+---+---+---+---+---+---+
    3  | . |   | . |   | . |   | . |   |
       +---+---+---+---+---+---+---+---+
    2  |-P-|-P-|-P-|-P-|-P-|-P-|-P-|-P-|
       +---+---+---+---+---+---+---+---+
    1  |-R-|-N-|-B-|-Q-|-K-|-B-|-N-|-R-|
       +---+---+---+---+---+---+---+---+
         a   b   c   d   e   f   g   h

called from Main(1), ply=0
node=0
active path:
user@localhost:~/Downloads/src/crafty236$

Got the same problems with Crafty 23.5, but version 23.4 runs fine (with one thread) on my ARM-box. Any ideas?

Thanks,
Max

[bob]

I'm trying to compile Crafty 23.6 on a Samsung ARM Chromebook running Ubuntu 13.04 with gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3, but faced this issues.

- SMP support seems to be asm-optimized for x86:

Code: Select all

user@localhost:~/Downloads/src/crafty236$ make arm
make target=LINUX \
		CC=gcc CXX=g++ \
		CFLAGS=' -w -O2' \
		CXFLAGS=' -w -O2' \
		LDFLAGS=' -lpthread' \
		opt=' -DCPUS=4' \
		crafty-make
make[1]: Entering directory `/home/user/Downloads/src/crafty236'
make[2]: Entering directory `/home/user/Downloads/src/crafty236'
gcc -w -O2 -DCPUS=4 -DLINUX -c crafty.c
In file included from chess.h:99:0,
                 from search.c:1,
                 from crafty.c:13:
thread.c: In function ‘ThreadStop’:
lock.h:64:3: error: impossible constraint in ‘asm’
lock.h:81:3: error: impossible constraint in ‘asm’
make[2]: *** [crafty.o] Error 1
make[2]: Leaving directory `/home/user/Downloads/src/crafty236'
make[1]: *** [crafty-make] Error 2
make[1]: Leaving directory `/home/user/Downloads/src/crafty236'
make: *** [arm] Error 2
user@localhost:~/Downloads/src/crafty236$

- Crafty 23.6 compiles without threads, but terminates at runtime on ARM:

Code: Select all

user@localhost:~/Downloads/src/crafty236$ make arm
make target=LINUX \
		CC=gcc CXX=g++ \
		CFLAGS=' -w -O2' \
		CXFLAGS=' -w -O2' \
		LDFLAGS='' \
		opt='' \
		crafty-make
make[1]: Entering directory `/home/user/Downloads/src/crafty236'
make[2]: Entering directory `/home/user/Downloads/src/crafty236'
gcc -w -O2  -DLINUX -c crafty.c
g++ -c -w -O2  -DLINUX egtb.cpp
gcc -o crafty crafty.o egtb.o  -lm  
make[2]: Leaving directory `/home/user/Downloads/src/crafty236'
make[1]: Leaving directory `/home/user/Downloads/src/crafty236'

user@localhost:~/Downloads/src/crafty236$ ./crafty 
unable to open book file [./book.bin].
book is disabled
unable to open book file [./books.bin].

Crafty v23.6 (1 cpus)

White(1): go
ERROR white occupied squares is bad!
- - - - - - - -     X X X X X X X X 
- - - - - - - -     X X X X X X X X 
- - - - - - - -     - - - - - - - - 
- - - - - - - -     - - - - - - - - 
- - - - - - - -     - - - - - - - - 
- - - - - - - -     - - - - - - - - 
X X X X X X X X     X X X X X X X X 
X X X X X X X X     X X X X X X X X 
ERROR  material evaluation is wrong, good=4150, bad=44435
ERROR!  bitboards/board[48] don't agree!
ERROR!  board[48]=255, should be 0
ERROR!  board[49]=255, should be 0
ERROR!  board[50]=255, should be 0
ERROR!  board[51]=255, should be 0
ERROR!  board[52]=255, should be 0
ERROR!  board[53]=255, should be 0
ERROR!  board[54]=255, should be 0
ERROR!  board[55]=255, should be 0
ERROR!  board[56]=252, should be 0
ERROR!  board[57]=254, should be 0
ERROR!  board[58]=253, should be 0
ERROR!  board[59]=251, should be 0
ERROR!  board[60]=250, should be 0
ERROR!  board[61]=253, should be 0
ERROR!  board[62]=254, should be 0
ERROR!  board[63]=252, should be 0
processor id: cpu-0
current move:
move=  piece=0, from=0, to=0, captured=0, promote=0

       +---+---+---+---+---+---+---+---+
    8  |RQK|np*PNBRQK*12345678/|kqrbnp*PNBRQK*12345678/| PNBRQK||kqrbnp*PNBRQK*12345678/|np*PNBRQK*12345678/|RQK|
       +---+---+---+---+---+---+---+---+
    7  |NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|NBRQK*12345678/|
       +---+---+---+---+---+---+---+---+
    6  |   | . |   | . |   | . |   | . |
       +---+---+---+---+---+---+---+---+
    5  | . |   | . |   | . |   | . |   |
       +---+---+---+---+---+---+---+---+
    4  |   | . |   | . |   | . |   | . |
       +---+---+---+---+---+---+---+---+
    3  | . |   | . |   | . |   | . |   |
       +---+---+---+---+---+---+---+---+
    2  |-P-|-P-|-P-|-P-|-P-|-P-|-P-|-P-|
       +---+---+---+---+---+---+---+---+
    1  |-R-|-N-|-B-|-Q-|-K-|-B-|-N-|-R-|
       +---+---+---+---+---+---+---+---+
         a   b   c   d   e   f   g   h

called from Main(1), ply=0
node=0
active path:
user@localhost:~/Downloads/src/crafty236$

Got the same problems with Crafty 23.5, but version 23.4 runs fine (with one thread) on my ARM-box. Any ideas?

Thanks,
Max

I'll take a look, but this is unusual. Almost looks like a "char x" defaults to unsigned, where every compiler / system I have used defaults to signed. If this is true, you might do a global search and replace (file=chess.h) and replace " char " with " signed char ".

ugh..

[Max]

Thanks for looking into.

BTW, Crafty 23.6 compiled with gcc 4.6.3 on this ARM-system running now Ubuntu 12.04 shows exactly the same behaviour and terminates after "go".

Max

[Max]

I have to add, that Crafty 23.4 runs normal only, when compiled with "target=FreeBSD" and without SMP (because of the asm part). Compiled with "target=Linux", version 23.4 crashes like 23.6. But for 23.6 changing the target makes no difference any more. Both executables terminate the same way after go-command.

Here the benchmark result for Crafty 23.4 on the Samsung ARM chromebook

Code: Select all

user@localhost:~/Downloads/src/crafty234$ ./crafty234
unable to open book file [/usr/share/crafty/book.bin].
book is disabled
unable to open book file [/usr/share/crafty/books.bin].
pondering disabled.
Warning--  xboard 'memory' option disabled
hash table memory = 256M bytes (16M entries).
Warning--  xboard 'memory' option disabled
pawn hash table memory = 64M bytes (2M entries).


Crafty v23.4 (1 cpus)

White(1): bench
Running benchmark. . .
......
Total nodes: 286296640
Raw nodes per second: 1050899
Total elapsed time: 272.43
White(1): 

Max

[Jim Ablett]

Hi Max/Bob,

Adding the compiler switch

Code: Select all

 -fsigned-char 

to force char to signed does the trick.

To compile on Arm with thread support you need this in 'lock.h' > (already at bottom of 'lock.h' but not being seen when compling)

Code: Select all

#if defined(__arm__)

#  define LockInit(p)
#  define LockFree(p)
#  define Lock(p)
#  define Unlock(p)
#  define lock_t volatile int

#endif

I also used built-in intrinsics for bitscan (boolean.c) instead of Bob's routines (not necessary but neat) >

Code: Select all

#if defined(BUILTIN_INTRINSICS)

// GCC intrinsics for bitscan and popcount

inline int LSB(uint64_t b) { return __builtin_ffsll(b) - 1; }
inline int MSB(uint64_t b) { return 63 - __builtin_clzll(b); }


int PopCnt(register uint64_t w) {  // '-mpopcnt' to enable gcc hardware support
return __builtin_popcountll(w);
}

#else

Here is a direct link to the android binary (so can be directly installed on a tablet) > https://dl.dropboxusercontent.com/u/504 ... android-ja


A while back Martin Thoresen ask if I could add tb hits display to the pv output. I came up with this little patch. I think it works as required.

Code: Select all

4. To add tb hits to the pv display >
--------------------------------------------------


In 'utility.c'  (DisplayPV/initialize section) change so it looks like this >


------------------------------------------------------------

if (pv->pathh == 2) {
   sprintf(buffer + strlen(buffer), " tb=%d          ", tree->egtb_probes_successful);
  }else{
  sprintf(buffer + strlen(buffer), " tb=%d          ", 0);
  }

  if (pv->pathh == 1)
    sprintf(buffer + strlen(buffer), " <HT>           ");
 
  strcpy(kibitz_text, buffer);

------------------------------------------------------------

Jim.

[Jim Ablett]

Forgot to mention on ARM compilers char is unsigned by default.

Jim.

[bob]

Hi Max/Bob,

Adding the compiler switch

Code: Select all

 -fsigned-char 

to force char to signed does the trick.

To compile on Arm with thread support you need this in 'lock.h' > (already at bottom of 'lock.h' but not being seen when compling)

Code: Select all

#if defined(__arm__)

#  define LockInit(p)
#  define LockFree(p)
#  define Lock(p)
#  define Unlock(p)
#  define lock_t volatile int

#endif

That is going to break thread support completely. Those simply turn the locks into <null> so that no locks are used at all.

I also used built-in intrinsics for bitscan (boolean.c) instead of Bob's routines (not necessary but neat) >

Code: Select all

#if defined(BUILTIN_INTRINSICS)

// GCC intrinsics for bitscan and popcount

inline int LSB(uint64_t b) { return __builtin_ffsll(b) - 1; }
inline int MSB(uint64_t b) { return 63 - __builtin_clzll(b); }


int PopCnt(register uint64_t w) {  // '-mpopcnt' to enable gcc hardware support
return __builtin_popcountll(w);
}

#else

Here is a direct link to the android binary (so can be directly installed on a tablet) > https://dl.dropboxusercontent.com/u/504 ... android-ja


A while back Martin Thoresen ask if I could add tb hits display to the pv output. I came up with this little patch. I think it works as required.

Code: Select all

4. To add tb hits to the pv display >
--------------------------------------------------


In 'utility.c'  (DisplayPV/initialize section) change so it looks like this >


------------------------------------------------------------

if (pv->pathh == 2) {
   sprintf(buffer + strlen(buffer), " tb=%d          ", tree->egtb_probes_successful);
  }else{
  sprintf(buffer + strlen(buffer), " tb=%d          ", 0);
  }

  if (pv->pathh == 1)
    sprintf(buffer + strlen(buffer), " <HT>           ");
 
  strcpy(kibitz_text, buffer);

------------------------------------------------------------

Jim.

[bob]

Forgot to mention on ARM compilers char is unsigned by default.

Jim.

At one point, IBM's AIX systems behaved exactly the same (RS6000 days)... That's how I concluded this was a problem so quickly. Seen it previously.

[sje]

Suggestion: Reduce and centralize assumptions about default character and integer types.

Code: Select all

// Integer types

typedef signed   int           si;
typedef unsigned int           ui;

typedef signed   char          si8;
typedef unsigned char          ui8;

typedef signed   short int     si16;
typedef unsigned short int     ui16;

typedef signed   int           si32;
typedef unsigned int           ui32;

typedef signed   long long int si64;
typedef unsigned long long int ui64;

[hgm]

Forgot to mention on ARM compilers char is unsigned by default.

Jim.

At one point, IBM's AIX systems behaved exactly the same (RS6000 days)... That's how I concluded this was a problem so quickly. Seen it previously.

The C standard does not specify if char is signed char or unsigned char. It explicitly states that this is left to the compiler developer, to pick whatever is most convenient on the platform he is compiling for. (E.g. on a machine that does not support an instruction for signed compare of byte variables, or sign extension from byte to word, signed char would be much slower than unsigned char.)

If you want your code to be portable, you should only use char when you don't care if it is signed or unsigned (e.g. when you know for sure the value will always be in the range 0-127).