Feuerstein, moteur de jeu d'échecs de Fritz Grau

Bonjour tout le monde !

Il existe une multitude de moteurs d'échecs écrits en Pascal, dont certains qui sont très, très forts (comme Booot).

Feuerstein est un de mes préférés. Il joue très bien (sans être un monstre comme le précédent). Il est même capable de jouer à une variante (Crazyhouse), et pour cette variante il accepte les deux protocoles CECP et UCI. En à peine un millier de lignes ! 8-)

Au départ, c'est un programme Delphi. Je l'ai légèrement retouché pour le compiler avec Free Pascal et supprimer la dépendance à l'unité Windows. J'ai fait aussi une petite correction (qui m'a été indiquée ici) pour permettre la compilation 64 bits.

Resterait éventuellement 1° à adapter les parties en assembleur (pour qu'on puisse les activer aussi dans la version 64 bits), et 2° à vérifier que le programme peut toujours être compilé avec Delphi. Contributions bienvenues ! ;)

Le programme est là : (* https://codeberg.org/rchastain/feuerstein *)

Salut

Pour le ASM 64 bits :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

procedure Schiebe; ASM ; Version 64 bits PUSH RBX ; Sauvegarde RBX (registre 64 bits) MOV RBX, RDX ; RBX = RDX (registres 64 bits)   @Anfang: ADD AL, BL ; Addition 8 bits (inchangé) TEST AL, 136 ; Test 8 bits (inchangé) JNZ @Ende ; Saut conditionnel (inchangé)   PUSH RAX ; Sauvegarde RAX (registre 64 bits) CALL Setze ; Appel de fonction (inchangé) POP RAX ; Restauration RAX (registre 64 bits)   MOV RCX, qword ptr [PL] ; Chargement d'une adresse 64 bits CMP byte ptr [RCX+RAX+Lage.Br], 0 ; Comparaison avec offset 64 bits JZ @Anfang ; Saut conditionnel (inchangé)   @Ende: POP RBX ; Restauration RBX (registre 64 bits) END;

---

Principales modifications pour la version 64 bits :

Registres étendus : EBX → RBX, EDX → RDX, EAX → RAX, ECX → RCX
Opérations sur les registres bas : AL et BL restent identiques (registres 8 bits)
Adressage mémoire : La ligne MOV ECX, PL devient MOV RCX, qword ptr [PL] pour charger une adresse 64 bits
Calcul d'adresse : [RCX+RAX+Lage.Br] utilise maintenant des registres 64 bits pour l'adressage

Code:

---

1 2 3 4 5 6 7 8 9

PROCEDURE TestSetze(Ziel: Integer); ASM ADD RAX, qword ptr [Quell] // Addition avec valeur 64 bits TEST AL, 136 // Test sur le registre bas (inchangé) JNZ @Ende // Saut conditionnel (inchangé) CALL Setze // Appel de procédure (inchangé) @Ende: // Label de fin END;

---

Modifications principales pour 64 bits :

Registre étendu : EAX → RAX (registre 64 bits)
Accès mémoire : ADD EAX, Quell → ADD RAX, qword ptr [Quell]

Utilise un pointeur 64 bits pour accéder à la variable Quell
qword ptr spécifie explicitement un accès 64 bits

Opérations inchangées :
TEST AL, 136 : reste identique (opération sur 8 bits)
JNZ @Ende : saut conditionnel inchangé
CALL Setze : appel de procédure inchangé

Notes importantes :
Le paramètre Ziel: Integer reste un entier 32 bits en Pascal
En 64 bits, RAX est automatiquement le registre de retour/paramètre principal
La variable Quell doit être accessible dans la portée de la procédure
La procédure Setze doit également être adaptée pour 64 bits si nécessaire

Code:

---

1 2 3 4 5 6

FUNCTION Entnimm(VAR S: String): String; ASM MOV RCX, RDX // Copie du pointeur/paramètre 64 bits XOR RDX, RDX // Mise à zéro de RDX (64 bits) CALL EntnimmBis // Appel de fonction (inchangé) END;FUNCTION Entnimm(VAR S: String): String;

---

Modifications pour la version 64 bits :

Registres étendus : ECX → RCX (registre 64 bits) EDX → RDX (registre 64 bits)
Convention d'appel 64 bits :
RCX et RDX sont les premiers registres de paramètres en convention Win64
MOV RCX, RDX copie le deuxième paramètre vers le premier
XOR RDX, RDX remet à zéro le deuxième paramètre

Gestion des chaînes :
En 64 bits, les pointeurs de chaînes sont des adresses 64 bits
Le paramètre VAR S: String est passé par référence (pointeur 64 bits)
La valeur de retour String utilise également des pointeurs 64 bits

Points importants :
L'instruction CALL EntnimmBis reste identique
La fonction EntnimmBis doit également être adaptée pour 64 bits
Les conventions d'appel 64 bits peuvent différer selon le compilateur (Win64, SysV, etc.)
La gestion mémoire des chaînes Pascal utilise désormais des adresses 64 bits

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

PROCEDURE Setze(Ziel: Integer); ASM MOV RDX, Z // RDX := adresse de Z (directe) MOVSXD RAX, EAX // Étendre Ziel de 32 à 64 bits ADD RDX, RAX // RDX := @(Z^[Ziel])   MOV RCX, RAX // RCX := Ziel (64 bits) SHL RCX, 3 // RCX := Ziel * 8 ADD RCX, Q // RCX := @(Q^[Ziel])   MOVZX RAX, byte ptr [RDX] // RAX := Z^[Ziel] (extension zéro) ADD RCX, RAX // Inc(RCX, Z^[Ziel])   MOV AL, byte ptr [Quell] // AL := Quell   CMP byte ptr [Setzen], 0 // Comparer Setzen avec 0 JZ @negativ   // Branche positive MOV byte ptr [RCX], AL // Q^[Ziel, Z^[Ziel]] := Quell INC byte ptr [RDX] // Inc(Z^[Ziel]) INC dword ptr [Beweg] // Inc(Beweg) RET   @negativ: DEC byte ptr [RDX] // Dec(Z^[Ziel]) DEC dword ptr [Beweg] // Dec(Beweg) MOV AH, byte ptr [RCX-1] // AH := Q^[Ziel, Z^[Ziel]]   @Finde: DEC RCX // Décrémenter pointeur 64 bits CMP byte ptr [RCX], AL // Comparer avec AL JNE @Finde // Continuer si différent MOV byte ptr [RCX], AH // Remplacer par AH END;

---

Extension de registres :
MOVSXD RAX, EAX : étend le paramètre Ziel (32 bits) vers 64 bits avec extension de signe
Tous les registres principaux utilisent maintenant la version 64 bits (RAX, RCX, RDX)

Calcul d'adresses :
SHL RCX, 3 : multiplication par 8 pour l'adressage 64 bits (au lieu de 4 en 32 bits)
Les opérations de pointeur utilisent des registres 64 bits

Opérations sur bytes :
Les opérations sur AL, AH et les accès byte ptr restent identiques
La logique de recherche dans @Finde est préservée

Points importants :
La logique algorithmique reste identique
Les tableaux Z et Q sont maintenant adressés avec des pointeurs 64 bits
La boucle de recherche @Finde fonctionne avec des adresses 64 bits

J'ai essayé de maintenir la logique de manipulation des paramètres tout en utilisant l'architecture 64 bits.

@anapurna

Merci beaucoup.

J'ai incorporé ton code et vais faire des essais.

Un détail. Je n'ai pas compris pourquoi la fonction EntnimmBis doit être modifiée.

@anapurna

La version ASM 64 bits fonctionne parfaitement. 8-)

Je suis en train de faire des essais avec l'option Lernen activée. Je suis curieux de voir si le jeu du moteur s'améliore vraiment avec le temps.

Salut

La fonction EntnimmBis doit être en 64 bits (ce qui est le cas si tu compiles en 64 bits).
Ce que je voulais dire c'est que selon le compilateur, il faut que tu inclues des options de compilation du genre {$IFDEF COMP64}...{$ELSE}{IFDEF COMP32} ...{$END}...{$END}.

Bonjour,

J'ai regardé le code, mais n'étant pas sous Linux cela me limite.

Cependant, j'ai remarqué que les codes Assembleur sont de simples allitérations d'un code Pascal bien écrit. Je doute donc que ces portions Assembleur apportent un réel gain de performances. En effet, quand le codage Assembleur consiste seulement à faire le travail du compilateur, autant laisser ce dernier faire le job.

Ce serait différent si des instructions spéciales comme les opérations de haut niveau telles bsr, bsf, popcnt ou des instructions vectorielles étaient mises à contribution.
Mais ce n'est pas le cas, et même l'entrelacement de code qui favorise le "out of order" n'est pas utilisé. De plus, l'option de suppression de cadre de pile n'est apparemment pas activée, ce qui induit des empilages et dépilages cachés et inutiles.

Je conseillerais donc de vérifier que ce code Assembleur apporte réellement quelque chose. Si ce n'est pas le cas, le supprimer.

Salutations

Citation:

---

Envoyé par Guesset

Je conseillerais donc de vérifier que ce code assembleur apporte réellement quelque chose. Si ce n'est pas le cas, le supprimer.

---

Merci d'avoir regardé et merci pour cet avis intéressant.

Ne connaissant rien à l'Assembleur, je ne peux évaluer la chose que de façon empirique. Les essais que j'ai faits jusqu'à présent semblent montrer un léger avantage pour les versions avec Assembleur, mais c'est peut-être un hasard.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

438 game(s) loaded, 0 game(s) with unknown result ignored. Rank Name Elo + - games score oppo. draws 1 GreKo 2021.10 330 306 180 12 92% -27 0% 2 CT800 1.12 114 167 147 12 71% -27 25% 3 Uralochka 1.1d RC 49 158 146 12 63% -27 25% 4 King Slayer 24 93 90 36 57% -27 19% 5 Feuerstein 0.4.6.1 RC 0.3 64-bit LERNEN 21 47 46 128 57% -29 32% 6 Feuerstein 0.4.6.1 RC 0.3 32-bit LERNEN 3 46 46 128 54% -27 32% 7 Feuerstein 0.4.6.1 RC 0.3 32-bit ASM -18 46 46 128 51% -23 31% 8 Feuerstein 0.4.6.1 RC 0.3 64-bit ASM -28 47 47 128 49% -21 27% 9 Feuerstein 0.4.6.1 RC 0.3 32-bit -46 47 47 128 46% -18 29% 10 Feuerstein 0.4.6.1 RC 0.3 64-bit -91 48 49 128 39% -10 20% 11 Stash 13.0.1 -111 106 113 24 38% -27 25% 12 Sjaak II 1.4.1 -246 158 203 12 21% -27 8%

---

Pareil pour les versions compilées avec le switch {$DEFINE Lernen} : je ne sais pas si elles sont vraiment plus fortes comme les résultats ci-dessus en donnent l'impression. En tout cas elles fonctionnent...

Citation:

---

Envoyé par Guesset

J'ai regardé le code, mais n'étant pas sous Linux cela me limite.

---

Le programme compile sous Windows. Il n'y a que le Makefile qui n'était pas adapté, mais entre-temps je l'ai mis à jour.

@anapurna

La fonction EntnimmBis est en Pascal... Je n'y vois rien de spécifique à une architecture. :koi:

Le respect que j'ai pour l'auteur me retient, mais j'ai bien envie de passer un coup de formateur dans ce programme. D'ailleurs, j'ai fait un essai : ça me paraît beaucoup plus lisible après qu'avant. :?

Je viens de corriger deux fuites de mémoire. Il en reste une que n'arrive pas à identifier...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

$ ./feuerstein64 quit Heap dump by heaptrc unit of /home/roland/Documents/pascal/echecs/feuerstein/feuerstein64 11 memory blocks allocated : 34932174/34932184 10 memory blocks freed : 34932145/34932152 1 unfreed memory blocks : 29 True heap size : 393216 True free heap : 392960 Should be : 392992 Call trace for block $00007FBCC68B6500 size 29 $0000000000401604 ENTNIMM, line 145 of Feuerstein0461.dpr $000000000040B0A0 KONTAKT, line 1319 of Feuerstein0461.dpr $00000000004010F5 WARTEN, line 80 of Feuerstein0461.dpr $000000000040A555 RECHNERZUG, line 1208 of Feuerstein0461.dpr $000000000040B70F main, line 1403 of Feuerstein0461.dpr

---

P.-S. Trouvé !

Code:

---

1 2 3 4 5 6 7 8 9 10 11

IF Kommando[1] = 'q' {quit} THEN BEGIN {$IFDEF Log} CloseFile(Log); {$ENDIF} Finalize(Befehl); // <-- Finalize(Kommando); // <-- Finalize(S); // <-- Finalize(T); // <-- {Halt}Halt2; END;

---

Quel peut être l'intérêt d'après vous de transtyper GetTickCount en Integer ? (Sachant qu'au départ, c'était GetTickCount. C'est moi qui l'ai remplacé par GetTickCount64.)

Code:

---

Urzeit := Integer(GetTickCount64);

---

Salut

En regardant le dernier source, tu as fais de toi-même les différents types de définition (CPU64).
Pour ma part, ma phrase n'est qu'un rappel. Par ailleurs, il y a le même avertissement sur l'autre méthode.
Ton source ne doit prendre la version 64 bits de L'asm que si et seulement si sa compilation est en 64bits.
Il n'y a rien de plus à comprendre.

Bonjour Roland,

Citation:

---

Envoyé par Roland Chastain

Le respect que j'ai pour l'auteur me retient, mais j'ai bien envie de passer un coup de formateur dans ce programme. D'ailleurs, j'ai fait un essai : ça me paraît beaucoup plus lisible après qu'avant. :?

---

Je partage ton avis plus justifié encore sur le code en assembleur déjà naturellement peu lisible qui devient très pénible avec des instructions à la queue-leu-leu. Je n'ai pas pu résister à le mettre un peu en forme et je vois que Anapurna présente un code assembleur également plus lisible.

Je présume que le tableau permet de comparer les performances mais je ne le comprends pas vraiment.

Je suis étonné que le code assembleur compile sous Windows et Linux sans changement. Je croyais que l'empilage des arguments était différent (peut être sommes-nous sauvés par l'usage systématique de la pile ?)

Salut

Bonjour Roland,

Citation:

---

Envoyé par Roland Chastain

Quel peut être l'intérêt d'après vous de transtyper GetTickCount en Integer ? (Sachant qu'au départ, c'était GetTickCount. C'est moi qui l'ai remplacé par GetTickCount64.)

Code:

---

Urzeit := Integer(GetTickCount64);

---

---

Ce n'est pas très joli de mettre un 64 bits dans un 32 bits, mais les problèmes ne se poseront qu'après plus de 49 jours de fonctionnement ininterrompu.

Salut

@anapurna

Vu, merci pour la confirmation.

Citation:

---

Envoyé par Guesset

Je présume que le tableau permet de comparer les performances mais je ne le comprends pas vraiment.

---

Ce sont les résultats d'un tournoi entre plusieurs « moteurs » (nombre de parties jouées, estimation du nombre de points ELO gagnés ou perdus, entre autres).

Citation:

---

Envoyé par Guesset

Je suis étonné que le code assembleur compile sous Windows et Linux sans changement. Je croyais que l'empilage des arguments était différent (peut être sommes-nous sauvés par l'usage systématique de la pile ?)

