Also ich kriege hier echt noch Läuse... Ich sitze schon seit Tagen über ein paar Zeilen aber irgendwie scheint GCC zwei Variablen die selben Register zuzuordnen. Kann sowas sein? Das ist auf jedenfall sehr schwer mit AVRStudio zu beurteilen ob da die Register nacheinander genutzt werden und die werte gesichert werden oder ob es da zu handfesten Kollisionen kommt. Ist euch da irgendetwas bekannt ob GCC solche Bugs erzeugen kann? Hätte mal jemand Zeit drüber zu schauen?
> Kann sowas sein? Eigentlich nicht. > Hätte mal jemand Zeit drüber zu schauen? Über was?
0undNichtig wrote: > Ich sitze schon seit Tagen über ein paar Zeilen aber irgendwie scheint > GCC zwei Variablen die selben Register zuzuordnen. Kann sowas sein? Ja klar. Warum sollte der Compiler eine so wertvolle Resource wie ein CPU-Register noch blockieren für eine Variable, die bereits gar nicht mehr genutzt wird? Das wäre doch pure Verschwendung. Der Job des Optimierers ist es doch, die Register möglichst sinnvoll zu belegen. Gewöhn' dich dran. AVR Studio ist sowieso eher ein mittelmäßiger Debugger. Wenn du's genau wissen willst, musst du eben den generierten Assemblercode angucken oder dir den Code disassemblieren lassen.
Also ich benutze viele 16bit Doppelregister. Wie man im Bild sieht haben x und pixelrest die selben Register. Nun kann es ein Bug im AVRStudio sein, eine Fehlinterpretation meinerseits oder GCC hat im Binary oder im ELF was falsch gemacht :-/ Ich weiß nicht ob ich es jemanden zumuten kann sich durch meinen Source zu wühlen...
Hast du dir mal genau durchgelesen, was Jörg geschrieben hat? "Warum sollte der Compiler eine so wertvolle Resource wie ein CPU-Register noch blockieren für eine Variable, die bereits gar nicht mehr genutzt wird?"
Ja das stimmt schon aber wenn ich das Disassembly richtig verstehe wird der Wert nicht gerettet. Das Problem ist ja eigentlich auch, dass eine Stelle kommt, wo beide Variablen gebraucht werden, aber wenn beide die selben Register sind wäre das ja ohne Wirkung:
1 | //check if the first pixelbyte is incomplete (necessary byte allready allocated)
|
2 | pixelrest=x % PixelSpace; //if x<3 it returns 3 |
3 | if (pixelrest!=0) |
4 | {...
|
1 | ---- D:\Projekte\AVR\Hausmanagement\GLCD\Source\S1D13700ex.c -------------------------------------- |
2 | 261: pixelrest=x % PixelSpace; //if x<3 it returns 3 |
3 | +0000032C: E037 LDI R19,0x07 Load immediate |
4 | ---- No Source ------------------------------------------------------------------------------------ |
5 | +0000032D: 22E3 AND R14,R19 Logical AND |
6 | +0000032E: 24FF CLR R15 Clear Register |
7 | ---- D:\Projekte\AVR\Hausmanagement\GLCD\Source\S1D13700ex.c -------------------------------------- |
8 | 262: if (pixelrest!=0) |
9 | +0000032F: 14E1 CP R14,R1 Compare |
10 | ---- No Source ------------------------------------------------------------------------------------ |
11 | +00000330: 04F1 CPC R15,R1 Compare with carry |
12 | +00000331: F069 BREQ PC+0x0E Branch if equal |
Ganz nebenbei, bitte screenshots nicht als JPEG: Beitrag "Schaltpläne und Board-Layouts gehören nicht ins jpg oder g"
0undNichtig wrote: > Das Problem ist ja eigentlich auch, dass eine Stelle kommt, wo beide > Variablen gebraucht werden, ... Woher willst du das wissen? Der Compiler kann und darf deinen Code doch so umformen, dass er vielleicht nicht mehr beide Variablen braucht? >
1 | > //check if the first pixelbyte is incomplete (necessary byte allready |
2 | > allocated) |
3 | > pixelrest=x % PixelSpace; //if x<3 it returns 3 |
4 | > if (pixelrest!=0) |
5 | > {... |
6 | >
|
Ja, die Variable x wird ab dieser Stelle nicht mehr benötigt (zumindest nicht im geposteten Teil), daher wird ihr ,Speicher' (also ihr Registerpaar) durch den neuen Wert von pixelrest überlagert. Das hat hier sogar doppelt Sinn, da die Modulo-Operation mit (offenbar) 8 als UND-Verknüpfung mit 7 implementiert ist, und diese Operation ihr Ergebnis zwangsweise erst einmal im bisherigen Register hinterlässt. Wenn der Compiler also ab der linken Seite dieser Zuweisung den Wert von x nicht mehr braucht, dann spart er sich sinnlosen Kopieraufwand. Wenn dem nicht so ist: bitte compilierfähiges Schnipsel posten (am besten gleich als Anhang), bitte nur den Code, keine langen Disassemblerlistings. Ich kann die Dinger sowieso nicht lesen, und die Zuordnung des Quellcodes zum Objektcode ist bei guter Optimierung schlicht nicht mehr möglich, verwirrt also eher.
@ Jörg Wunsch (dl8dtl) >Ganz nebenbei, bitte screenshots nicht als JPEG: Eben. Oder nochmal schön dargestellt. Bildformate MFG Falk
Wo werden denn in deinem Codefragment beide Variablen gleichzeitig gebraucht?
@Rolf in dem obigen Source bei der Modulo Operation Also gut ich gehe mal davon aus, dass das stimmt. Ist mir ja schon öfters bei AVRStudio aufgefallen aber an der Stelle kam mir das irgendwie komisch vor... Das ist aber auch doof fürs debuggen, na werde meinen (eigentlichen) Fehler schon finden. Danke Leute! Sry wegen dem JPEG...
Wie Jörg schon schreibt, wird x nur bis zu dieser Operation benötigt, pixelrest erst danach.
Bitte 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.