schon mal festgestellt? A. Due rechnet falsch - Mega ok!

[HaWe]

danke, habe ich sogleich getestet:

PC devcpp: OK

Arduino Due ARM: selber Fehler.

Arduino Mega AVR: OK.

[HaWe]

hat hier keiner einen Arduino Due zum austesten?

[Sisor]

Nö, leider nicht...

[Peter(TOO)]

Hallo HaWe,

Data Missalignment wird von unterschiedlichen CPUs unterschiedlich gehandhabt.

Also ein 16-Bit Zugriff auf eine ungerade Adresse:
1. Es wird ein Trap ausgelöst.
2. Das letzte Adressbit wird einfach als 0 angenommen und der Zugriff auf die gerade Adresse durchgeführt.
2. Es wird auf die ungerade Adresse zugegriffen und anschliessend auf das nächst höhere Byte. Bei e1nem 16-Bit Datenbus führt dies zu zwei Speicherzugriffen.

Hier macht mir das Macro:
#define K(A,B) *(int*)(T+A+( B&8 )+S*( B&7 ))
gerade etwas Sorgen.
T ist als char-Arrary definiert.

T+A kann eine ungerade Adresse erzeugen, welche dann zu einer Adresse eines int umgewandelt wird ....


Beim Cortex-M3 wird's jetzt richtig kompliziert.
Manche Befehle erlauben Zugriffe auf eine Unaligned-Adresse, andere erzeugen einen TRAP.
Über ein Register-Bit kann gefordert werden, dass alle Unaligned-Zugriffe den TRAP erzeugen.
Dann stellt sich noch die Frage, was der Standard-Traphandler macht.
Und natürlich, welchen Code der Compiler erzeugt.

Wie sich der ATMega verhält, weiss ich nicht.

MfG Peter(TOO)

[Mxt]

Meine Überlegungen gehen in die selbe Richtung, wie die von Peter.

Da der Beaglebone Black die gleiche Ausgabe produziert wie der Due, ist das kein Arduino spezifisches Problem. Der Cortex M3 im Due und der Cortex A8 im Beagle haben beide ARM v7.1 Architektur.

Das sich x86 und ein 8-Bitter ähnlich verhalten, ist nicht so außergewöhnlich. Intels Architektur enthält einiges an 8-Bit Erbe.

Bei dem Makro bin ich mir auch noch nicht sicher. Aber die vielen Warnungen zur Operator-Reihenfolge, die Clang auswirft, könnten auch noch auf andere Probleme im Code deuten. Im Moment habe ich keine Zeit dafür.

[HaWe]

hi,
danke schon mal für die Antworten!

Das obige *(int *) Makro habe ich ja wie berichtet (bei unveränderten Laufzeit-Verhaltenweisen) schon ersetzt durch

#define K(A,B) (int)(T+A+( B&8 )+S*( B&7 ))

Der Code läuft trotzdem OK für alle automatischen Zugberechnungen und auch für alle manuellen auf AVR und PC, nur die schwarzen Halbzüge machen Probleme auf dem Due.

Da sich unterm Strich nichts am Laufzeitverhalten geändert hat, sehe ich in dem Makro also ehrlich gesagt kein Problem, oder wie sehr ihr das?

Die Logik hinter den manuellen Zügen ist ja:
wenn man einen Zug eingibt, überprüft er ihn in einer abgekürzten Schleife auf Gültigkeit.

wenn man keinen eingibt, wird K auf I (=30000) gesetzt, damit erkennt der Move Generator, dass er selber über Züge nachdenken muss -
und überprüft sie dann auf Gültigkeit (mit derselben abgekürzten Schleife, und den besten gültigen führt er dann aus ).


Ich kann mir nur vorstellen, dass die Ursache ein Compilerfehler (Optimierungsfehler) ist, denn so großartige Pointerakrobatik wird ja nun mit dem umgeschriebenen Makro gar nicht mehr gemacht - das was beibt, ist Standard-ANSI-C.

Zugegebenrmaßen ist ja der von Muller ziemlich schwer verständlich und auf Kürze optimiert, d.h. auf möglichst wenige geschriebene Buchstaben.
Auch setzt er z.B. oft das Bitweise & oder | ein statt das logische && bzw. || ...

Bin deshalb ntl offen für andere Meinungen und Argumente, gerne auch für umgeschriebenen Sourcecode, den ich dann testen kann (und alle, die einen Due haben !


edit:
gerade festgestellt:
Springerzüge wie b8c6 werden akzeptiert, aber kein Bauernzug!
Spricht auch eher für ein Optimierungsproblem (piece < 3 )

- - - Aktualisiert - - -

ps:
gerade festgestellt:

manche automatischen Züge sind auf dem Due auch komplett falsch, z.B.
Bauer a7 X f2

das kann ja gar nicht gehen.

Also ist auch der Gültigkeits-Check für automatische Züge beim Due im A****, ganz egal ob
*(int*) oder nur (int)
im Makro, also immer !

- - - Aktualisiert - - -

also jetzt erst recht:

Bitte gerne Vorschläge für umgeschriebenen Sourcecode, den ich dann testen kann (und alle, die einen Due haben !

[Mxt]

Ich kann mir nur vorstellen, dass die Ursache ein Compilerfehler (Optimierungsfehler) ist,

Das ist extrem unwahrscheinlich, da mit Clang ein zweiter Compiler exakt die gleiche Programmausgabe produziert. Optimierungen hatte ich gar nicht eingeschaltet.

[HaWe]

guter Hinweis, stimmt!
hast du denn mit Clang (Beaglebone?) auch ungültige automatische Züge beobachten können, während mit dem PC immer alles OK war ?

[Mxt]

Ich habe nur ein paar Sachen probiert, jeweils die Windows Konsole parallel zu zwei Putty-Sessions mit der g++ und Clang Variante auf dem Beaglebone. Zwischen den beiden ARM-Linux Programmen gab es keinen Unterschied in der Ausgabe, sie verhielten sich immer gleich und anders als die Windows Version.

[HaWe]

ich verstehe zuwenig von Linux und putty -
was bedeutet genau "jeweils die Windows Konsole parallel zu zwei Putty-Sessions mit der g++ und Clang Variante auf dem Beaglebone" ?

heißt das, dass sowohl Clang- als auch gpp-Compiler-Code auf dem Beaglebone liefen und beide dieselben falschen Ergebnisse auf dem Beaglebone produzierten?