---

Aucune idée !

Salut

A priori il n'y a pas beaucoup de différences entre les deux.

Voir ici.

À la demande générale, le code a été formaté (pour le moment, dans une branche séparée).

P.-S. Branche fusionnée avec la branche principale.

Bonjour,

Quand je vois le code suivant, je me demande ce qu'il y a dans RAX car on ne peut faire une hypothèse fiable sur sa valeur initiale.

Code:

---

1 2 3 4 5 6 7 8

PROCEDURE TestSetze(Ziel: Integer); ASM ADD RAX, qword ptr [Quell] // Addition avec valeur 64 bits TEST AL, 136 // Test sur le registre bas (inchangé) JNZ @Ende // Saut conditionnel (inchangé) CALL Setze // Appel de procédure (inchangé) @Ende: // Label de fin END;

---

En 32 bits sous Windows, ce serait eax = Ziel. Si c'est bien le cas, la transcription sous Windows 64 bits serait ADD RCX, qword ptr [Quell] et (sans garantie :oops:) ADD RDI, qword ptr [Quell] sous Linux 64. Et bien sûr, le test porterait sur CL sous Windows 64, mais sur DI sous Linux 64.
Ajout : Quell est un integer, il n'y a donc pas de raison de charger un 64 bits. Sous Windows 64, la procédure devient :

