Schach für ARM Cortex

Nochmals: Schach für Arm Cortex, nicht für Windows!

mit solch einer Frage sind offenbar einige hier schwer 
unterfordert...wie so oft..wird aus einer einzigen EINFACHEN Frage eine 
etliche Stunden laufende Diskussion..der nächste fragt dich gleich was 
Du denn damit willst..der nächste kommt damit das Du deine Anforderungen 
nicht klar ausgedrückt hast etc pp.
Ein Trauerspiel....

ach ja, und zum Schluss sagen sie, das Du vermutlich nur ein Troll bist 
und rumtrollen willst...das übliche eben

Mit Angabe des Wunsch MCU kann man auch suchen:

https://duckduckgo.com/?q=stm32+chess

Eine interessante Frage.

Schach gab's wohl schon auf dem 6502 und dem Z80:
https://www.schach-computer.info/wiki/index.php?title=Schachcomputer

Wenn man bedenkt, das früher Schach die Königsdisziplin der KI war.

Wie dumm ist doch der Mensch ...

Warum soll der Algorithmus speziell für ARM sein? Ein in korrektem C, 
C++, Java, C#, ... geschriebener Schach-Algorithmus läuft auf jedem 
Prozessor. Auch wenn er irgendwann mal für ZX81 konzipiert war.

Dann nimmst du halt einen beliebiges Schachprogramm in C, wie dieses...
https://github.com/fogleman/MisterQueen

...und jagst das durch deinen Compiler.

Ob genau DAS für dich tut, weiß ich nicht. Ich haber nur schnell das in 
Google eingetippt. Aber du wirst fündig werden, denke ich.

Ja, das tut man so. Denn C ist eine Hochsprache, und ist im Normalfall 
Hardwareunabhängig. Um die Umsetzung auf deinem ARM Cortex kümmert sich 
dein Compiler. Im Höchstfall mussst du geringe Anpassungen machen.

Wenn du nach "open source schach" suchst solltest du was finden un dann 
ist auch die Plattform egal.

Patrick B. schrieb:
> Aber die Rechentiefe ist abhängig von
> Prozessorleistung.

Gute Software sollte man die natürlich an die Prozessorleistung anpassen 
(skalieren) können.

Patrick B. schrieb:
> Wenn man jetzt z.B. mit Assembler arbeitet oder
> Kombinationen damit macht, denke ich, dass ein paar Ebenen mehr drin
> sein sollten.

Ein paar Ebenen entspricht dann einer Potenzierung, also mehrere 
Größenordnungen schneller. Ich bezweifle dann doch, dass man von Hand in 
Assembler so viel effizienter kodieren kann, zumal es dank moderner 
Pipeline-Prozessoren überhaupt ziemlich kompliziert ist, all die 
Timing-Details zu beachten die der Compiler eingebaut hat.

Beispiel: Im "ARM System Developer's Guide" (2004) sind einige 
Optimierungen gezeigt, wie man seinen C-Code schneller machen kann, mit 
Beispielen was der Compiler aus der "langsamen" und "schnellen" Variante 
macht. Das habe ich mal ausprobiert - ein aktueller GCC produziert für 
alle Varianten den gleichen Code, der noch effizienter als das ist, was 
im Buch steht...

Dr. Sommer schrieb:
> Warum soll der Algorithmus speziell für ARM sein? Ein in korrektem C,
> C++, Java, C#, ... geschriebener Schach-Algorithmus läuft auf jedem
> Prozessor. Auch wenn er irgendwann mal für ZX81 konzipiert war.

Mit dem Ziel ARM Cortex zeige ich an, habe stark limitierten Speicher 
(256 Kb Flash), ebenso sehr stark limitiertes RAM, was für Hash Tables 
ein No go ist. Und ich möchte keinen Source Code haben, der unter 
Windows läuft, denn sollte auf Betriebssystemroutinen (Libraries) 
zurückgegriffen werden, ist Feierabend. Außerden sind die Windows- und 
Linux Schachprogramme meisten viel zu groß.

Source Code für Java- da brauche ich doch einen Java Interpreter 
(Runtime environment), das dürfte bei 256 kb Flash lustig werden...., 
oder?

