www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik ARM-Befehle und Condition flags


Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich muss einen Vortrag u.a. über den Befehlssatz der ARM-Prozessoren 
halten.
Bei ARM-Prozessoren ist es ja nun so, dass jeder Befehl (oder vielleicht 
doch nur einige Befehle?) auch als bedingter Befehl ausgeführt werden 
kann. Dafür gibt es in den Befehlen die letzten 4 Bits, also die Bits 28 
bis 31.
Was ich mich jetzt frage ist folgendes:
Gibt es zu jedem bedingten Befehl 16 Varianten? Also zum Bsp. der 
Additionsbefehl: ADDEQ R1, #1. Das wären dann ja wahnsinnig viele 
Befehle für eine RISC-CPU. Oder sind es "nur" bis zu 16 Varianten? Aber 
auch das wären noch sehr viele.
Wie muss ich mir das vorstellen mit den Befehlen? Hoffe mir kann da 
jemand weiter helfen.

Wünsche eine gute Nacht

MfG Andy

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
andy schrieb:

> Bei ARM-Prozessoren ist es ja nun so, dass jeder Befehl (oder vielleicht
> doch nur einige Befehle?) auch als bedingter Befehl ausgeführt werden
> kann.

Fast jeder Befehl wird bedingt ausgeführt. Es gibt ab ARMv5 ein paar, 
die sich die Codierung für "never" gekrallt haben und demzufolge ohne 
predication auskommen müssen.

> Was ich mich jetzt frage ist folgendes:
> Gibt es zu jedem bedingten Befehl 16 Varianten?

Eigentlich 15, weil "never" naheliegenderweise anderweitig genutzt wird.

> Additionsbefehl: ADDEQ R1, #1. Das wären dann ja wahnsinnig viele
> Befehle für eine RISC-CPU. Oder sind es "nur" bis zu 16 Varianten? Aber
> auch das wären noch sehr viele.

Wenn du alle Suffixbuchstaben hinter ADD als separate Befehle rechnest, 
dann wirst du beim Zählen mit den Finger und Zehen nicht mehr auskommen. 
Denk dir ADD als Grundbefehl, und den Rest dahinter als Beschreibung 
einer bestimmten Arbeitsweise dieses Grundbefehls. Kann ja 
beispielsweise auch noch ein "S" folgen (bei LDM/STM noch ein bischen 
mehr).

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
danke für die rasche Antwort.
Dass es nun doch so viele Befehle sind bei dieser RISC-CPU wundert mich 
ein wenig. Ich bin davon ausgegangen, dass man mit den Predicated 
Instructions den Programm-Code verkleinern will, was die Ausführung des 
Codes beschleunigt. Ich dachte aber auch, dass man den Speicherplatz zum 
Speichern der Befehle reduzieren will, da der Zugriff darauf Energie 
kostet, die in Handys oder Notebooks Mangelware ist. Wenn man nun aber 
doch so viele Befehle hat, die man nun auch alle speichern muss, erhält 
man ja eine geringe Beschleunigung der Ausführung auf Kosten eines 
höheren Energieverbrauches. Lohnt sich das denn?

Allgemein zu den bedingten Anweisungen hab ich gelesen, dass sie die 
Ausführung beschleunigen, indem sie das leeren der kompletten Pipeline 
verhindern (im schlimmsten Fall wird der bedingte Befehl nicht 
ausgeführt und eine no-op in die Pipeline geschickt).

Berichtigt mich bitte wenn ich das falsch verstanden hab.

MfG Andy

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
andy schrieb:

> Dass es nun doch so viele Befehle sind bei dieser RISC-CPU wundert mich
> ein wenig.

Das liegt nur an deiner Zählweise und an ARMs Schreibweise von Befehlen. 
Wenn ARM in Anlehnung an Motorola-Syntax ADD.EQ statt ADDEQ geschrieben 
hätte, oder wie Intel mit vorgestelltem IF(EQ), dann wäre es dir 
vielleicht klarer.

Aber wenn du es unbedingt so willst: Die Maschine hat unabhängig von 
deiner Interpretation nur einen ADD Befehl, mit predication, einem S-Bit 
und ein paar Operanden. Deine Vervielfältigung der Befehle entsteht erst 
durch die symbolische Darstellung des Assemblers.

> Ich bin davon ausgegangen, dass man mit den Predicated
> Instructions den Programm-Code verkleinern will, was die Ausführung des
> Codes beschleunigt.

Korrekt, allerdings macht nicht (nur) die Grösse den Unterschied, 
sondern die eingesparte Laufzeit des Sprungbefehls.

> Ich dachte aber auch, dass man den Speicherplatz zum
> Speichern der Befehle reduzieren will, da der Zugriff darauf Energie
> kostet,

Das eher ist ein kleiner aber nicht allzu auffälliger Nebeneffekt.

> die in Handys oder Notebooks Mangelware ist. Wenn man nun aber
> doch so viele Befehle hat, die man nun auch alle speichern muss

Sorry, aber du bist grad ziemlich auf dem Holzweg...

Selbst wenn eine Maschine 1 Million verschiedener Befehle hätte, käme 
das einfachste Programm trotzdem mit einem einzigen Speicherwort aus.

> Allgemein zu den bedingten Anweisungen hab ich gelesen, dass sie die
> Ausführung beschleunigen, indem sie das leeren der kompletten Pipeline
> verhindern (im schlimmsten Fall wird der bedingte Befehl nicht
> ausgeführt und eine no-op in die Pipeline geschickt).