Code:

---

1 2 3 4 5 6 7 8

PROCEDURE TestSetze(Ziel: Integer); ASM ADD ECX, dword ptr [Quell] // Addition avec valeur 32 bits TEST CL, 136 // Test sur le registre bas (inchangé) JNZ @Ende // Saut conditionnel (inchangé) CALL Setze // Appel de procédure (inchangé) @Ende: // Label de fin END;

---

Cet autre code interroge également :

Code:

---

1 2 3 4 5 6

FUNCTION Entnimm(VAR S: String): String; ASM MOV RCX, RDX // Copie du pointeur/paramètre 64 bits XOR RDX, RDX // Mise à zéro de RDX (64 bits) CALL EntnimmBis // Appel de fonction (inchangé) END;

---

Anapurna fait bien remarquer que MOV RCX, RDX copie le deuxième paramètre vers le premier. Mais il n'y a pas de second paramètre :roll:. Donc là aussi, il y a une hypothèse hasardeuse sur le contenu initial de RDX à moins que cela vienne d'un codage ATT qui aurait du être transformé en MOV RDX, RCX pour passer en Intel car les sens source-destination sont inversés.

Ces points illustrent que la compilation avec l'option ASM ne donnera pas le même résultat (mauvais :D) sous les deux OS : RCX = @S sous Windows mais c'est RDI (sauf erreur) sous Linux.

