Hi
Ich möchte auf meinem atmega644 Nanochess zum laufen bringen
(http://nanochess.110mb.com/chess3.html). Leider ist im Quellcode fast
nichts zu erkennen. Ich dachte mir ich könnte das WinboardProtokoll
simulieren um eine Verbindung zwischen avr-In/Output und chess-Engine
herzustellen (Hardware funktioniert, Display ansteuerungsmethoden und
Tastatur abfragfunktionen sind auch schon fertig). Nun habe ich aber
nichts über das Winboard-Interface gefunden, zumindest nicht welche
Befehle es hat.
Gebe ich im Prog (für Winboard) e2e4 ein kommt komischerweise folgendes:
1
e2e4
2
y}{|~z|{} 76Lsabcddcba .pknbrqmove a8e4
Stehe ich auf dem Schlauch oder ist da ein Bug im Programm?
Konnte bisher aber nichts brauchbares rauslesen. Sieht vielleicht
irgendjemand wie ich an der berechneten Zug komme? Eingeben kann ich ihn
ja leicht, indem ich sie über die getchar-Funktion zukommen lasse.
Hans Mayer schrieb:> hast du mal E2E4 probiert?> in Großbuchstaben?
Dem Programm ist das egal. Man kann beides eingeben. Es muss aber
irgendwie doch möglich sein, den Zug abzufangen und weiterzuleiten,
damit ich ihn anzeigen kann.
Natürlich könnte man auch das board abfragen, wie es sich geändert hat,
aber das ist irgendwie doch total ineffizient.
Du willst es Dir antuen, und ein Programm vom IOCCC benutzen ???
Dir ist klar das diese Programme ausschliesslich auf Groesse und
Unleserlichkeit getrimmt sind ? Performance spielt z.B. oft keine Rolle,
wenn man es nur in die wenigen Bytes quetschen kann. Könnte auf 'nem
Mikrocontroller ewig zur Berechnung brauchen.
Naja, als Tipp würde ich mal den Preprozessor über das Programm laufen
lassen. Vielleicht kann man ja dann mehr erkennen als Chinesisch.
Das geht z.B. so:
derdas schrieb:> Naja, als Tipp würde ich mal den Preprozessor über das Programm laufen> lassen. Vielleicht kann man ja dann mehr erkennen als Chinesisch.
Ich möchte ungern den Thread hier kapern, aber warum schreibt man so ein
"Chinesisch":
Samuel K. schrieb:> #define F getchar()&z> #define v X(0,0,0,21,> #define Z while(> #define _ ;if(> #define P return--G,y^=8,
Das ist doch Krank!!
Silvan König schrieb:> derdas schrieb:>> Naja, als Tipp würde ich mal den Preprozessor über das Programm laufen>> lassen. Vielleicht kann man ja dann mehr erkennen als Chinesisch.>> Ich möchte ungern den Thread hier kapern, aber warum schreibt man so ein> "Chinesisch":
Aus Spaß. Google doch einfach mal nach "IOCCC". Es so unleserlich wie
möglich zu schreiben, ist genau das, worum es dort geht.
derdas schrieb:> Performance spielt z.B. oft keine Rolle,> wenn man es nur in die wenigen Bytes quetschen kann. Könnte auf 'nem> Mikrocontroller ewig zur Berechnung brauchen.
Ich kenne außer Micromax aber kein anderes das mit so wenig Ram
auskommt.
Silvan König schrieb:> Samuel K. schrieb:>> #define F getchar()&z>> #define v X(0,0,0,21,>> #define Z while(>> #define _ ;if(>> #define P return--G,y^=8,>> Das ist doch Krank!!
Ja, das ist es. Das machen sie nur um den Code zu verkleinern.
Simon K. schrieb:> Um den Code zu verkleinern?! Das machen die um ihn unleserlich zu> machen. Aus welchen Gründen auch immer ;-)
Lies doch den Text. Es geht ihnen um den kleinsten C-Code der Schach
spielen kann. -> Alle Variablen/Funktionen nur ein Zeichen. Alles so
klein wie möglich schreiben... und natürlich #define benutzen wenn der
Code kleiner wird.
Man macht es auch wenn man den Code unleserlich machen möchte,
allerdings glaube ich nicht das es hier um darum geht (Micromax schreibt
sogar Kommentare hinter die Zeilen, bei einer Version, um es leichter zu
verstehen. Dazu erklärt er das ganze Programm noch).
Kleinster C-Code vielleicht. Aber nicht kleinster Maschinencode. Kleines
Missverständnis.
Trotzdem: Der IOCCC wurd ja schon genannt.
---
Der International Obfuscated C Code Contest (kurz IOCCC) ist ein
Programmierwettbewerb für die am kreativsten verschleierten C-Programme,
der seit 1984 jährlich veranstaltet wird (mit Ausnahme von 1997, 1999,
2002 und 2003). (engl.: to obfuscate: von lat. obfuscare, dt.:
verdunkeln).
---
http://de.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest
Also geht es ums Verschleiern und nicht (vorrangig) ums Verkleinern. :-)
Vielleicht habe ich dein Problem nicht ganz verstanden, aber was spricht
dagegen, einfach die getchar- und dir putchar-Funktion durch eigene
Funktionen zu ersetzen und dort die gesamte Ein-/Ausgabe (LCD, Taststur,
Sensorbrett, Roboterarm oder was auch immer) abzuwickeln? Das brauchst
du den eigentlichen Schachalgorithmus nicht verstehen.
Simon K. schrieb:> Der International Obfuscated C Code Contest (kurz IOCCC) ist ein> ProgrammierwettbewerbWar ein Programmierwettbewerb trifft es wohl eher. Das letzte Mal fand
im Jahr 2006 statt.
Mark Brandis schrieb:> Simon K. schrieb:> War ein Programmierwettbewerb trifft es wohl eher. Das letzte Mal fand> im Jahr 2006 statt.
Das waere ein Jammer. Da gab es immer so schoen kranke Sachen! Ich
erinnere mich z.B. noch an ein 3D Labyrinth ala Castle Wolfenstein
(natuerlich im Text-Modus): Der Plan des Labyrinths war die Formatierung
des Source-codes, d.h. das compilierte Program hat seinen eigenen
Source-Code eingelesen :-) (wobei das eher Standard war, als
ungewoehnlich)
Oder ein BASIC interpreter oder compiler, und das alles in weniger als
4096 Bytes Quelltext!
erster Schritt bei den IOCCC Sachen ist es immer, das ganze auf einem PC
zum laufen zu bringen. Nicht selten werden beim IOCCC nicht-standard
konforme Dinge ausgenutzt, die eine bestimmte Compiler-Release macht und
die nächste macht es schon wieder ganz anders. Rechne nicht damit, dass
sich IOCCC Programme streng an C-Richtlinien halten.
Hast du das Ding am PC am laufen, dann beginnt die eigentliche Arbeit.
Das Rück-Obfuscaten. Wobei man sinnvollerweise nach ausnahmlos jeder
kleinen Änderung wieder Tests fährt um zu sehen ob und was man durch die
Rückübersetzung zerstört hat.
Das geht jetzt ein paar Iterationen durch, bis man auf einem halbwegs
akzeptablen C-Code gelandet ist. Und erst der hat dann auch Chancen,
dass man ihn portieren kann.
Johann L. schrieb:> Für avr-gcc scheitert es schon daran, daß ein int nur 16 Bits groß ist.> Bei der Initialisierung läuft N zB über.
Also bei mir läuft das ganze am PC einwandfrei.
Yalu X. schrieb:> Vielleicht habe ich dein Problem nicht ganz verstanden, aber was spricht> dagegen, einfach die getchar- und dir putchar-Funktion durch eigene> Funktionen zu ersetzen und dort die gesamte Ein-/Ausgabe (LCD, Taststur,> Sensorbrett, Roboterarm oder was auch immer) abzuwickeln? Das brauchst> du den eigentlichen Schachalgorithmus nicht verstehen.
Mein Problem hast du erkannt, aber ausgegeben wird nur das Board, dh ich
müsste das Board nach Änderung untersuchen (und das kostet Code, Zeit,
Ram, und ist ineffizient) Achja das ganze kostet auch einen haufen Ram,
denn das alte Board muss gespeichert werden (min. 32Byte).
Bernhard M. schrieb:> Wie wärs alternativ zu Nanochess mit AVR-Max:> http://www.schach-computer.info/wiki/index.php/AVR...>> Edit: Wichtig auch die dort verlinkte Seite:> http://www.andreadrian.de/schach/
Auf den Seiten war ich auch schon, allerdings finde ich den Code
ebenfalls extremst unleserlich.
Samuel K. schrieb:> Johann L. schrieb:>> Für avr-gcc scheitert es schon daran, daß ein int nur 16 Bits groß ist.>> Bei der Initialisierung läuft N zB über.>> Also bei mir läuft das ganze am PC einwandfrei.
Was ist denn das für eine völlig sinnfreie Stellungnahme zu dem genanten
Problem?? Ganz schön disquallifizierende Aussage.
Samuel K. schrieb:> Auf den Seiten war ich auch schon, allerdings finde ich den Code> ebenfalls extremst unleserlich.
Dafür gibts eine wirklich ausführliche Erklärung beim Autor des
Originals auf:
http://home.hccnet.nl/h.g.muller/max-src2.html
Wenn man sich eh richtig in das Programm einarbeiten will (es also
komplett verstehen will) ist es eine gute Übung, es mithilfe der
Beschreibung leserlich zu machen.
Sinnfrei. schrieb:> Was ist denn das für eine völlig sinnfreie Stellungnahme zu dem genanten> Problem?? Ganz schön disquallifizierende Aussage.
Am PC wird das Board ausgegeben. Ich den Befehl, der das Board
aktualisiert, durch einen ersetzen, der den Zug ausgibt.
Samuel K. schrieb:> Johann L. schrieb:>> Für avr-gcc scheitert es schon daran, daß ein int nur 16 Bits groß ist.>> Bei der Initialisierung läuft N zB über.>> Also bei mir läuft das ganze am PC einwandfrei.
Ich dachte es ging um eine Implementierung für avr-gcc?
Auf nem PC ist ein int üblicherweise mindestens 16 Bits groß. Für
Nanochess bringt jedoch ein
1
#define int long // bzw. int32_t
kaum was, weil man damit nicht (implizite) Type-Promotion erschlägt,
d.h. man müsste an gegebenen Stellen explizite Casts einfügen. Ohne
jedoch den Code zu verstehen, ist das nicht ganz einfach. Immerhin ist
der Code dafür geschrieben, unverständlich zu sein.
Weiters wäre es interessant, für das Programm eine RAM-Analyse zu machen
um zu sehen, ob der AVR überhaupt genügend RAM hat.
Ausserdem...spielt das Programm so grottenschlecht, daß es keim Spaß
macht, dagegen zu spielen.