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.
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.
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 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.
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.
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.
