Would anyone like to contribute to a chess engine in FASM? I currently have the basic framework of a bitboard engine and GUI working in FASM.

The engine follows the uci protocol (http://wbec-ridderkerk.nl/html/UCIProtocol.html) and currently plays at about 1800 ELO (http://www.computerchess.org.uk/ccrl/404/). It analyzes ~3 million positions per second with one 2.5GHz laptop core and a simulated PEXT and PDEP. I expect the native PEXT and PDEP of haswell to give good speed boost but haven't tested it on haswell yet.

The engine has LOTS of room for improvement.

If we can make it strong enough (~2500ELO), it could compete in tcec (http://tcec.chessdom.com/).

The engine follows the uci protocol - if you want to use it you can use a well known gui like arena.

How does a chess engine work? Does it find all combinations of X turns ahead and score them based on best/worst outcome to select the next move for the player? Are there lists or databases of terrible moves that are thrown out immediately? Seems like opening moves are pretty well hashed out in the chess world does the engine always use teh same openings or is it more non-deterministic?

r22, It depends on the specific chess engine. Most important is move generation and move make/unmake combined with some search algorithm. Move ordering is important in alpha-beta search. Strong chess programs use better evaluations of the leaf nodes, transposition tables, move ordering heuristics, search tree pruning heuristics,...

So by "bitboard" do you mean storing an empty(0)/occupied(1) board state in a 64bit register 8x8 and then the actual pieces in a dynamic LUT ([0..63] -> piece identifier)? I can see how this would be optimal and why you might want to take advantage of the new PEXT and PDEP opcodes.

If you had a knight at bit position 1 (b1) you could easily check all of it's possible moves with a mask that TESTed bit positions 16 (a3), 18 (c3) and 11 (d2). Cool stuff.

Using this (possibly imaginary) construct you'd have a node structure something like.

r22, I think you get it. My current structures are actually given below. There is great redudancy in the first 64*3 bytes of STATE, but it nice to have a .BOARD that you can look the piece on a given square and bit boards (i.e. .WKNIGHTS), where you can lookup the squares that are occupied by a given piece. For example, BPIECES = BPAWNS | BKNIGHTS | BBISHOPS | BROOKS | BQUEENS | BKING should always hold. Make the opening move e2e4 will involve xoring WPIECES and WPAWNS with (1 shl SQUARE_E2 + 1 shl SQUARE_E4) and making the move on the 64 byte STATE.BOARD. Since making a move (and generating moves) is so quick, I just store a list of pseudolegal moves between [.MOVES_START] and [.MOVES_END]. This way, you only need to store the nodes that are parents of your current node, not the whole tree.

Beyond the obvious win/lose checks, how do you score potential moves? Also what are the time/move and memory constraints of these competitive engines? If a memory constraint is imposed you'd want a more compressed state structure.

And... you have a flag for 'castling' but none for 'en passant'

For en passant I use a bitboard EPSQUARE since there is a 8 byte hole after the white pieces and nothing to fill it. Now that I think about it, I could put EPSQUARE as a byte in the hole after CASTLING and move the bitboard CHECKERS to the current EPSQUARE location. That should still preserve the identity property for the first 64*3 bytes .


chess evaluation is an art form in itself... At minimum, you should take the difference of the material scores (WMSCORE-BMSCORE), and have a term for mobility. King safety is quite tricky but improves the engine's play.


The time constraints are determined by the match conditions. Engines should be able to search 3-4 moves deep and produce an adequate move within a milisecond. The best open source program searches to 30-40 moves deep in a couple of minutes. As for the memory constraints, these are generally determined by the size of the hash table. I've seen anthing from 1MB to 16GB for the hash table.


As I said before, the size of the STATE structure does not matter. I do not store the whole search tree in memory - only the list of parents from the root to the current child node is stored. The hash table is what holds information about each node in the search tree, and it is the hash entries should of course be compressed as much as possible. The large STATE strucutre is for fast move making and move generation.

If I get the code cleaned up soon, I'll post an example engine.

Seems the two major factors for an engine are the speed at which you can generate move permutations and the quality of your scoring heuristics.

Move generation can easily be optimized all the way to the opcode level, but choosing the correct move seems like it would take great insight into chess to begin with. Perhaps a genetic algorithm or neural network could be trained to do the best job at that.

yeah - most of the factors that make a chess program strong are algorithmic and not dependent on pedal-to-the-medal opcode optimizations. But it should still be fun anyways

[ Post removed by author. ]

perpetual development

posted an engine

[ Post removed by author. ]

Haha, if you want to port something, try my updated version at https://github.com/tthsqe12/asm
If you can make a working linux version ill include it in the master.

Very good code, tthsqe.

Thinking about getting a 64BIT PC soon (ASrock ITX Quad MB+CPU = $75, InWin Developer case = $50, 2G memory = $20). So, I can test your examples.

Haha, I was serious about the linux port. See if you can can translate the functions in Windows.asm on my repo into linux syscalls. It would be really cool if you did. Also, Ill be adding a windows ches gui for uci engines to the repo soon.

[ Post removed by author. ]

it might be more difficult than i orginally though.
the pthread functions in stockfish are here
https://github.com/official-stockfish/Stockfish/blob/master/src/platform.h#L61
and for example, i found an implementation of one of the functions at
http://fossies.org/dox/glibc-2.20/pthread__mutex__init_8c_source.html

it is futex in the kernel, then most pthread things are built upon that
there are bout man 2 and 7 pages about it and plenty of docs online

PS musl is a much simpler library
http://git.musl-libc.org/cgit/musl/tree/src/thread

m3ntal, kudos to you if you can make an inexpensive windows box. I just added a gui to my repo, so you can play against the engine and other engines as well. Let me know if something doesn't work on your box.