Korrekt. Das ist der wichtigste Effekt. Je länger die Pipeline desto 
markanter.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falls es dieses Holz sein sollte, auf dem du grad unterwegs bist: Die 
meistgebrauchte Bedingung in den Befehlen ist "always".

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, ich hab nochmal nachgelesen: Die Befehle sind im Steuerwerk fest 
verdrahtet und werden damit durch die Hardware interpretiert. Heisst man 
braucht gar keinen Speicher.
Vielleicht ist das der Grund, weshalb ich auf dem Holzweg war:
http://de.wikipedia.org/wiki/ARM-Architektur#Thumb...
> "Um die Code-Dichte zu erhöhen, also den Speicherbedarf für eine bestimmte
> Funktion zu verringern, hat ARM Ltd. den Thumb-Befehlssatz entwickelt, der
> nur aus 16 Bit breiten Befehlen besteht ... "
Heisst dann nur, dass das Speichern des Programm-Codes im 
Instruktionsspeicher weniger Platz in Anspruch nimmt. Dadurch spart man 
sich die Energie für den Zugriff auf die Speicherzellen.
In der Thumb-Einheit ist die Dekodierung der 16-Bit Befehle wiederum 
fest verdrahtet.

Mit dem Always war ein guter Tip, danke.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
andy schrieb:

> Heisst dann nur, dass das Speichern des Programm-Codes im
> Instruktionsspeicher weniger Platz in Anspruch nimmt.

Richtig. Ist dafür langsamer weil weniger mächtig.

> Dadurch spart man
> sich die Energie für den Zugriff auf die Speicherzellen.

Da würde ich lieber nicht so drauf rumreiten. Hauptsächlich spart es dem 
Handy-Hersteller Geld. Für Speicherbausteine

Kannst ja man bei ARMv7 aka Thumb2 reinsehen. Da ist die predication in 
Form eines recht pfiffigen Präfix-Befehls realisiert. Frisst nur dort 
Platz weg, wo es sich auch lohnt.

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo genau sind denn dann die Vorteile bei ARM-Prozessoren, im Hinblick 
auf Akkulaufzeit und Rechenleistung?
Durch Predicated Instructions kann man die Code-Größe reduzieren und 
vermeidet das leeren der kompletten Pipeline. Das beschleunigt die 
Ausführung des Codes bei gleicher Taktfrequenz.
Und durch die Thumb-Erweiterung kann man die Codegröße an sich 
reduzieren, indem man immer 2 Befehle gleichzeitig läd.
Allerdings steht in dem Wiki-Artikel auch, dass die 
Ausführungsgeschwindigkeit abnimmt, bspw. weil die Pipeline im 
Thumb-Modus auch komplett geleert werden muss, da hier keine Predicated 
Instructions zur Verfügung stehen.

Ich glaube ich sehe gerade irgendwo den Sinn der thumb-Erweiterung 
nicht.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
andy schrieb:

> Wo genau sind denn dann die Vorteile bei ARM-Prozessoren, im Hinblick
> auf Akkulaufzeit und Rechenleistung?

Gegenüber wem oder was?

> Und durch die Thumb-Erweiterung kann man die Codegröße an sich
> reduzieren, indem man immer 2 Befehle gleichzeitig läd.

Krude Aussage.

Der Code wird nicht dadurch kürzer, dass man mehr Befehle gleichzeitig 
läd, sondern indem man für die gleiche Aufgabe zwar mehr Befehle 
benötigt, diese in Summe aber weniger Platz brauchen.

> Allerdings steht in dem Wiki-Artikel auch, dass die
> Ausführungsgeschwindigkeit abnimmt

Stimmt auch. Wobei nicht nur die Predication mitspielt, sondern auch 
2-Adress vs 3-Adress Befehle, Anzahl verwendbarer Register, Codierung 
von Konstanten und Displacements usw. wodurch ebenfalls die Anzahl 
Befehle zunimmt. Mehr Befehle bedeuten (hier) höhere Laufzeit.

> Ich glaube ich sehe gerade irgendwo den Sinn der thumb-Erweiterung
> nicht.

Kein Wunder. Wenn dir der Sinn nur nach Tempo und Strom geht, dann 
kommst du nie dahinter.

Grosse Teile des Codes vieler Programme sind für die Gesamtperformance 
des Produkts nicht relevant, d.h. ob dieser Code schneller oder 
langsamer ist hat keine Bedeutung. Dort wo Performance gefragt ist kann 
man ARM-Code verwenden. Für die Kosten des benötigten Speichers ist die 
Grösse des Code jedoch sehr relevant.

Autor: andy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es geht in dem Vortrag um Prozessoren für mobile Geräte.
Und das Hauptanliegen ist dort ja, die Akkulaufzeit zu verlängern und 
die Rechenleistung zu erhöhen. Und Kosten will man natürlich überall 
sparen. Deshalb bin ich da so fixiert drauf.

> Grosse Teile des Codes vieler Programme sind für die Gesamtperformance
> des Produkts nicht relevant, d.h. ob dieser Code schneller oder
> langsamer ist hat keine Bedeutung. Dort wo Performance gefragt ist kann
> man ARM-Code verwenden. Für die Kosten des benötigten Speichers ist die
> Grösse des Code jedoch sehr relevant.

Also: Kann man gut damit leben, dass die Ausführung des Codes etwas 
länger dauert, dann bedient man sich den Thumb-Befehlen. So spart man 
wenigstens ein paar Kosten.
Soll es aber etwas schneller gehen, dann bleibt man lieber beim 32-Bit 
ARM-Befehlssatz.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.