jdid wird mit -o3 wegoptimiert, muss ich das wirklich auf volatile
setzen?
uid wird komischerweise nicht wegoptimiert.
Danke und viele Grüße aus Ulm!
Reggie
Reginald L. schrieb:> jdid wird mit -o3 wegoptimiert
Wird die damit verbundene Funktionalität entfernt? Oder wird bloss das
Byte im Speicher wegoptimiert, aber das Programm tut was es soll?
Du hast Anspruch darauf, dass ein Programm sich wie beschrieben verhält.
Nicht aber, dass ein auf aggressiv eingestellter Optimizer den Code
Zeile für Zeile und Byte für Byte genau so umsetzt, wie der Quellcode
suggeriert.
Erklärung: Da der Compiler bei
ReadBytes((uint8_t*)&jdid, 1);
den Quellcode kennt und wohl inlined, merkt er in der Umsetzung des
Codes der Funktion, dass es um genau 1 Byte geht und wird dieses Byte
ohne Umweg über Speicher direkt im Register belassen.
Bei uid ist das jedoch nicht so einfach, weil 4 Bytes.
A. K. schrieb:> Wird die damit verbundene Funktionalität entfernt? Oder wird bloss das> Byte im Speicher wegoptimiert, aber das Programm tut was es soll?
Puh, schwer zu sagen, ich schaffe erst seit ein paar Tagen mit
Compiler-Optimierungen. Breakpoints kann ich bspws. nur auf dem ersten
und letzten return setzen. Der Breakpoint am return der uid wird
automatisch gelöscht.
A. K. schrieb:> Nicht aber, dass ein auf aggressiv eingestellter Optimizer den Code> Zeile für Zeile und Byte für Byte genau so umsetzt, wie der Quellcode> suggeriert.
Achso OK, ich verstehe. Also kann man debuggen eigentlich vergessen.
Kann man dann überhaupt 100%-ig sicher sein, dass ein größeres Programm
genau das tut, was man von ihm verlangt?
Reginald L. schrieb:> Achso OK, ich verstehe. Also kann man debuggen eigentlich vergessen.
Bei -O3 kann man im Debugger recht seltsame Erlebnisse haben, ja. Am
besten funktioniert ein Debugger ohne Optimierung.
> Kann man dann überhaupt 100%-ig sicher sein, dass ein größeres Programm> genau das tut, was man von ihm verlangt?
Nur wenn man es gemäss dem C Standard 100%-ig richtig formuliert hat.
Aber ich glaube du hast schon recht gehabt, dass die Funktionalität des
Programms gegeben ist. Es verhält sich genau so, wie vorher, nur dass
Debuggen nicht mehr wirklich funktioniert.
A. K. schrieb:> Nur wenn man es gemäss dem C Standard 100%-ig richtig formuliert hat.
Wer kann sowas bei größeren Programmen, Gott? :)
Vielen Dank für die Hilfestellung, ich weiß jetzt bescheid.
Reginald L. schrieb:> A. K. schrieb:>> Wird die damit verbundene Funktionalität entfernt? Oder wird bloss das>> Byte im Speicher wegoptimiert, aber das Programm tut was es soll?> Puh, schwer zu sagen, ich schaffe erst seit ein paar Tagen mit> Compiler-Optimierungen. Breakpoints kann ich bspws. nur auf dem ersten> und letzten return setzen. Der Breakpoint am return der uid wird> automatisch gelöscht.>> A. K. schrieb:>> Nicht aber, dass ein auf aggressiv eingestellter Optimizer den Code>> Zeile für Zeile und Byte für Byte genau so umsetzt, wie der Quellcode>> suggeriert.> Achso OK, ich verstehe. Also kann man debuggen eigentlich vergessen.> Kann man dann überhaupt 100%-ig sicher sein, dass ein größeres Programm> genau das tut, was man von ihm verlangt?
Du hast, denke ich, die Aussage nicht vollständig erfasst.
Die Optimierung wird dann Variablen wegfallen lassen, wenn sie die
gleiche durch den Code beschrieben Funktionalität auch ohne sie erzeugen
kann.
Der Effekt ist also nur, dass Du die Variable im Debugger nicht mehr
siehst oder anzeigen lassen kannst. In einigen Fällen entfallen auch
Codeteile, auf die Du dann keine Breakpoints mehr setzen kannst.
ABER: Die Funktionalität ist (in der Regel, also nur dann nicht, wenn
ein Fehler im Compiler vorliegt - und das ist ausgesprochen selten)
haargenau die selbe.
Daher: Testet und debuggt man einen Code erst einmal ohne Optimierung.
Erst wenn das gelungen ist, schaltet man die Optimierung ein.
Wenn es dann Fehler gibt, dann liegt ein anderer Fall vor. Nämlich der,
dass Du zwar syntaktisch korrekt eine interpretierbare Anweisung
hingeschrieben hast, die aber nicht tatsächlich unter allen relevanten
Umständen, dass machst, was Du tatsächlich beschreiben wolltest.
Du kannst also sicher sein, das getester und debuggter Code tut was er
aussagt. Nur kannst Du nicht sicher sein, dass Du Dich hundertprozentig
korrekt ausgedrückt hast.
Das ist ein Unterschied zu, der Compiler macht was er will ohne das Du
darüber Kontrolle hast.
Obwohl ich selbst sehr gerne in C programmiere, muss ich einräumen, dass
auch ich immer wieder mal über etwas abwegige Deutungen stolpere, die
aber nichts desto trotz durch den Standard (mehr oder weniger klar)
beschrieben sind. Das zeigt sich aber eben genau bei der Optimierung.
Die Optimierung ist extrem "konservativ" und geht nach dem "Buchstaben
des Gesetzes". Anders als wir Menschen. Das ist das Problem. Es sitzt
vor dem Bildschirm.
Hanswurst schrieb:> Du hast, denke ich, die Aussage nicht vollständig erfasst.
Ich habe mich undeutlich ausgedrückt, genauso wie du es beschreibst,
habe ich es verstanden :)
Reginald L. schrieb:>> Nur wenn man es gemäss dem C Standard 100%-ig richtig formuliert hat.> Wer kann sowas bei größeren Programmen, Gott? :)
Deshalb gibt es auch keine 100%-ig fehlerfreie grössere Programme. Auch
Gott hat bekanntlich seinen ersten Ansatz (Paradies) völlig versemmelt
und auch den zweiten nach längeren Tests in grossen Teilen wieder
vernichtet (Noah).
Reginald L. schrieb:> Hanswurst schrieb:>> Du hast, denke ich, die Aussage nicht vollständig erfasst.> Ich habe mich undeutlich ausgedrückt, genauso wie du es beschreibst,> habe ich es verstanden :)
Aha. Schön. Viel Erfolg, weiterhin.
A. K. schrieb:> Auch> Gott hat bekanntlich seinen ersten Ansatz (Paradies) völlig versemmelt
Mal davon abgesehen, dass ich ich absolut nicht bibeltreu bin:
Vielleicht war ja genau das der Plan ;)