Ich arbeite in ATMEL-Studio 6 mit C und kompiliere mit Optimization (-O0). So funktioniert mein Code. Bereits mit (-O1) geht nix mehr. Wie kann ich mir anzeigen lassen welche Variablen oder Pointer(weil sie wahrscheinlich nicht volitale deklariert worden sind) denn nun wegoptimiert worden sind? Vielen Dank schon mal im Voraus.
Im Assemblerlisting nachschauen... Besser: Verstehen, was volatile macht, und wofür es gebraucht wird, und es dann sinnvoll einsetzten. Oliver
Danke für die schnelle Antwort. Oliver schrieb: > Im Assemblerlisting nachschauen... Das hatte ich gemacht und mir den Disasembly anzeigen lassen, allerdings was müsste ich den lesen, wenn da an einer Stelle etwas wegoptimiert worden ist? > Besser: > Verstehen, was volatile macht, und wofür es gebraucht wird, und es dann > sinnvoll einsetzten. > > Oliver Das verstehe ich und um es noch besser zu verstehen(im Zusammenspiel mit dem Compiler), möchte ich es gerne auch sehen.
Frischling schrieb: > Das hatte ich gemacht und mir den Disasembly anzeigen lassen, allerdings > was müsste ich den lesen, wenn da an einer Stelle etwas wegoptimiert > worden ist? du musst den Assembler-Code natürlich auch verstehen bzw nachvollziehen, nicht nur lesen...
Frischling schrieb: >> Besser: >> Verstehen, was volatile macht, und wofür es gebraucht wird, und es dann >> sinnvoll einsetzten. >> >> Oliver > > Das verstehe ich und um es noch besser zu verstehen(im Zusammenspiel mit > dem Compiler), möchte ich es gerne auch sehen. Was willst du da sehen? Dass der COmpiler manchmal Operationen, die du eigentlich erwarten würdest, weglässt bzw. an eine andere Stelle schiebt? So ist das nicht weiter sinnvoll. Viel besser ist, wenn du auf C-Ebene verstehst, was du tun darfst, was du nicht tun darfst und wofür du von der Sprachdefinition her keinerlei Garantie hast. Grundsätzlich kann der Compiler alles umstellen und zwar bis zur Unkenntlichkeit im Assemblercode. Er darf alles tun, solange das sichtbare Verhalten des Programms nach aussen sich nicht verändert. D.h. der Compiler wird gnadenlos jedes Schlupfloch ausnutzen, welches du ihm aufgrund von Defiziten in deinen C-Kenntnissen lässt. Genau deshalb ist es auch wichtig, dass man die Sprache gut beherrscht und nicht nur 15% des Sprachumfangs kennt, die man sich so recht und schlecht in Foren zusammengeschnorrt bzw. in untauglichen Tutotials angelesen hat.
Justus Skorps schrieb: > Frischling schrieb: >> Das hatte ich gemacht und mir den Disasembly anzeigen lassen, allerdings >> was müsste ich den lesen, wenn da an einer Stelle etwas wegoptimiert >> worden ist? > > du musst den Assembler-Code natürlich auch verstehen bzw nachvollziehen, > nicht nur lesen... Ähm ja, das ist mir auch klar, das versuche ich auch, nur beantwortet das die Frage nicht, oder?
Karl Heinz schrieb: > Genau deshalb ist es auch > wichtig, dass man die Sprache gut beherrscht und nicht nur 15% des > Sprachumfangs kennt, die man sich so recht und schlecht in Foren > zusammengeschnorrt bzw. in untauglichen Tutotials angelesen hat. Gut, du sagst mit jetzt, "Wenn du schnell laufen willst, musst du schnell laufen".
So viel ich weiss, gibt kein listing, wo steht was der Compiler wo wegoptimiert und umgestellt hat. Du kannst höchstens aufgrund des Assembler-Codes versuchen zu verstehen, was der Compiler gemacht hat. Sonst stell doch mal den Quellcode rein.
Erdbewohner schrieb: > So viel ich weiss, gibt kein listing, wo steht was der Compiler wo > wegoptimiert und umgestellt hat. Du kannst höchstens aufgrund des > Assembler-Codes versuchen zu verstehen, was der Compiler gemacht hat. Ich denke so werde ich es machen, danke. Ich habe auch schon die Vermutung, dass ich Variablen die ich im externen RAM anspreche volatile machen muss, da der Compiler ja gar nicht sehen/wissen kann, dass sich die Variable ändert/nicht ändern kann. Das schaue ich mir mit ADD-WATCH an und dann im Disasembly schauen was wieso passiert.
Map file... Ansonsten: drauf geachtet, shared variablen als volatile zu deklarieren?
Frischling schrieb: > Ich habe auch schon die Vermutung, dass ich Variablen die ich im > externen RAM anspreche volatile machen muss, da der Compiler ja gar > nicht sehen/wissen kann, dass sich die Variable ändert/nicht ändern > kann. Ja, das ist die Grundregel: wenn sich irgendetwas an einer Stelle ändert, für die der Compiler es gar nicht wissen kann, dann muss man das entsprechende Objekt als “volatile” markieren. Der Klassiker dafür ist halt eine Variable, die aus einem Interruptkontext heraus geändert wird, aber im Haupt-Thread dann überwacht. Aber es gibt natürlich auch andere Fälle. Was für eine Art „externen RAM“ benutzt du denn da?
Frischling schrieb: > Karl Heinz schrieb: >> Genau deshalb ist es auch >> wichtig, dass man die Sprache gut beherrscht und nicht nur 15% des >> Sprachumfangs kennt, die man sich so recht und schlecht in Foren >> zusammengeschnorrt bzw. in untauglichen Tutotials angelesen hat. > > Gut, du sagst mit jetzt, "Wenn du schnell laufen willst, musst du > schnell laufen". Nein. Ich sag dir: wenn du schnell laufen willst, dann musst du erst mal langsam laufen lernen. Es hat keinen Sinn, sich jetzt nach Methoden und Möglichkeiten zu erkundigen, wie man den New York Marathon gewinnen kann, wenn du noch nicht mal richtig krabbeln kannst. Das man beim Krabbeln lernen auch mal auf die Schnauze fällt ist normal. Nur darf man dabei nicht stehen bleiben. Die Devise heißt weiter lernen. Irgendwann ist man dann soweit, dass man sein erstes richtiges Programm schreiben kann. Aber mit zu wenig wissen, hat es keinen Sinn zu versuchen, ein Programm abseits der Lernstube zu schreiben. Leider wollen das viele nicht wahr haben, und denken mit dem wenigen was sie wissen können sie die Welt der Programmierung revolutionieren. Überspitzt ausgedrückt.
Frischling schrieb: > Erdbewohner schrieb: >> Du kannst höchstens aufgrund des >> Assembler-Codes versuchen zu verstehen, was der Compiler gemacht hat. > > Ich denke so werde ich es machen, danke. Ganz ernsthaft, wenn du dich schon selber als Frischling bezeichnest, lass es. Das schaffst du nicht. Was der Compiler mit eingeschalteter Optimierung aus dem C-Code macht, ist "höheres Durcheinander". Daraus etwas zu erkennen, erfordert sehr gute Kenntnisse in Assembler, und Übung im Lesen solches compiler-erzeugten Codes. Oliver
Karl Heinz schrieb: > Nein. > Ich sag dir: wenn du schnell laufen willst, dann musst du erst mal > langsam laufen lernen. > Es hat keinen Sinn, sich jetzt nach Methoden und Möglichkeiten zu > erkundigen, wie man den New York Marathon gewinnen kann, wenn du noch > nicht mal richtig krabbeln kannst. > Das man beim Krabbeln lernen auch mal auf die Schnauze fällt ist normal. > Nur darf man dabei nicht stehen bleiben. Die Devise heißt weiter lernen. > Irgendwann ist man dann soweit, dass man sein erstes richtiges Programm > schreiben kann. Aber mit zu wenig wissen, hat es keinen Sinn zu > versuchen, ein Programm abseits der Lernstube zu schreiben. Leider > wollen das viele nicht wahr haben, und denken mit dem wenigen was sie > wissen können sie die Welt der Programmierung revolutionieren. > Überspitzt ausgedrückt. Ich weiß, da gebe ich dir auch recht. Das Programm funktioniert(wiznet udp packete hin und her schicken), ohne Optimize, krabbeln geht also schon. Jetzt versuche ich zu verstehen warum der Compiler an bestimmten Stellen wegoptimiert. Beim nächsten Programm will ich das halt gleich wissen und net erst wenn der Code fertig ist. So, ich krabbel weiter.
Frischling schrieb: > Ich weiß, da gebe ich dir auch recht. Das Programm funktioniert(wiznet > udp packete hin und her schicken), ohne Optimize, krabbeln geht also > schon. Jetzt versuche ich zu verstehen warum der Compiler an bestimmten > Stellen wegoptimiert. Beim nächsten Programm will ich das halt gleich > wissen und net erst wenn der Code fertig ist. So, ich krabbel weiter. Dann geb ich dir den Tip, den Optimizer nicht erst zum Schluss einzuschalten, sondern gleich von Anfang an. Denn der Supergau ist es, wenn man vor einem 'fertigen' Programm steht, nichts geht und man hat keine Ahnung wo man anfangen soll zu suchen. Das erste was man lernt ist: Entwickle in Stufen. Nach jeder Stufe wird getestet! Und erst dann, wenn man einigermassen sicher ist, dass die gerade fertig gestellte Stufe so leidlich fehlerfrei ist, kommt dir nächste Stufe drann. Und ja, da hat man den Optimizer schon lange am laufen und nur zu Debug-Zwecken wird er abgeschaltet.
Karl Heinz schrieb: > Dann geb ich dir den Tip, den Optimizer nicht erst zum Schluss > einzuschalten, sondern gleich von Anfang an. Und auch die Warnings von Anfang an Einschalten, und Jede Warnung sofort beheben. Am besten gleich mit "-Werror" kompilieren. Bei vielen dieser "Optimierungs-Fallen" gibt der Compiler nämlich nette Warnungen aus. "Unreachable code", "Comparsion is always true", "Statement has no effect", ....
Εrnst B✶ schrieb: > Karl Heinz schrieb: >> Dann geb ich dir den Tip, den Optimizer nicht erst zum Schluss >> einzuschalten, sondern gleich von Anfang an. > > Und auch die Warnings von Anfang an Einschalten, und Jede Warnung sofort > beheben. > Am besten gleich mit "-Werror" kompilieren. > > Bei vielen dieser "Optimierungs-Fallen" gibt der Compiler nämlich nette > Warnungen aus. "Unreachable code", "Comparsion is always true", > "Statement has no effect", .... Yes, das war der Tip den ich suchte! Optimize einstellen und warnings anschauen. Danke Dir!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.