Hi, ich versuche gerade zu verstehen, wie der Controller den Weg zur main() findet. Nach einem Reset wird der resethandler aufgerufen, an dessen Ende die main aufgerufen wird. Im assembly sieht das ganze so aus: 0x080001de: bl 0x8000430 <main> An der Adresse 0x080001de liegen die Daten, die als og Befehl interpretiert werden: F927F000 Nun habe ich in der architecture reference manual (http://www.pjrc.com/arm/pdf/doc/DDI0403D_arm_architecture_v7m_reference_manual.pdf, S. A7-248) nach bl geschaut und den syntax vor mir liegen. Das Feld imm10 ist null, das Feld imm11 enthält 227h. F |9 |2 |7 |F |0 |0 |0 1111.1010.0010.0111|1111.0000.0000.0000 ......xxx xxxx xxxx........yy yyyy yyyy x = imm11 y = imm10 Wie kommt nun der ARM dazu, von 0x080001de nach 0x8000430 zu springen? 1deh + 227h = 405h. Bis zur 430h fehlt noch ein Stück. Wie ist der Befehl bl händisch nachzurechnen? Aus der manual werd ich nicht schlau.
Wenn das Wort nicht verdreht dargestellt ist, dann steht der Opcode 1111101* nicht für BL, sondern für "data processing".
Stimmt, das eine Bit ist eine Null.. Das ändert jedoch nichts an dem Inhalt von imm11. Der Befehl bl stimmt auch, denn so wird es mir im disassembly von coocox angezeigt.
Aber nun versteh ich erst recht nicht, wie der Controller die Adresse 0x8000430 aus den gegebenen Daten berechnet.
Was immer das ist: Der Opcode von BL fängt mit 1111.0 an (F0-F7), nicht mit 1111.1 (F8-FF). Wenn das BL ist, dann muss es verdreht dargestellt sein, F000F927.
gibt noch mal den genauen hex string an. Wir reden von dem Befehl von Seite A7-248? XXX und YYY sind verdeht. wie hast du die werte ausgelesen. 16 bit / 32 bit? Ich hab irgendwie das gefühl du dekodierst da die falschen bytes. was kommt nach 0xF000?
Jap, ist verdreht dargestellt. Im Speicher an der Adresse 0x080001de steht folgendes (Auszug ausm HEXeditor): 00 F0 27 F9 Somit ist 00 das LSB und F9 das MSB?! Richtig rum steht da also F927F000, oder nicht? Und so sollte das auch als 32BitBefehl interpretiert werden, nicht wahr?
Und da im Disassembler BL steht und ich dem DA glaube, muss F927F000 irgendwie mit dem Muster des BL-Befehls zusammenpassen. Eine andere Datei lieferte mir an der Stelle FA73F000, weswegen ich die 2 Bytes gedreht habe, da es sonst nicht ins Muster passt. F0 = 11110000 FA = 11111010
Vorsicht Falle. Thumb-Befehle sind halbwortweise angeordnet, nicht wortweise. Auch wenn sie 32 Bits lang sein sollten. Das erste Halbwort signalisiert ggf dass es ein 32-Bit Befehl ist. Somit steht das linke Halbwort vor dem rechten im Speicher. Deshalb sind die Bits in der Ref mit 15...0 15...0 nummeriert, nicht 31...0. 00 F0 27 F9 ist also F000.F927.
Also habe ich es richtig dekodiert? Zuerst kommt F000 (das ist das erste Halbwort), dann kommt F927?
Gut, dann bleibt also die Frage, wie der Controller die Adresse 0x8000430 berechnet? PC-relativ, das ist klar. Im PC steht 080001de
080001de + 127 * 2 + 4 (allex hex, Die letzte 4 weil der PC schon weiter ist)
Also weiter im Text. F000.F927:
S = 0
imm10 = 0
J1 = 1
J2 = 1
imm11 = 127
Disp: 0.1.1.000000000.0100100111
1 8 0 1 2 7
also 0018.0127
080001de + 4 + 180127*2 = 0830.0430
Passt nicht, also sind J1:J2 Käse und es ist nicht Thumb2 sondern
Thumb1.
OK, die 127 ist auch klar, die steht in imm11. Aber woher kommt die *2? Und die 4 ist auch nicht ganz klar.
0xF000F927 S = 0 I1 = 0 I1 = 0 imm10 = 00 0000 0000 imm11 = 001 0010 0111 => 0 0 0 0000000000 00100100111 0 PC + 0x252 + 2 * 2 der befehlt besteht ja 2 16bit worten
Fritz schrieb: > OK, die 127 ist auch klar, die steht in imm11. Aber woher kommt die *2? > Und die 4 ist auch nicht ganz klar. Branches gehen von PC+4 aus und Displacements werden mit 2 multipliziert, da es keine ungeraden Ziele geben kann.
123 schrieb: > da steht I1 = not (Xor (S,J1)) > gemein geimein Anders war die Kompatiblität zu Thumb nicht zu machen.
Gut, ich habs gleich. Bin jetzt auch für imm32 bei 24e. Im manual steht PC = PC + imm32. An dieser Stelle ist PC noch immer 080001de ? Nun bleibt noch die Frage, woraus ersichtlich wird, dass man da noch was addieren muss.
Fritz schrieb: > Im manual steht PC = PC + imm32. An dieser Stelle ist PC noch immer > 080001de ? Nein, eben nicht. > Nun bleibt noch die Frage, woraus ersichtlich wird, dass man da noch was > addieren muss. Ich weiss grad nicht wo das in der Ref steht, aber bei ARMs steht der PC am Anfang der Befehlsausführung immer auf addr+4, und zumindest bei nativen ARMs manchmal auch auf addr+8.
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.