Tout cela m'incite à réitérer le conseil de retirer l'ASM.

Salutations

Citation:

---

Envoyé par Guesset

Tout cela m'incite à réitérer le conseil de retirer l'ASM.

---

Merci. Conseil suivi. 8-)

Salut.

Je n'ai fait que traduire en 64 bits la version 32 sans aucune vérification.

Pour la fonction TestSetze il aurait fallu faire un truc du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

PROCEDURE TestSetze(Ziel: Integer); ASM // Ziel est déjà dans EAX (convention d'appel 32 bits) // En 64 bits, Ziel serait dans ECX, donc on le déplace vers EAX MOV EAX, ECX // EAX := Ziel (paramètre 64 bits -> 32 bits) ADD EAX, dword ptr [Quell] // EAX := Ziel + Quell (addition 32 bits) TEST AL, 136 // Test AL AND 136 (registre bas) JNZ @Ende // Si résultat <> 0, aller à @Ende CALL Setze // Sinon appeler Setze(EAX) @Ende: // Label de fin END;

---

Citation:

---

Envoyé par Guesset

Bonjour,
Cet autre code interroge également :

Code:

---

1 2 3 4 5 6

FUNCTION Entnimm(VAR S: String): String; ASM MOV RCX, RDX // Copie du pointeur/paramètre 64 bits XOR RDX, RDX // Mise à zéro de RDX (64 bits) CALL EntnimmBis // Appel de fonction (inchangé) END;

---

Anapurna fait bien remarquer que MOV RCX, RDX copie le deuxième paramètre vers le premier. Mais il n'y a pas de second paramètre :roll:. Donc là aussi, il y a une hypothèse hasardeuse sur le contenu initial de RDX à moins que cela vienne d'un codage ATT qui aurait du être transformé en MOV RDX, RCX pour passer en Intel car les sens source-destination sont inversés.

---

On aurait aussi pu la traduire comme cela :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

FUNCTION Entnimm(VAR S: String): String; VAR EmptyStr: String; BEGIN EmptyStr := ''; ASM MOV RCX, S // 1er paramètre: S MOV RDX, EmptyStr // 2ème paramètre: chaîne vide CALL EntnimmBis // Le résultat sera dans Result automatiquement END; END;

---

Mais comme le dit Guesset, je ne suis pas certain du gain et donc le conseil de retirer l'ASM n'est pas si farfelu.