Debugging mit bedingten Befehlen auf ARM-CPUs - EuE24.net

MIKROCONTROLLER & PROZESSOREN
E&E PRODUCTS & SOLUTIONS
Debugging mit bedingten
Befehlen auf ARM-CPUs
Bedingte Befehle eröffnen Entwicklern neue, weit reichende
Möglichkeiten beim Software-Debugging
B.01
Die typischen Debug-Funktionen
beim Entwickeln und Testen von
Software heißen Breakpoint und
Single-Step. Beim Debuggen von
ARM-Prozessoren macht sich die
spezielle Eigenschaft des Befehlssatzes
bemerkbar: Jeder Befehl
kann bedingt ausgeführt werden.
Dies kann zu einem für den
Entwickler zunächst unerwarteten
Programmablauf führen, der
jedoch durch Software-Debug-
Tools automatisch erkannt und
angezeigt werden kann.
PETER SAUER
D
ie Programmablauf-Prüfung mit
den Funktionen Breakpoint und
Single-Step kann bei ARM-Prozessoren
zu unerwarteten Ergebnissen
führen. Die Eigenschaft, dass alle Befehle
bedingt ausgeführt werden können, wird von
den üblichen C-Compilern zur Code-Optimierung
benutzt. Dabei zeigt sich ein Verhalten,
dass z.B. bei „if-then-else“-Konstrukten
scheinbar immer beide Pfade durchlaufen
A U T O R
Dr. PETER SAUER
Manager Product Marketing
peter.sauer@hitex.de
Hitex Development Tools GmbH
Greschbachstr. 12
76229 Karlsruhe
T +49/721/9628-0
F +49/721/9628-149
Dem 28-Bit-Assembler opcode ist ein vier
Bit langer Code für die Bedingung cond anwerden,
unabhängig von der „if“-Bedingung.
Bei näherer Betrachtung des generierten Assembler-Codes
wird das Verhalten jedoch verständlich
und der vermeintliche Fehler entpuppt
sich als korrekter Vorgang.
Die Software-Debug-Tools können dieses
Verhalten automatisch berücksichtigen und
dem Entwickler beim Debuggen den aktuellen
Status mit einfachen Symbolen anzeigen.
Der ARM-Befehlssatz
Die typische RISC-Architektur eines ARM-
Prozessors [1] zeichnet sich aus durch
eine große Zahl einheitlicher Register,
eine Load-Store-Architektur, nur unter
Verwendung der Register-Inhalte,
einfache Adressierungsverfahren und
einheitliche und gleichlange Befehlsworte.
Daneben weist die ARM-Architektur die
spezielle Eigenschaft auf, dass die Befehlsausführung
bedingt erfolgen kann und zwar
abhängig vom Zustand der Flags im Statusregister.
Die gängigen Compiler, u.a. der GNU
Compiler, nutzen dies aus und erzeugen
u.U. einen optimierten Code. Besonders bei
Anweisungen mit einfachen „if-then-else“-
Konstrukten werden die bedingten Befehle
anstelle von Programmverzweigungen mit
Sprungbefehlen verwendet.
Der ARM-Befehlssatzes ist aus gleichlangen
und gleich aufgebauten Feldern zusammengesetzt,
die eine effiziente Dekodierung des
Befehls ermöglichen. Der Aufbau eines 32-
Bit-Befehlswortes ist wie folgt:
31 27 0
cond
opcode
E&E KOMPENDIUM 2005/2006
91

