Reverse Engineering der NLT II

[HenneNWH]

Beim BCC (DOS) gibt es einige Optimierungsstufen (-O1, -O2) welche nicht korrekten Code erzeugen.

Code welcher mit anderen Optimierungsstufen generiert wurde (-O, -G, -Od) laufen scheinbar ohne Fehler.

Das ist sehr interessant und vielleicht ein guter Moment, um diese Sache ins Gespräch zu bringen:
https://github.com/Henne/Bright-Eyes/issues/54

Steckt da vielleicht ein BCC-Bug dahinter?

Es sieht ganz danach aus. Diese Funktion halte ich für ein Paradebeispiel, da sie sich sehr leicht formal beweisen lässt.
Ein 32-bit Wert hat 4 Bytes v = (a,b,c,d). Der Wert der Funktion swap_u32(v) = (d,c,b,a), wenn alles richtig vom Compiler umgesetzt wurde.
Der Clang hat das sogar noch bestätigt.

Die in Gen gewählte Implementierung habe ich jetzt, optimiert mit (-O2), mit meiner neuen Implementierung verglichen.
Beispiel:

Code:

v = 0x1'21'93 new = 0x93'21'01'00 old = 0x1'01'00

Folglich geht an diesem Beispiel mit der Originalimplementierung etwas kaputt wofür der BCC verantwortlich gemacht werden kann.

In der professionellen Anwendungsentwicklung benutzt man automatische Unit-Tests um solchen Fehlern auf die Schliche zu kommen.
Die gibt's bei BrightEyes noch nicht werden von mir aber in Erwägung gezogen, wenn die Zeit dafür reif ist.

Solche Warnungen wie: "Blos nicht die Optimierung einschalten." werden (manchmal zu Recht) immer noch in Programmiererkreisen geflüstert.
Daher sind meine Anforderungen an korrekte, portable Programmierung berechtigt.
Ich bin mir allerdings auch bewusst, dass 1992 das Entwickeln von Software sehr mühselig und frustrieren war und ziehe den Hut vor Guido und Jochen.
Das gleiche gilt auch für die Entwickler von Compilern. Nach schlimmer als unter Windows etwas zu entwickeln war es unter DOS.

Dieser mögliche Fehler tritt übrigens in GEN nicht auf, da die Optimierung ausgeschaltet ist und imho. diese Funktion gar nicht benutzt wird.


Zum Schiffsreisebug: Es scheint so, dass das, was ich aus dem Assemblercode zurück entwickelt habe, mehrdeutig ist.
Manchmal wird bei unterschiedlicher signedness vom BCC derselbe Code erzeugt, manchmal nicht.
Im aktuellen Zustand von Schick in Bright-Eyes fällt es mir im Moment auch schwer etwas verlässliches zu sagen.
Hab das aber im Hinterkopf.