Werte Leser, ich bin mir nicht ganz sicher, ob hier das richtige Forum ist, aber es scheint mir das am wenigsten falsche zu sein ;) Ich habe eine Assemblerstrecke da taucht zweimal direkt hintereinander dieselbe Instruktion auf. So sieht das aus: cmp r0,#0 cmp r0,#0 Ich habe auch geguckt, ob da ein Sprunglabel ist. Ist aber nicht. Was soll so etwas? Gruß Espen
Assembler-Quellcode? Bei disassembliertem Code können es mitten drin eingebettete Daten sein, oder Füllbytes für Alignment.
Espen A. schrieb: > Was soll so etwas? Ergibt eine Zeitverzögerung, oder es war ein Copy/Past Fehler.
"Bei disassembliertem Code" Das könnte es tatsächlich sein, da muss ich mal forschen. Danke!
Gast
#6723756
> ... Assemblerstrecke ...
Wo kommt die her? Welcher Prozessor?
Das ist ein arm compiler für einen STM32F4. Und jetzt habe ich mir auch den Hexcode angeguckt und der sieht so aus: 2800 cmp r0,#0 2800 cmp r0,#0 und der wird auch ausgeführt, ich hab da reingebreakt.
Beitrag #6723767 wurde von einem Moderator gelöscht.
>würde ich sagen MCS-51
nönönö ist ein 32bitter.
Espen A. schrieb: > und der wird auch ausgeführt, ich hab da reingebreakt. Schreib die Adressen dazu. Sprungziel dahinter?
08005858: cmp r0, #0 0800585a: cmp r0, #0
Alignment fällt aus.
"Bearbeiten" scheint nicht zu funktionieren. Dann kommt 0800585c: bne.n 0x800584c Gibt es nicht vielleicht so einen allgemeinen Grund "wie flush buffer" oder so?
Rück halt etwas mehr Kontext raus, deine Salamischeiben sind zu dünn.
>"Rück halt etwas mehr Kontext raus, deine Salamischeiben sind zu dünn."
Ich hab nur die Codestrecke von __sync_val_compare_and_swap( &lock,0,1 )1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Mod: Formatierung angepasst.
Espen A. schrieb: > Gibt es nicht vielleicht so einen allgemeinen Grund "wie flush buffer" > oder so? Das sind die DMB Befehle davor und dahinter.
Gast
#6723978
>> Assembler Frage ( 2mal hintereinander dieselbe Instruktion )
Das ist für den Fall, das der Prozessor den Befehl beim ersten Mal nicht
verstanden hat. Er legt dann die Frage "Hä?!" auf den Datenbus.
Könnte es, dass der Grund mit dem Carry-Flag zu tun hat? https://stackoverflow.com/questions/44620368/cmp-and-carry-flag CMP verwendet das Carry-Flag und setzt dieses wiederum. Daher müssen die Flags beim ersten und zweiten CMP Aufruf nicht gleich sein, oder irre ich mich?
CMP setzt das C Flag, nutzt es aber nicht als Input. Das tut SBC, Subtraktion mit Carry. Die Semaphor-Operation hier findet sich in Varianten auch in etlichen Beispielen, dort aber mit einem CMP. Zu einem Fehler des Cortex Core bei STREX fand ich auch nichts.
(prx) A. K. schrieb: > nutzt es aber nicht als Input Wird es für den Größer/Kleinervergleich nicht benutzt?
Erstmal besten Dank für die bisherige Unterstützung, wenn ich auch nicht immer alles verstehe. Die obige Codestrecke ist das Kompilat ohne Optimierung. Wenn ich mit -Os kompiliere, fehlt der doppelte Vergleich und diese Codestrecke wird generiert:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
Das sieht für mich proper aus. Dies nur zur Info und die nops sind natürlich von mir. Mod: Formatierung angepasst.
Gerald K. schrieb: > (prx) A. K. schrieb: >> nutzt es aber nicht als Input > > Wird es für den Größer/Kleinervergleich nicht benutzt? Nicht als Input zu CMP, nur als Output.
Espen A. schrieb: > __sync_val_compare_and_swap Davon könnte der Sourcecode interessant sein.
Espen A. schrieb: > Wenn ich mit -Os kompiliere, fehlt der doppelte Vergleich und diese > Codestrecke wird generiert: Bitte zukünftig die Code-Teile in [ code ] ... [ /code ] (ohne Leerzeichen) einpassen, sonst steht das auf Mobilteilen alles in einer Zeile und wird dadurch unleserlich. Ich habe die oben stehenden Beiträge mal angepasst. Bitte zukünftig selber machen. Danke.
(prx) A. K. schrieb: > Davon könnte der Sourcecode interessant sein. Ich hab ihn nicht, versuch ihn zu kriegen, kann aber dauern.
Espen A. schrieb: > Die obige Codestrecke ist das Kompilat ohne Optimierung. > Wenn ich mit -Os kompiliere, fehlt der doppelte Vergleich Da hatte der Compiler ursprünglich wohl zwei Codefragmente aneinandergekleistert, von denen das erste mit dem CMP aufhört, als Vorbereitung darauf was meist folgt, z.B. RET mit gesetzten Flags, und einem zweiten Fragment, das mit der Abfrage auf 0 beginnt, weil sofort danach die Verzweigung erfolgt. Schadet ja nichts. Der Optimizer hat das dann bemerkt und den ersten CMP entfernt. P.S.: Dass die optimierte Version andere Register verwendet, dürfte daran liegen, dass der Optimizer vorher schon manche überflüssigen Umladungen entfernt hat.
Gast
#6743368
Unoptimierter Assembler-Code enthält jede Menge redundanten Blödsinn. Es ist ziemlich nutzlos, sich solchen Code anzusehen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.