E&E PRODUCTS & SOLUTIONS
MIKROCONTROLLER & PROZESSOREN
B.01
gefügt. Das Feld cond bestimmt hierbei, abhängig
von den Flags N, Z, C und V im Statusregister
CPSR, ob der Befehl ausgeführt
wird oder nicht. Für die Bedingungen ergeben
sich damit insgesamt 16 Fälle:
Die Mnemonic-Erweiterung wird hierbei an
den Assembler-Befehl angehängt, wobei für
Befehle ohne Bedingung die Erweiterung al
in der Regel entfällt. Für den Befehl
add r2, r2, #1 ; inkrementiere Register r2
ergibt sich im Falle der Bedingung „Ausführen
bei Gleichheit“ Z=1 der Befehl
addeq r2, r2, #1 ;
inkrementiere Register r2 wenn Z=1.
Im Falle von Z=0 wird r2 nicht inkrementiert.
Im folgenden Abschnitt werden Beispiele
angeführt.
C-Code versus Assembler-Code
Beispiel 1
# “C” Code ARM Assembler
Code
1 if (index < counter) ldrh r2, [r5]
2 { ldrh r3, [r4, #00h]
cmp r2, r3
3 buffer1 = index; movcc r7, r2
4 }
5 else
6 {
7 buffer2 = index+1; ldrcs r3, [pc, #1ch]
ldrcsb r6, [r3]
addcs r6, r6, #1h
9 }
Abb. 1:
Den „bedingten“
Breakpoint, erkennt
man am Fragezeichen
im Punkt, den unbedingten
Breakpoint
am Punkt
Hier werden drei Beispiele für bedingte Anweisungen
in C- und Assembler-Code gezeigt.
Der C-Code wurde dabei mit einem
ARM-GNU-Compiler übersetzt. Die den C-
Anweisungen entsprechenden Assembler-
Instruktionen sind zur Verdeutlichung in
Gruppen zusammengefasst. Ein einfaches
Beispiel für eine „if-then-else“-Bedingung in
C und Assembler zeigt Beispiel 1.
Diese in C absolut übliche Konstruktion
einer Abfrage erzeugt im Assembler-Code
eine lineare Abfolge von Befehlen ohne
Sprünge. Abhängig vom Carry-Flag werden
die Befehle ausgeführt oder nicht (ersichtlich
an den Mnemonic-Erweiterungen cc
und cs, siehe vorherige Tabelle). Der Vorteil
ist eine konstante Laufzeit des Codes, unabhängig
von der Gültigkeit der Abfrage-
Bedingung in Zeile #1. Es werden immer
sowohl der „if“-Zweig als auch der „else“-
Zweig durchlaufen.
Für Prozessoren ohne bedingte Befehle werden
Assembler-Anweisungen generiert, die
die „if-then-else“-Pfade über Sprungbefehle
erreichen. Dazu wird nach der Abfrage der
Bedingung in Zeile #1 ein bedingter Sprung
eingefügt, und im „if“-Zweig der „else“-
Zweig übersprungen und umgekehrt. Dies
ist in Beispiel 2 zu sehen. Hier wird der Programmablauf
durch Sprünge gesteuert,
womit die Laufzeit vom durchlaufenen Pfad
abhängt. Dies ist an der Anzahl der ausgeführten
Befehle leicht zu erkennen (Vergleich
der Zeilen #3 und #7).
Beispiel 3 zeigt, wie durch eine zusätzliche
Abfragebedingung im Beispiel 1 ein ARM
Assembler-Code wie bei Beispiel 2 erzeugt
wird. Hier wird der Programmablauf ebenfalls
durch Sprünge gesteuert.
Die Zeilen #7 aller Beispiele erzeugen dieselbe
Folge von Assemblerbefehlen, mit dem
Unterschied, dass sie in Beispiel 1 bedingt
ausgeführt werden, während sie in Beispiel 2
und 3 immer (Bedingung „Always“, siehe
vorherige Tabelle) ausgeführt werden. Die
Mnemonic-Erweiterung wird hierbei, wie
bereits erwähnt, nicht angezeigt.
Für den Software-Entwickler ist damit nicht
unbedingt zu erkennen, welcher Programmcode
erzeugt wird und wie das Laufzeitverhalten
sein wird. Der generierte ARM-Assembler-Code
hängt im Wesentlichen davon
ab, wie komplex die Anweisungen in der
„if“-Bedingung und innerhalb der beiden
Pfade sind und welche Register zur Verfügung
stehen.
Debug-Problematik
Das Debuggen solcher Programmabläufe
mit Breakpoints führt zu unterschiedlichen
Resultaten:
Bei einem Breakpoint in Zeile #7 des C-Codes
wird eine Programmunterbrechung erwartet,
falls die Bedingung in Zeile #1 nicht erfüllt ist.
Für die Beispiele 2 und 3 trifft dies zu. In Beispiel
1 jedoch wird die Programmausführung
in jedem Fall in Zeile #7 angehalten, da immer
beide Zweige durchlaufen werden. Was
Beispiel 2
# “C” Code ARM Assembler
Code
1 if (index < counter) ldrh r2, [r5]
2 { ldrh r3, [r4, #00h]
cmp r2, r3
bcs #else
3 buffer1 = index; mov r7, r2
ble #end
4 }
5 else #else
6 {
7 buffer2 = index+1; ldr r3, [pc, #1ch]
ldrb r6, [r3]
add r6, r6, #1h
9 } #end
Beispiel 3
# “C” Code ARM Assembler
Code
1 if ((index < counter) && ldrh r2, [r5]
(buffer1+buffer2 < 25)) ldrh r3, [r4, #00h]
2 { cmp r2, r3
bcs #else
add r3, r7, r6
cmp r3, #18h
movle r7, r2
ble #end
3 buffer1 = index;
4 }
5 else #else
6 {
7 buffer2 = index+1; ldr r3, [pc, #1ch]
ldrb r6, [r3]
add r6, r6, #1h
9 } #end
92
www.EuE24.net

MIKROCONTROLLER & PROZESSOREN
E&E PRODUCTS & SOLUTIONS
aus Sicht des C-Codes als fehlerhaftes Verhalten
erscheint, wird nur durch einen Blick auf
den Assembler Code verständlich. Der Software-Entwickler
muss sich hier versichern,
ob der Befehl ausgeführt wird oder nicht, d.h.
er muss den Zustand der Flags für den jeweiligen
Assembler-Befehl prüfen (siehe vorherige
Tabelle). Er muss sich also dessen bewusst
sein, dass dieses Stück Programmcode immer
durchlaufen wird.
Software-Debug-Tools können hier sehr hilfreich
sein. Durch Prüfen der Status-Flags, die
für den Assemblerbefehl an der Stelle des
Breakpoints relevant sind, kann das Debug-
Tool entscheiden, ob der Befehl ausgeführt
wird oder nicht. Wenn der Befehl ausgeführt
wird, bleibt der Programmablauf gestoppt.
Andernfalls wird das Programm wieder gestartet.
Die Programmausführung erfolgt
dann mit einem kleinen zeitlichen Versatz, der
für die Prüfung der Status-Flags benötigt wird.
Im Single-Step-Betrieb sind Debug-Tools
ähnlich hilfreich, da die manuelle Auswertung
der Status Flags entfällt. Gelbe und rote
Pfeile zeigen dem Entwickler unmittelbar
an, ob der nächste Befehl ausgeführt wird
oder nicht.
Abbildung 1 zeigt das HiTOP5 Software-
Debug-Tool mit einem so genannten „bedingten“
Breakpoint, erkenntlich am Fragezeichen
im Punkt, und mit einem unbedingten Breakpoint,
erkenntlich am Punkt. Im mittleren
Fenster zeigt ein Pfeil die aktuelle Position des
Programmzählers pc für den nächsten auszuführenden
Befehl
nicht ausgeführt werden wird, da das zugehörige
Carry-Flag C=1 gesetzt sein wird
(mit r2=r3). Damit wird der Programmablauf
fortgesetzt und der Breakpoint ignoriert.
Fazit
Tabelle: ARM Befehlserweiterungen
Cond Mnemonic Beschreibung Status Flags
[31:27] Erweiterung
0000 eq Equal Z=1
0001 ne Not Equal Z=0
0010 cs/hs Carry Set / Unsigned C=1
Higher or Same
0011 cc/lo Carry Clear / Unsigned Lower C=0
0100 mi Minus / Negative N=1
0101 pl Plus / Positive or Zero N=0
0110 vs Overflow V=1
0111 vc No Overflow V=0
1000 hi Unsigned Higher C=1 und Z=0
1001 ls Unsigned Lower or Same C=0 und Z=1
1010 ge Signed Greater Than or Equal N=1 und V=1 oder
N=0 und V=0
1011 lt Signed Less Than N=1 und V=0 oder
N=0 und V=1
1100 gt Signed Greater Than Z=0 und (N=1 und =1)
oder N=0 und V=0
1101 le Signed Less Than or Equal Z=1 oder N=1 und V=0
oder N=0 und V=1
1110 al Always --
1111 nv Never --
die Optimierungen der C-Compiler lässt
sich somit sinnvoll in die Debug-Tools integrieren.
Literatur
[1] Advanced RISC Machines. Architectural Reference
Manual. ARM, DDI 0100B, 1996
cmp
r2,r3
Eine automatische Analyse der Status Flags
erleichtert dem Software-Entwickler das Debuggen
Dieser Beitrag als PDF und weiterführende
an. Weiterhin erkennt man, dass der Befehl
an der Stelle des bedingten Breakpoints
seiner Anwendung und elimi-
niert falsch interpretierte „Fehler“ im Programmablauf.
Dies ist vor allem beim Debuggen
Informationen (ähnliche Beiträge, technische
Daten, Direktlinks zum Hersteller etc.)
sind online verfügbar auf www.EuE24.net.
auf C-Ebene wichtig, da das Verhal-
ldrcc r3, [pc, #11ch]
ten nicht unmittelbar erkannt werden kann.
Das Wissen um die Befehlsarchitektur und
more @ click EE5B0102 >
B.01
Das Knowledge-Portal für
Elektronik & Entwicklung
E&E KOMPENDIUM 2005/2006
93