Uwe M. schrieb:
> Und ich möchte keinen Source Code haben, der unter
> Windows läuft, denn sollte auf Betriebssystemroutinen (Libraries)
> zurückgegriffen werden, ist Feierabend.

Wozu braucht ein Schach-Algorithmus Betriebssystemroutinen? Die 
braucht's nur für die Nutzeroberfläche, die du sowieso neu schreiben 
musst.

Uwe M. schrieb:
> Außerden sind die Windows- und
> Linux Schachprogramme meisten viel zu groß.

Wenn man die Grafiken und Texte für die GUI rausnimmt wird das schon 
viel weniger. 256 KB Flash (oder mehr, manche STM32 haben 2 MB) wirklich 
komplett nur mit Code zu füllen muss man erst mal schaffen,

Uwe M. schrieb:
> Source Code für Java- da brauche ich doch einen Java Interpreter
> (Runtime environment), das dürfte bei 256 kb Flash lustig werden....,
> oder?
Es gibt Java für STM32.

Ein Arm-Cortex alleine sagt nichts aus.
Es gibt die A, die R und die M Reihe mit unterschiedlichen Profilen.
Dahinter kommt meist noch eine Zahl.

Ich habe hier gerade einen ARM Cortex A15. Der hat 4 Core mit 1.4 GHz. 
Daran hängen 2 Gbyte Ram.
Der kann es locker mit älteren Pentiums aufnehmen. Ich habe C++ und auch 
Qt darauf.

Wenn Arm, dann gib genau an, was du an Prozessor hast.

>Ich bezweifle dann doch, dass man von Hand in
> Assembler so viel effizienter kodieren kann,

Ich hatte mal dieses Jahr ein Morseprogramm in C auf dem GCC und dem IAR 
Compiler (Optimierung an) für einen M0+ geschrieben, sollte ein Test 
sein, dann exakt diesen Algorithmus Zeile für Zeile in Assembler 
formuliert. Auf Anhieb Faktor 2,5 schneller erreicht, und dann später 
bis zum Faktor drei optimiert. Natürlich weiß ich, daß Aufwand und 
Portierbarkeit grausam sind (Ausnahme Portierung innerhalb einer 
Familie). Ich will die Leistung eines C Compilers nicht schmälern, vor 
dessen Optimierungsleistung ich viel Respekt habe. Aber Assembler ist 
nun mal unerreichbar in Sachen Geschwindigkeit und Codegröße.

PittyJ schrieb:
> Ein Arm-Cortex alleine sagt nichts aus.

Stimmt, sorry! Ich meine einen M4.

Patrick B. schrieb:
> Dr. Sommer schrieb:
>> Warum soll der Algorithmus speziell für ARM sein? Ein in korrektem C,
>> C++, Java, C#, ... geschriebener Schach-Algorithmus läuft auf jedem
>> Prozessor. Auch wenn er irgendwann mal für ZX81 konzipiert war.
>
> Das kommt halt ganz darauf an, wieviele Möglichkeiten man vorausrechnen
> will. Mit einer intelligenten Software kann man den Entscheidungsbaum
> schon mal vereinfachen. Aber die Rechentiefe ist abhängig von
> Prozessorleistung. Wenn man jetzt z.B. mit Assembler arbeitet oder
> Kombinationen damit macht, denke ich, dass ein paar Ebenen mehr drin
> sein sollten. Aber ob das nötig ist...

Wenn man damit die Tiefe erreicht das Endspieldatenbanken das korrekte 
Endergebnis berechnen können, dann hat man sehr viel erreicht.


Übrigens, der C64 mit 64k Memory und Colossus 4.0 war damals schon so 
stark ,daß wenn er hier gegen die Forenteilnehmer spielen würde, 
mindestens 95% aller Punke holen würde.

Uwe M. schrieb:
> Auf Anhieb Faktor 2,5 schneller erreicht, und dann später
> bis zum Faktor drei optimiert.

Wie üblich bei solchen Anekdoten wäre es schön, den genauen Code zu 
kennen. Beim M0 hat man wohl noch keine komplexe Pipeline und Cache, 
welche das Assembler-Programmieren erschweren.

Patrick B. schrieb:
> Verhalten sich andere Prozessoren ähnlich?

Worauf jetzt genau bezogen? Alle leistungsfähigen modernen Prozessoren 
haben Pipelines und Caches, falls es darum geht.

