Ich will verstehen welcher ARM Assemblercode vom Compiler erzeugt wird.
Das folgende Testprogramm
1
voidsetup(){
2
Serial.begin(9600);
3
delay(1000);
4
Serial.print("Hello teensy40armDisasm5\n");
5
kStop=0;
6
while(1){
7
a=a+0x1234;
8
b=a+0x5678;
9
xstop();
10
}
11
Serial.print("end setup....\n");
12
}
erzeugt den unten angegebenen ARM-Thumb Assemblercode. Ich habe zwei
Fragen (für mich ist ARM Assembler noch ganz neu.):
Wozu dienen die vielen mit .short erzeugten Konstanten im Code?
Warum wird der code für
1
.....
2
a=a+0x1234 ;
3
b=a+0x5678 ;
4
....
anscheinend zweimal erzeugt?
1
void setup() {
2
b4: b508 push {r3, lr}
3
Serial.begin(9600);
4
delay(1000) ;
5
b6: f44f 707a mov.w r0, #1000 ; 0x3e8
6
ba: 4c0c ldr r4, [pc, #48] ; (ec <setup+0x38>)
7
bc: f000 f838 bl 130 <delay>
8
virtual int read() { return usb_serial_getchar(); }
9
virtual int peek() { return usb_serial_peekchar(); }
10
virtual void flush() { usb_serial_flush_output(); } // TODO: actually wait for data to leave USB...
Taiga Wutzzz wie wir ihn lieben.
Aber zum Thema: der "Assemblercode" passt nicht so recht zum
Programmcode. Irgendwas vom Programmcode wird uns verheimlicht ;)
Martin O. schrieb:> kStop=0 ;> a=a+0x1234 ;> b=a+0x5678 ;> xstop() ;
Das ist alles weder definiert noch initialisiert.
Das kann der Compiler garnicht übersetzen und sollte einiges an Fehlern
und Warnungen rausgeben.
Und wenn du die Optimierung vernünftig eingeschaltet hättest würde der
Compiler das sowieso einfach entsorgen weil die Variablen für nichts
verwendet werden.
Schreib erstmal vernünftigen C-Code...
Oliver S. schrieb:> Dann solltest du mal alle Warnungen einschalten.
Ich seh jetzt auf den ersten Blick nichts wo ne Warnung kommen sollte.
Was meinst Du?
Das einzige was mir auffällt ist daß die Klammern grauenvoll und
irreführend falsch eingerückt sind, aber das ist dem Compiler egal.
Naja, der Compiler (oder die Toolchain) bemühte sich, den Anforderungen
gerecht zu werden.
Will sagen, dass sie nicht mal selbst erzeugten Code korrekt in
Assembler ausgeben kann, daher die .sort und .word mitten im Code.
Was ist das für ein Compiler (und welche Version)?
Bernd K. schrieb:> Ich seh jetzt auf den ersten Blick nichts wo ne Warnung kommen sollte.> Was meinst Du?Irgend W. schrieb:> Das ist alles weder definiert noch initialisiert.
Definiert schon, initialisiert nicht.
Oliver
Oliver S. schrieb:> Definiert schon, initialisiert nicht.
Doch,schon.
Die non-local Variablen a,b,c werden - sofern nicht anders angeben -
zero-initialized.
Ist der falsche Diassembler. Ist kein ARMv4Thumb sondern ARMv7Thumb.
Da wird schnell aus:
"216841f2342245f278630a442260226813442b60"
6821 LDR R1, [R4]
f241 2234 MOVW R2, #0x1234
f245 6378 MOVW R3, #0x5678
440a ADD R2, R1
6022 STR R2, [R4]
6822 LDR R2, [R4]
4413 ADD R3, R2
602b STR R3, [R5]
und nicht:
d0: 6821 ldr r1, [r4, #0]
d2: f241 .short 0xf241
d4: 2234 movs r2, #52 ; 0x34
d6: f245 .short 0xf245
d8: 6378 str r0, [r7, #52] ; 0x34
da: 440a .short 0x440a
dc: 6022 str r2, [r4, #0]
de: 6822 .short 0x6822
e0: 4413 add r3, r2
e2: 602b .short 0x602b
Beim ARMv4 war Thumb noch optional, beim Cortex-M7 ist es das einzige
Opcode-Format und deswegen wurde es um einige 2x16Bit Breite Befehle
erweitert. Der ARMv4-Diassembler wird da einiges undefiniertes Vorfinden
und nur den short (16-bit) hinschreiben.
Dennis H. schrieb:> Ist der falsche Diassembler. Ist kein ARMv4Thumb sondern ARMv7Thumb.
Wurde ja schon angefragt, was für Programme verwendet wurden.
Der TO schweigt dazu. Zeitverschwendung.
An Dennis H. (den einzigen der Hilfreiches gepostet hat)
Besten Dank, ich habe inzwischen rausgefunden das die neuste objdump
Routine anscheinend richtig arbeitet. Vermutlich war die alte objdump
Routine nur für ARMv4Thumb richtig, wie Du bemerkt hast.
Martin O. schrieb:> An Dennis H. (den einzigen der Hilfreiches gepostet hat)> Besten Dank, ich habe inzwischen rausgefunden das die neuste objdump> Routine anscheinend richtig arbeitet. Vermutlich war die alte objdump> Routine nur für ARMv4Thumb richtig, wie Du bemerkt hast.
Bei binutils, die Code für unterschiedliche Prozessoren einer Familie
erzeugen können, muss man objdump (mit --architecture) u.U. mitgeben,
für welche Variante disassembliert werden soll (das ist dem .elf-File
nicht notwendigerweise zu entnehmen).
Wahrscheinlich hat dein neueres objdump nur andere Defaults.
Martin O. schrieb:> An Dennis H. (den einzigen der Hilfreiches gepostet hat)> Besten Dank, ich habe inzwischen rausgefunden das die neuste objdump> Routine anscheinend richtig arbeitet. Vermutlich war die alte objdump> Routine nur für ARMv4Thumb richtig, wie Du bemerkt hast.
Wieder was gelernt: Man darf nicht die alte objdump benutzen.
Es muss die neueste sein.
S. R. schrieb:> .. schrieb:>> Wieder was gelernt: Man darf nicht die alte objdump benutzen.>> Es muss die neueste sein.>> Falsch: Es muss die richtige (passende) sein.
Neinneinnein!
Nach dem ich ja schon die Version der Tools angefragt habe, und dieser
Beitrag, wie der anderer Leute, vom TO als nicht hilfreich bezeichnet
wurde, dazu keinerlei Infos vom TO kamen, und als Endlösung dann, das
"alte" müsste gegen das "neusten" objdump ersetzt werden, wuss das
prezise und zwingend richtig sein! ;)