Assembler Frage ( 2mal hintereinander dieselbe Instruktion )

[Espen A. (espen)]

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

[(prx) A. K. (prx)]

Assembler-Quellcode? Bei disassembliertem Code können es mitten drin 
eingebettete Daten sein, oder Füllbytes für Alignment.

[Gerald K. (geku)]

Espen A. schrieb:
> Was soll so etwas?

Ergibt eine Zeitverzögerung, oder es war ein Copy/Past Fehler.

[Espen A. (espen)]

"Bei disassembliertem Code"
Das könnte es tatsächlich sein, da muss ich mal forschen. Danke!

[ARM007 (Gast)]

> ... Assemblerstrecke ...

Wo kommt die her? Welcher Prozessor?

[Espen A. (espen)]

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.

[Espen A. (espen)]

>würde ich sagen MCS-51
nönönö ist ein 32bitter.

[(prx) A. K. (prx)]

Espen A. schrieb:
> und der wird auch ausgeführt, ich hab da reingebreakt.

Schreib die Adressen dazu. Sprungziel dahinter?

[Espen A. (espen)]

08005858:   cmp     r0, #0
0800585a:   cmp     r0, #0

[(prx) A. K. (prx)]

Alignment fällt aus.

[Espen A. (espen)]

"Bearbeiten" scheint nicht zu funktionieren. Dann kommt
0800585c:   bne.n   0x800584c

Gibt es nicht vielleicht so einen allgemeinen Grund "wie flush buffer" 
oder so?

[(prx) A. K. (prx)]

Rück halt etwas mehr Kontext raus, deine Salamischeiben sind zu dünn.

[Espen A. (espen)]

>"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 )

 8005844:  463a        mov  r2, r7
 8005846:  2101        movs  r1, #1
 8005848:  f3bf 8f5b   dmb  ish
 800584c:  e852 3f00   ldrex  r3, [r2]
 8005850:  2b00        cmp  r3, #0
 8005852:  d104        bne.n  800585e <main+0x66>
 8005854:  e842 1000   strex  r0, r1, [r2]
 8005858:  2800        cmp  r0, #0
 800585a:  2800        cmp  r0, #0
 800585c:  d1f6        bne.n  800584c <main+0x54>
 800585e:  f3bf 8f5b   dmb  ish
 8005862:  60bb        str  r3, [r7, #8]

Mod: Formatierung angepasst.

[(prx) A. K. (prx)]

Espen A. schrieb:
> Gibt es nicht vielleicht so einen allgemeinen Grund "wie flush buffer"
> oder so?

Das sind die DMB Befehle davor und dahinter.

[Spätz-Jalist (Gast)]

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

[Gerald K. (geku)]

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?

[(prx) A. K. (prx)]

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.

[Gerald K. (geku)]

(prx) A. K. schrieb:
> nutzt es aber nicht als Input

Wird es für den Größer/Kleinervergleich nicht benutzt?

[Espen A. (espen)]

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:

80039d8:  bf00        nop
    val = __sync_val_compare_and_swap( &lock,0,1 );
 80039da:  2601        movs  r6, #1
 80039dc:  f3bf 8f5b   dmb  ish
 80039e0:  e854 2f00   ldrex  r2, [r4]
 80039e4:  42aa        cmp  r2, r5
 80039e6:  d103        bne.n  80039f0 <main+0x5c>
 80039e8:  e844 6300   strex  r3, r6, [r4]
 80039ec:  2b00        cmp  r3, #0
 80039ee:  d1f7        bne.n  80039e0 <main+0x4c>
 80039f0:  f3bf 8f5b   dmb  ish
    __ASM( "nop" );
 80039f4:  bf00        nop

Das sieht für mich proper aus.
Dies nur zur Info und die nops sind natürlich von mir.

Mod: Formatierung angepasst.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

Espen A. schrieb:
> __sync_val_compare_and_swap

Davon könnte der Sourcecode interessant sein.

[Frank M. (ukw) (Moderator)]

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.

[Espen A. (espen)]

(prx) A. K. schrieb:
> Davon könnte der Sourcecode interessant sein.

Ich hab ihn nicht, versuch ihn zu kriegen, kann aber dauern.

[Hp M. (nachtmix)]

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.

[Programmierer (Gast)]

Unoptimierter Assembler-Code enthält jede Menge redundanten Blödsinn. Es 
ist ziemlich nutzlos, sich solchen Code anzusehen.