Es kann nur besser werden. Das ist gerade wie mit der Machete durch den Dschungel fetzen.
Im Moment werden Speicherzugriffe aufs Datensegment durch echte, lesbare globale Variablen
und hoffentlich gut benannte Datenstrukturen ersetzt.
Am Ende dieses Kapitels von Phase 2 sollten keine ds_read/write()-makros und auch
kein p_datseg mehr im Code sein und die symbols.h wird dann nicht mehr gebraucht.
Die Binäräquivalenzcodedifferenz ist ein wichtiger Wert, der mir herauszufinden hilft,
ob einzelne Variablen ein Vorzeichen haben oder nicht.
Wird dieser Wert kleiner oder bleibt gleich ist alles in Ordnung.
Wird er größer stimmt etwas nicht und ich muss dann genauer nachgucken.
Das bessert unsaubere Arbeiten meinerseits aus der Anfangszeit von Bright-Eyes aus,
falls ich mal ds_readb() anstelle von ds_readbs() benutzt habe.
Das entspricht dem Lesezugriff auf eine Variable im Datensegment vom Typ: unsigned char bzw. signed char.
Manchmal spielt es keine Rolle, manchmal kann so etwas auch zu Fehlern/Abweichungen geführt haben.
Wenn der Code dann in Reinform ist, ist es dann auf jeden Fall einfacher diesen Dingen nachzugehen.
Zwischenstand:
* Binäräquivalenzcodedifferenz = 4098 Bytes (geht gegen 0)
* auskommentierte Zeilen in der symbols.h = 28.6 % (geht gegen 100%)
* es kompilieren auch schon einige Dateien (54 / 112) mit dem GCC



Im Moment werden Speicherzugriffe aufs Datensegment durch echte, lesbare globale Variablen
und hoffentlich gut benannte Datenstrukturen ersetzt.
Am Ende dieses Kapitels von Phase 2 sollten keine ds_read/write()-makros und auch
kein p_datseg mehr im Code sein und die symbols.h wird dann nicht mehr gebraucht.
Die Binäräquivalenzcodedifferenz ist ein wichtiger Wert, der mir herauszufinden hilft,
ob einzelne Variablen ein Vorzeichen haben oder nicht.
Wird dieser Wert kleiner oder bleibt gleich ist alles in Ordnung.
Wird er größer stimmt etwas nicht und ich muss dann genauer nachgucken.
Das bessert unsaubere Arbeiten meinerseits aus der Anfangszeit von Bright-Eyes aus,
falls ich mal ds_readb() anstelle von ds_readbs() benutzt habe.
Das entspricht dem Lesezugriff auf eine Variable im Datensegment vom Typ: unsigned char bzw. signed char.
Manchmal spielt es keine Rolle, manchmal kann so etwas auch zu Fehlern/Abweichungen geführt haben.
Wenn der Code dann in Reinform ist, ist es dann auf jeden Fall einfacher diesen Dingen nachzugehen.
Zwischenstand:
* Binäräquivalenzcodedifferenz = 4098 Bytes (geht gegen 0)
* auskommentierte Zeilen in der symbols.h = 28.6 % (geht gegen 100%)
* es kompilieren auch schon einige Dateien (54 / 112) mit dem GCC