In einem compilat hat folgende (disassemblierte) Instruktion LDR R5, =0xFC0000000 nur 2 Byte Länge und die Opcodes lauten "4D A9" (Hex). Wie erklärt sich das? Ich vermute das der eigentliche 4 Byte Wert an einer anderen Speicheradresse liegt und der CPU mit den 2 Bytes neben dem Befehl auch noch der Offset auf diese Speicheradresse mitgegeben wird und der sich dort gefundene Werte im Disassembler mit "=" darstellt, also indirekt.
PC-relative Adressierung, die Konstante liegt dann irgendwo in der Nähe. Das ist nur ein pseudo-Befehl, dahinter verbirgt sich ein "LDR <Rd>, [PC, #immed8]".
Sowas habe ich mir ja auch schon gedacht, aber ganz konkret, WO? Das nächste Vorkommen von FC 00 00 00 als Bytesequenz (big endian) ist an Adresse 0x000013BC, also 0x2A8 Bytes entfernt. Ich hatte gehofft jemand könnte anhand der Opcodes erklären wie es dazu kommt. Und was bitte ist ein Pseudo-Befehl? Sowas kennt doch maximal Assembler aber nicht die CPU?
Olli Z. schrieb: > Das nächste Vorkommen von FC 00 00 00 als Bytesequenz (big endian) ist > an Adresse 0x000013BC, also 0x2A8 Bytes entfernt. Da der Befehl Worte adressiert, reicht eine imm8 Distanz 256 Worte weit, also 1kB. > Und was bitte ist ein Pseudo-Befehl? Sowas kennt doch maximal Assembler > aber nicht die CPU? Diese Notation erleichtert das Verständnis des Codes erheblich.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Olli Z. schrieb: >> Das nächste Vorkommen von FC 00 00 00 als Bytesequenz (big endian) ist >> an Adresse 0x000013BC, also 0x2A8 Bytes entfernt. > > Da der Befehl Worte adressiert, reicht eine imm8 Distanz 256 Worte weit, > also 1kB. AAH! Das ist nicht ein Byte-Offset, sondern ein WORD-Offset?! Aber dann passt das mit 1k nicht. Ich denke Du meinst wohl eher ein DWORD, also 4 Bytes? >> Und was bitte ist ein Pseudo-Befehl? Sowas kennt doch maximal Assembler >> aber nicht die CPU? > Diese Notation erleichtert das Verständnis des Codes erheblich. Ok, also macht der Disassembler aus dem eigentlichen Befehl dann diese Notation mit dem "=" und zeigt mir damit an das im Endeffekt dieser Wert geladen wird, als wäre es ein immediate value, richtig? Dennoch meine Frage wie sich die Opcode-Bytes zusammensetzen, vielleicht auch anhand dieser Tabelle? http://imrannazar.com/arm-opcode-map Was bedeutet die Bytefolge 0x4D und 0xA9 für die CPU genau?
Olli Z. schrieb: > Ich denke Du meinst wohl eher ein DWORD, also 4 Bytes? ARM ist nicht von Intel. Ein (Maschinen-)Wort ist 4 Bytes gross, ein Halbwort 2 Bytes. Gewöhne dich lieber dran.
(prx) A. K. schrieb: > Olli Z. schrieb: >> Ich denke Du meinst wohl eher ein DWORD, also 4 Bytes? > > ARM ist nicht von Intel. Ein (Maschinen-)Wort ist 4 Bytes gross, ein > Halbwort 2 Bytes. Gewöhne dich lieber dran. Hm, ich dachte diese "Varianz" gäbe es nur bei höheren Instanzen wie INT usw. Ein Byte ist für mich immer 8 Bit, ein Word immer 16 Bit und ein Double immer 32 Bit. Bislang dachte ich das seit unabhängig von der CPU Architektur.
Angehängte Dateien:
Olli Z. schrieb: > Was bedeutet die Bytefolge 0x4D und 0xA9 für die CPU genau? 0xA9 * 4 = 0x2A4. Für die Rechnung siehe Bild.
Olli Z. schrieb: > Hm, ich dachte diese "Varianz" gäbe es nur bei höheren Instanzen wie INT > usw. Ein Byte ist für mich immer 8 Bit, ein Word immer 16 Bit und ein > Double immer 32 Bit. Bislang dachte ich das seit unabhängig von der CPU > Architektur. Die vor dir als universell gesehenen Begriffe sind das keineswegs, sondern gelten in dieser Form zunächst nur für x86 und Nachfolger. Bei anderen Architekturen kann es anders sein.
:
Bearbeitet durch User
Ich hoffe ich liege richtig das eine ARM-Instruction immer mindestens 32 Bit lang sein müsste? Ist die obige 2-Byte Sequenz also evtl. ein Thumb-Befehl?
(prx) A. K. schrieb: > 0xA9 * 4 = 0x2A4. Für die Rechnung siehe Bild. Ok! also ist 0x2A4 der Offset, relativ vom PC (auf ARM Word-Boundary) vom PC nach ausführen des Befehls, was dann zum eigentlichen Offset 0x2A8 führt?
(prx) A. K. schrieb: > Olli Z. schrieb: >> Ist die obige 2-Byte Sequenz also evtl. ein Thumb-Befehl? > Ist sie. Siehe Bild. Woran hast Du das jetzt erkannt? Nur an der Tatsache das es 2 Byte Instruktion waren?
Das ARM ARM für ARMv7-M gibts hier: https://developer.arm.com/documentation/ddi0403/ee Da du den Prozessor nicht genannt hast, muss ich allerdings raten und tippe auf Cortex-M3 aufwärts. Beim Cortex M1 wäre ARMv6-M richtig, bei ARM7 ARMv5 usw.
:
Bearbeitet durch User
Olli Z. schrieb: > Hm, ich dachte diese "Varianz" gäbe es nur bei höheren Instanzen wie INT > usw. Ein Byte ist für mich immer 8 Bit, ein Word immer 16 Bit und ein > Double immer 32 Bit. Bislang dachte ich das seit unabhängig von der CPU > Architektur. Das ist abhängig vom jeweiligen Sprachgebrauch und damit lediglich eine Konvention zum gegenseitigen Verstehen. Quasi abhängig vom Stallgeruch. Mir ist das zuerst bei den FR30 von Fujitsu aufgestoßen, dort bin ich dann zuerst über Worte wie WORD und HWORD gestolpert, die einfach nur DWORD und WORD bedeuten - jedenfalls wenn man nicht nur Mikrocontroller von Fujitsu oder ARM programmiert, sondern auch noch etwas am PC zu tun hat. Diese jeweiligen und unterschiedlichen Sprachgebräuche sind extrem störend, wenn man dazwischen mental umschalten muß, deshalb habe ich für mich mit dem WORD und HWORD Gefummel erst gar nicht angefangen, sondern meine vom PC aus geläufigen Begriffe BYTE, WORD und DWORD einfach auch auf die Mikrocontroller-Szene angewendet. Das hat sich bislang bestens bewährt, lediglich beim Lesen der Dokumente von ARM (Fujitsu hat ja seine gesamte µC-Sparte verkauft) muß man dran denken, daß die mit WORD eben ein DWORD (also 32 Bit) meinen. Aber da dies seltener vorkommt als das Lesen in den eigenen Quellen und Zeugs aus der PC-Gegend, ist es so herum für mich deutlich besser. Man muß sich nicht an alles und jedes gewöhnen. Punkt. W.S.
(prx) A. K. schrieb: > Ja Das bezog sich darauf: Olli Z. schrieb: > Ok! also ist 0x2A4 der Offset, relativ vom PC (auf ARM Word-Boundary) > vom PC nach ausführen des Befehls, was dann zum eigentlichen Offset > 0x2A8 führt?
W.S. schrieb: > wenn man dazwischen mental umschalten muß Ich habe nie ein Problem damit gehabt, Architekturbezogene Bezeichnungen auf die Architektur zu beziehen. Schwieriger fände ich es, immer wieder zwischen meinen eigenen abweichenden Bezeichnungen und jenen in Lektüre und Programmen Anderer übersetzen zu müssen. Also ob im Kontext von ARM als Wort nun 2 oder 4 Bytes gemeint seien. Maschinenworte konnten auch 12, 18, 36, 48, 50, 52 und 60 Bits breit sein.
:
Bearbeitet durch User
Olli Z. schrieb: > Ich hatte gehofft jemand könnte anhand der Opcodes erklären wie es dazu > kommt. > Und was bitte ist ein Pseudo-Befehl? Sowas kennt doch maximal Assembler > aber nicht die CPU? Es soll von ARM eine (kostenlos erhältliche) Doku geben: z. B. DDI 0419C, "A6.7.27 LDR (literal)" Da gibt's nichts weiter zu erklären, man muss halt einfach mal lesen ...
Olli Z. schrieb: > Hm, ich dachte diese "Varianz" gäbe es nur bei höheren Instanzen wie INT > usw. Ein Byte ist für mich immer 8 Bit,... Selbst DAS ist schon nicht richtig. Meist ja, aber immer? Nein. Du meinst vermutlich das Oktett, das hat wirklich immer 8 Bit.
(prx) A. K. schrieb: > Maschinenworte konnten auch > 12, 18, 36, 48, 50, 52 und 60 Bits breit sein. oder 24-Bit Worte mit 6 Bit pro Byte https://en.wikipedia.org/wiki/ICT_1900_series#Data_formats
(prx) A. K. schrieb: > Ich habe nie ein Problem damit gehabt... Schön für dich. Aber wir sind zwei verschiedene Leute. W.S.
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.