Ja, Egbert, ich finde auch: das verdient in der Tat größten Respekt. Ich habe mal mit einem Kollegen zusammengearbeitet, der exakt so programmieren durfte/musste. Er hat meist 2 oder 3 Programmstellen gleichzeitig bearbeitet und über die Änderungen Buch geführt. Jedes Mal war ein Eprom "fällig", dieses brennen, einsetzen, die 2-3 Änderungen testen und nächste Runde.

Der Kollege war ausgesprochen geduldig. Ich behaupte dies zwar in einigen Punkten von mir auch, aber ich hätte niemals nicht auf diese Art programmieren können. Mir war es immerhin vergönnt, meine Programme zwecks Test nur flashen zu müssen, was erheblich schneller ging und kein Umstecken oder gar 15 min Löschen der Eproms erforderte...

Ein "moderner Programmierer" käme vermutlich mit dieser Art des Arbeitens überhaupt nicht mehr zurecht und würde es als absolute Zumutung empfinden. Ich denke aber, es sollte passende Emulatoren geben, sodass das eigentliche Brennen erst ganz am Ende der Produktentwicklung wirklich nötig wird. Und bis zu diesem Punkt kann man flüssig seiner Kreativität freien Lauf lassen und die Gedanken in Bits und Bytes fließen lassen. Programmieren ist Kunst!

Ich empfinde Egberts Test vor wenigen Monaten als ausreichend aussagekräftig um zu verstehen, dass die reine Transformation des Glasgow Programms nach C oder sonstwohin und die anschließende Beschleunigung Dank schnellerer Hardware nicht zielführend sind. Hier muss tatsächlich neu gedacht und programmiert werden. Und wenn das keiner der damaligen Helden macht... dann ist es einfach kein Glasgow-Programm mehr!

So leid es mir tut... es wird einem neuen Programmierer unmöglich sein, die Ideen des damaligen Teams en detail zu verstehen und alleine so weiterzuentwickeln, dass wir Schachcomputer-Enthusiasten den Spielstil wieder als Ur-Glasgow wiedererkennen werden.

Vl. überlegt es sich Thomas nochmal. Ansonsten erfreuen wir uns an dem was wir haben. Im Wissen, dass es das Ende eines Evolutionszweigs der Schachprogrammierung ist. Ich sage bewusst nicht "Sackgasse".

Viele Grüße
Andreas

Sehr schön geschrieben Adreas, volle Zustimmung

Gruß
Egbert

Und jetzt stell es Dir mal mit einem vernünftigen Protokoll vor!

Dann testet man wirklich die Engine und nicht die GUI.

Dieser Testzyklus mit EPROM brennen war aber in den 80ern Stand der Technik, das haben die meisten gemacht.

Ja, ich meinte aber den Umstand den Thomas beschrieben hatte, hinsichtlich des stetigen Pendelns zwischen Firma und Zuhause. Effizienz sieht anders aus

Gruß
Egbert

Ich habe das so verstanden, dass in der Firma gebrannt wurde und das Testen dann bequemerweise zu Hause stattgefunden hat. Ohne zu pendeln hätte sicher auch in der Firma getestet werden können.

Deswegen kann ich beim CT800 die Firmware sowohl für den PC als auch für die ARM-Zielhardware kompilieren. Auf dem PC ist das Testen einfacher, und das Debuggen dank zahlreicher Debug-Ausgabemöglichkeiten auch. Es unterscheidet sich nur die Schicht mit den IO-Sachen, die sauber gekapselt ist. Kann ich auch für kommerzielle Entwicklung empfehlen, weil man die Software bereits machen kann, während die Hardware noch gar nicht bereit ist.

Ein Hoch auf C, den genialsten portablen Makro-Assembler überhaupt. Mit den GCC-Erweiterungen kann man sogar Jumptables machen, also "computed goto", was man sehr gut gebrauchen kann. Beinahe wie in Assembler, nur in portabel.

Aber beim Glasgow wäre das aufwendig geworden, weil die primitiven Operationen ja in Assembler selber definiert werden mußten. Das hätte man also für x86 auch noch alles machen müssen. Und dann hätte man immer noch keine einfache Tastatureingabe und Bildschirmausgabe gehabt.

Und C ging damals beim Glasgow vermutlich deswegen nicht, weil die Compiler längst nicht so gut optimiert haben wie heute. Zudem war der CDL-Optimierer ganz große Klasse, und das nicht nur nach damaligen Maßstäben.

Eine Sache beim Glasgow wundert mich aber: wenn es auch damals schon klar war, daß die spekulativen Bäume in großer Entfernung doch unsicher werden, wieso hat man nicht einfach einen "Straffaktor" eingeführt, um die Abzinsung anhand der Rechentiefe gleich in die Bewertung einzufügen?

Das kannst Du aber nur, weil der PC eine große Rechenpower hat. Und es ist heute kein Problem mehr, mehrere PC auch privat zu besitzen.
Anfang der 80er war aber eine PDP als Entwicklungsgerät schon was besonderes und nicht gerade billig. Von daher ist es schon sinnvoll, für Spieltests zu Hause mit ROMs und einer 1806 zu arbeiten und nur die eigentliche Entwicklung mit der PDP zu machen.

Ich hatte damals unter CP/M auch eine minutenlange Turnaroundzeit für Compiler bzw. Assembler und Linker. Trotz RAM-Floppy für temporäre Dateien dauerte es 10 und mehr Minuten. Damals hat man anders als heute gearbeitet wo der Compiler einem kaum Zeit zum einschenken und trinken lässt.

Wie hoch soll der denn sein um zu wirken und nicht alles zuzulassen oder zu unterbinden?

Stimmt.

Anfang der 80er hab ich tatsächlich noch mit Murmeln gespielt.

Das wäre experimentell zu ermitteln, indem man in Testpartien mißt, was für eine durchschnittliche Trefferrate die Taube auf dem Dach denn hat.

Eine andere Sache ist natürlich die, daß z.B. auf einem Cortex-M4 eine ganz andere Rechenleistung verfügbar ist. Die Folge ist, daß man nicht bloß taktisch vorausrechnen kann, sondern vor allem auch positionell. Irgend ein Schachprofi hat mal treffend gesagt, daß überlegene Taktik aus einer überlegenen Position kommt. Das braucht dann aber erstmal die stillen, vorbereitenden Züge.

Insofern bin ich mir nicht so sicher, ob der ganze Ansatz des Glasgow überhaupt skaliert.

Wenn ein Figurengewinn in neun Halbzügen mit einem Bauerngewinn in drei Halbzügen verglichen werden soll, dann reden wir hier von etwa 0,4 Bauerneinheiten pro Halbzug als Schwelle. Das wird so nicht einfach funktionieren.

Der Glasgow hat einen Ansatz mit sehr viel Schachwissen und Statik. Die aktuellen Spitzenprogramme verwenden alle Late Move Reductions, ein ultradynamisches Verfahren fast ohne Schachwissen.

Jetzt wäre interessant, ob diese zwei Verfahren kompatibel gemacht werden können. Das wird nicht einfach, da der Aufwand pro Knoten stark differiert.

An der Stelle wäre es interessant, ob aus der vorhandenen sprachlichen Beschreibung ein Suchalgorithmus formuliert werden könnte. Wenn ich den Vortrag richtig verstanden habe, dann sind hier die CDL2-Sourcen nicht unbedingt eine Hilfe. Denn eine einfache rekursive Formulierung scheint es ja nicht zu sein.