Patrick B. schrieb:
> Oder kann es passieren, dass
> der gleiche Code massiv unterschiedliche Performance hat, je nach
> Zielsystem?
Das sowieso. Was auf einem ARM schnell geht, kann beim AVR 
schnarchlangsam sein, allein schon weil der keinen Barrel-Shifter, 
weniger Adressierungs-Möglichkeiten, keine FPU, und natürlich weniger 
Bits pro Register hat.

Hallo,

der Autor des CT800 hier. Da ich meine Backlinks nicht täglich prüfe, 
hat es etwas gedauert. Dass es außer dem CT800 soweit ich weiß kein 
OSS-Schachprojekt auf Cortex-M gibt, liegt einfach daran, dass bislang 
sonst niemand ohne finanzielle Kompensation den nötigen Aufwand 
getrieben hat.

Man kann grundsätzlich PC-Engines auf Cortex-M bringen, der CT800 ist ja 
ein Fork von NG-Play. Bitboard-Engines wie Stockfish sind aufgrund des 
Speicherbedarfes praktisch nicht möglich. Auch mit dem Stackverbrauch 
muss man sich Gedanken machen, weil das auf dem PC kein Gesichtspunkt 
ist. Hashtabellen gehen, nur entsprechend kleiner.

Der Löwenanteil des Aufwands geht in das User-Interface - besonders, 
wenn man ein vollwertiges Gerät mit diversen Zeitmodi, Optionen und 
Eröffnungsbuch bauen will. Dazu noch die Hardware, schließlich muss man 
das alles aufbauen und für die Ansteuerung auch Treiber schreiben.

viele Grüße, Rasmus

Hallo Rasmus!

Vielen Dank für den Hinweis! Habe sofort deine Seite besucht und alles 
runtergeladen. Muss mich aber im Januar damit ausführlich beschäftigen, 
scheint umfangreich zu sein bei der Leistungsfähigkeit deines Programms, 
alle Achtung!!!
LG

Uwe

Hi Uwe,

Freut mich, dass es dir gefällt!

Da das ja ein Fachforum für embedded ist: schau dir im Moment die 
Treiberschicht lieber nicht zu genau an. ;-) Die braucht ein 
Refactoring, was für das nächste Release Anfang Januar geplant ist.

Vom Umfang her dürfte der größte Einzelposten wohl das Eröffnungsbuch 
sein: 22000 verschiedene Züge in 12000 Positionen, jeder einzelne von 
Hand eingegeben und mit einem Desktop-Pprogramm geprüft.

Wenn man die PC/Android-Version auf ungefähr 30 kNPS (30000 Knoten pro 
Sekunde) drosselt und die Hashtabellen auf 1 MB einstellt, kommt die 
Spielstärke dem realen Gerät schon sehr nahe.

viele Grüße, Rasmus

Naja, der PI ist zwar kein Cortex-A sondern dessen veralteter 
ARM11-Vorgänger, aber dennoch ziemlich ähnlich. "Abseits von Cortex" 
stimmt also nicht so ganz...

Tom p. schrieb:
> ach ja, und zum Schluss sagen sie, das Du vermutlich nur ein Troll
> bist und rumtrollen willst...das übliche eben

Deshalb WAR das mal ein gutes Forum.
Heute ist es besser du kuemmerst dich um deine Probleme selbst und loest 
sie alleine.

Teilnehmer schrieb:
> Deshalb WAR das mal ein gutes Forum.

Paar Idioten gibt es immer, auch in der realen Welt. Vermiete mal 
Wohnungen..... Dennoch muss ich sagen, hatte hier von den mehrheitlich 
konstruktiv veranlagten Leuten tolle Tipps erhalten, etwa beim Einstieg 
in die ARM-Cortex M Welt, Löten von 0,5 mm Strukturen, Schach, man hat 
mir Kicad schmackhaft gemacht (ich liebe Kicad!), so daß mein 
Lebensabend richtig spannend geworden ist. Erst SAM D M0+ Projekt mit 
Kicad layoutet, dann zu ST gewechselt zum M4, geiles Ding. Ich danke all 
diesen Leuten und wünsche allen einen guten Rutsch nach 2019!

Uwe