Hallo, was sind eigentlich die gravierenden Unterschiede zwischen ARM7- und ARM9-Kern; Ausser das der ARM9 wohl höher getaktet werden kann. Gruß
google nach "arm9 arm7", 3te treffer, wikipedia, ausschnitt: Die ARM9 ist eine Weiterentwicklung der StrongARM- und ARM8-Architektur. Der wesentliche Unterschied der ARM9 gegenüber der ARM7 ist ein getrennter Datenbus jeweils für Instruktionen und Daten (Harvard-Architektur). Meist werden diese an separate Caches für Daten und Instruktionen angeschlossen. Des Weiteren besitzt die ARM9 eine 5-stufige Pipeline und kann so höhere Taktraten erreichen und weist eine bessere CPI (Cycles per Instruction) auf. Wird die ARM9 ohne Caches an einem externen Speicher mit nur einem Datenbus betrieben, schrumpft der Geschwindigkeitsvorteil gegenüber der ARM7.
Hallo, wichtigster Unterschied zwischen ARM7 und 9 ist die MMU (Memory management unit) des letzteren. Dadurch steht virtueller Speicher zur Verfügung, der eine Vorraussetzung für die meisten Betriebssysteme ist, z.B. Windows CE, Linux etc. Gruss Mike
Mal abgesehen davon, daß es auch ARM7 mit MMU geben muß, da selbst der ARM610 in meinem RiscPC 600 eine MMU hatte.
Es gibt beide mit und ohne MMU. Das wäre dann ein ARM710 (ARM7 mit MMU), ein ARM7TDMI (ARM7 ohne MMU), ARM966 (ARM 9 ohne MMU), ARM946 (ARM9 mit MPU), ARM926 (ARM9 mit MMU) Generell kann der ARM9 höher getacktet werden, allerdings ist ein ARM966 bei gleichem Takt nur unwesentlich schneller als ein ARM7. Allerdings ist beim ARM966 im Vergleich zum 946/966 deterministisch, d. h. die Befehlszyklen sind exakt vorhersagbar, während letztere zwar schneller sind und Caches haben. Die ARM9 bieten ausserdem die Möglichkeit Speicher direkt am ARM core anzuschliessen (sogenanntes tightly coupled memory) und von diesem direkt zu arbeiten. Der ARM7 geht immer über den ASB. Dann ist der ARM9 durch den direkten Speicherzugriff wieder deutlich schneller. So aus dem Gedächniss. Gruss Axel
ARM2 und ARM3 haben eben keine MMU gehabt. Die virtuelle Speicherverwaltung wurde über den externen MEMC geregelt, der nur 4MB Speicher verwalten konnte und außerdem auch nur mit einem 1:1-Mapping, d.h. je mehr Speicher man hatte, umso größer wurden Seitengröße (bei 4MB müßten es 32K pro Seite gewesen sein). Der ARM6 war der erste, der mit einer MMU ausgestattet werden konnte. ARM7 und ARM9 sind sowieso nur Kerne. Wahrscheinlich hält sich inzwischen keiner mehr an diese Bezeichnungen, aber bei der Einführung der neuen Numerierung mit dem ARM6 wurden folgende Konventionen aufgestellt: 1. Ziffer ist der Kern 2. Ziffer die Adressbreite 3. Ziffer die Caches Der ARM610 aus einem RiscPC 600 hatte einen 26-Bit Adressbus mit Cache, der ARM60 aus dem 3DO einen 32-Bit Adressbus ohne Cache. Die Angaben ohne Gewähr, da ich das ganze momentan nicht nachschlagen kann. Ansonsten gilt das, was Stefan schon zitiert hat: Der ARM9 hat eine Harvard-Architektur, d.h. getrennte Caches für Daten und Instruktionen. Dieser Vorteil ist natürlich nicht gegeben, wenn gar keine Caches vorhanden sind. Der ARM9 hat außerdem eine tiefere Pipeline, was durch die primitiveren Stufen eine höhere Taktung ermöglicht. Wenn der Takt aber nicht deutlich höher ist, kann sich die tiefere Pipeline aber auch negtiv auswirken, da es nach einem falsch vorhergesagtem Sprung (ich frage mich gerade, ob der ARM überhaupt eine Branch-Prediction hat) länger dauert, bis die Pipeline wieder gefüllt ist, und erst dann können auch wieder Instruktionen abgeschlossen werden.
> (ich frage mich gerade, ob > der ARM überhaupt eine Branch-Prediction hat) Der Core nicht, jedenfalls nicht ARM7-9, einzelne Implementierungen schon. So beispielsweise STR9, weil ohne Cache und dank halb-externem Flash (stacked die) von reichlich langsamem Flashzugriff geplagt. Im Endeffekt bei 96MHz i.d.R. nicht schneller als NXP ARM7 bei 70MHz.
> Wenn der Takt aber nicht deutlich > höher ist, kann sich die tiefere Pipeline aber auch negtiv auswirken, da > es nach einem falsch vorhergesagtem Sprung (ich frage mich gerade, ob > der ARM überhaupt eine Branch-Prediction hat) länger dauert, bis die > Pipeline wieder gefüllt ist, und erst dann können auch wieder > Instruktionen abgeschlossen werden. Da beide Cores die Execute Stage als dritte Stufe der Pipeline haben müssen beide auch nur zwei Befehle wegwerfen und neu holen. Deutlicher sind die Unterschiede für den Core selbst, da einiger Aufwand nötig ist, um Interlocks zu vermeiden, wenn Daten eines vorhergehenden Befehls sofort benötigt werden. Gruß, Dominic
Bitte 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.