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
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).
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
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.
Falls es dieses Holz sein sollte, auf dem du grad unterwegs bist: Die meistgebrauchte Bedingung in den Befehlen ist "always".
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-Befehlssatz > "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.
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.
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.
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.
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.
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.