Was ist so toll an ARM?

Leistung ist ein Vorteil. Als 32-Bit-Prozessor übertrifft er (fast) alle 8-Bit-Controller DMIPS-mäßig. Der Kern hat auch mehrere Generationen durchlaufen, lesen Sie Optimierungen.
Diese Optimierungen zeigen sich nicht nur in Leistungswerten, sondern auch im Stromverbrauch . Der neueste Kern hat sein DMIPS/mW-Verhältnis im Vergleich zur vorherigen Generation verdoppelt (siehe auch diese Antwort ).
ARM ist von sehr vielen Herstellern erhältlich , mehr als jeder andere Mikrocontroller, und jeder hat eine Reihe von Versionen zur Auswahl, mit unterschiedlichen Kombinationen von On-Chip-Peripheriegeräten und Speicher und Gehäusen. Ein typisches Beispiel: NXP bietet nicht weniger als 35 Controller mit On-Chip-Ethernet an .
Arme sindpreiswert ; ARM war wahrscheinlich der erste 32-Bit-Controller, der die 1-Dollar-Grenze durchbrach.

Diese Kombination aus Leistung , breitem Angebot und niedrigen Kosten macht es so, dass Sie ARM einfach nicht ignorieren können:

Im Jahr 2005 verwenden etwa 98 Prozent aller Mobiltelefone mindestens einen von ARM entwickelten Kern auf ihren Motherboards, laut einer Studie des Analyseunternehmens Linley Group. ( Quelle )

Der Handymarkt hat noch einen weiteren Effekt. Mobiltelefone sind sehr platzbeschränkt und erfordern kleine Gehäuse. Der LPC1102 von NXP wird in einem WLP-16-Gehäuse mit nur 5 mm geliefert$^2$, eine Skala, die bisher nur von 8-Bit-Mikrocontrollern mit niedriger Pinzahl verwendet wurde.

Ein Punkt, der noch nicht erwähnt wurde: 1908 erfand ein Typ namens Mr. PL Robertson einen neuen, verbesserten Schraubenkopf und Schraubendreher . Er wollte der Einzige sein, der Schrauben und Schraubendreher nach seinem Design fertigt. Jahrzehnte später entwickelte ein anderer namens Mr. Henry F. Phillips ein alternatives Design . Im Gegensatz zu Herrn Robertson war Herr Phillips mehr daran interessiert, sein Design zu lizenzieren, als Schrauben und Schraubendreher herzustellen.

Ebenso entwickelte Sony in den 1970er Jahren eine Technologie namens Betamax ; JVC hat eine namens VHS entwickelt. Sony war daran interessiert, Videorecorder herzustellen; JVC war mehr an der Lizenzierung interessiert.

Hier scheint es ein Muster zu geben. (Hinweis: Intel hat seine 80x86 -Technologie eine Zeit lang lizenziert, konzentriert sich aber seit Jahrzehnten mehr auf die Entwicklung von Technologien für den internen Gebrauch.)

1. Gleiche Hardware/Software zur Entwicklung für ARMs aller Anbieter. Sie kaufen einmal JLINK/ULINK und etwas Keil-IDE und können damit fast jeden ARM auf einem Planeten entwickeln, emulieren und debuggen.

2. Keine Notwendigkeit, eine neue Architektur zu lernen, wenn Sie zu einem neuen Chipanbieter wechseln => weniger Anbieterbindung => mehr Wettbewerb => niedrigere Preise

3. In modernen Tech-Prozessen (0,18 um und darunter) ist der ARM-Kern so winzig, dass das Opfern für einen 8-Bit-Kern keinen sichtbaren Bruchteil eines Preises einsparen würde. Daher der Grund, sich für eine leistungsstarke und dennoch kostengünstige Standardarchitektur zu entscheiden.

4. Leistung - nur mit ARM können Sie eine Single-Clock-32 * 32-> 32-Multiplikation und Hardware-Unterstützung für 32 * 32-> 64 und Division für Geräte unter 1 Dollar haben (nämlich beispielsweise STM32 der unteren Preisklasse)

5. ARM ist nicht zu gierig und erhebt keine unangemessenen Gebühren für Lizenzen, sodass Hersteller billige Mikros produzieren können.

Ich konzentriere mich aus folgenden Gründen auf ARM -Prozessoren der Mittelklasse:

1. Volle Linux-Unterstützung

   Das bedeutet Gerätetreiber fast kostenlos. Ich habe genug USB-Host- und Gerätecode gemacht, ich will DAS nicht mehr machen. Ich bin auch nicht besonders begeistert von dem Versuch, TCP/IP zu einer zufälligen Prozessorplattform hinzuzufügen (obwohl LwIP / uIP nicht so schlecht ist). Ich habe nie versucht, Wi-Fi, einen echten Bluetooth-Stack, Webcams usw. zu verwenden. Die Verwendung von Linux bedeutet, dass eine sehr breite Palette von Geräten viel einfacher zu kommunizieren ist.

   Ich war auch wirklich erstaunt, wie rationell und einfach das Schreiben von Linux-Gerätetreibern ist. Nach einigen Windows-Gerätetreibern ist Linux ein Traum. (Um fair zu sein, das Windows-Treiber-Framework hat sich seit meiner Einführung stark verbessert.)

   Die Softwareplattform ist auch großartig. Ich bekomme SSL-Verschlüsselung, Dateisysteme, Fernverwaltung, einfache Anwendungsaktualisierungen (eine Datei anstelle eines komplexen Bootloaders kopieren) usw. Oh, und viele vorhandene Dienstprogramme, wenn Sie etwas erledigen müssen.

   Es ist außerdem lizenzfrei und viel einfacher, sich Ihrem Willen zu beugen, als es eine Closed-Source- WinCE - Plattform sagen würde. (Nicht, dass ich wirklich ein Open-Source-Idealist wäre ... es ist alles sehr praktische Argumentation für mich.)

   Ich spreche von ARM-Kernen mit tatsächlichen MMUs , also ist dies für die Mid- bis High-End-Chips (obwohl Sie vermutlich μClinux verwenden könnten ).

2. Energieverbrauch

   Dies ist im Grunde eine Wiederholung der Kommentare anderer, aber es ist ein wichtiger Faktor für mich. Meine aktuelle 454-MHz-ARM-Plattform verbraucht 1/2 Watt, 1 Watt bei maximaler CPU. Daran kommt man mit x86 nicht einmal heran.

Das ist so ziemlich meine Überlegung. Ich sehe nicht, dass sich die Gleichung in absehbarer Zeit ändert.

Der ARM hat eine Entwicklung durchlaufen:

1. Eine 32-Bit-Befehlsarchitektur, die umfangreicheren Code hatte als viele andere Architekturen, die aber schnell decodiert werden konnte und viele Operationen mit weniger Befehlen als konkurrierende Architekturen ausführen konnte
2. Eine Architektur mit zwei Befehlsformaten, die zwischen dem netten und leistungsstarken (aber leider etwas aufgeblähten) ARM-Befehlssatz und einem weniger leistungsstarken (aber weitaus kompakteren) 16-Bit-„Thumb“-Befehlssatz wechseln kann. Jeder Thumb-Befehl hatte einen entsprechenden ARM-Befehl, wodurch die Notwendigkeit für Programmierer, zwei Befehlssätze zu lernen, etwas minimiert wurde.
3. Eine Thumb2-Architektur, die dem Thumb-Befehlssatz Zwei-Wort-Anweisungen hinzufügte, was größtenteils eine Win-Win-Situation ergab: Typischer ARM-Code würde eine Mischung aus Anweisungen enthalten, die nur in ARM verfügbar waren, und Anweisungen, die in Thumb verfügbar gewesen wären musste aber sowieso als 32 Bit dargestellt werden; In Thumb2 erhält ein solcher Code die Platzvorteile, indem er einige der 32-Bit-Anweisungen durch 16-Bit-Anweisungen ersetzt.
4. Eine Nur-Daumen-Architektur, die einschränkender ist, als mir lieb wäre, die aber kleiner und billiger ist als alle anderen.

Die ARM-Architektur ermöglicht die sehr schnelle Ausführung einiger ziemlich anspruchsvoller Operationen – viel schneller als auf jedem anderen Chip. Zum Beispiel (mit ARM7-TDMI):

  ldrh r0,[r10,#ADDR_BUS_OFS] ; Zielsystem-Adressbus lesen (13 Bit)
  ldrb r1,[r9,r0,lsr #8] ; Verwenden Sie obere Bits, um die Adresse in einer Handlertabelle nachzuschlagen
  füge pc, r9, r1 hinzu lsl #2 ; Gehen Sie zum entsprechenden Handler

Jeder Handler wird als Byte gespeichert, was 1/4 der Adressverschiebung vom Beginn der Tabelle ergibt. Der Nettoeffekt besteht darin, dass es, sobald der Inhalt des Adressbusses abgerufen wurde, nur sechs Zyklen (zwei Befehle) benötigt, um zu einem Handler zu springen, der auf den oberen fünf Bits des Abrufs basiert, wobei eine 32-Byte-Sprungtabelle verwendet wird.

Der entsprechende THUMB-Code wäre eher wie folgt:

; Angenommen, wir brauchen r6/r7 für nichts anderes, werden sie von r9/r10 neu zugewiesen
  ldrh r0,[r7,#ADDR_BUS_OFS]
  Bewegung r1,r0
  lsr r1,r1,#8 ; THUMB erfordert, dass Quelle und Ziel gleich sind
  ldrb r1,[r6,r1]
  lsl r1,r1,#1 ; Könnte Shift-Left-Two verwenden, wenn die Zieladressen an Vollwörtern ausgerichtet sind
  pc,r1 hinzufügen

Aus Sicht der Codedichte ist das in Ordnung, da die Anweisungen nur halb so groß sind wie die Originale, aber nach dem Abrufen neun statt sechs Zyklen dauern würde. In einer Anwendung, in der der überwachte Bus mit seiner eigenen Geschwindigkeit läuft, unabhängig davon, ob der ARM es geschafft hat oder nicht, sind die schnelleren ARM-Anweisungen ein großes Plus.

Übrigens ist Thumb2 binärkompatibel mit Thumb, was die Verwendung früherer Tools erleichtert, aber einige Dinge nicht so gut kann wie das ursprüngliche ARM. Beispielsweise könnte man in ARM eine 8x8-Bitmap, die in vier Registern gespeichert ist, mit etwa 3 Anweisungen pro zwei Bit "rotieren":

  movs r0,r4,lsl #25 ; Setzen Sie das oberste Bit von LSB in C und das nächste Bit in N
  orrcs r6,#0x00000001
  orrmi r6,#0x00000100

In Thumb2 müssten explizite bedingte Anweisungen hinzugefügt werden:

  movs r0,r4,lsl #25 ; Setzen Sie das oberste Bit von LSB in C und das nächste Bit in N
  itcs
  orrcs r6,#0x00000001
  itmi
  orrmi r6,#0x00000100

Netto 33 % weniger Zeit- und Platzeffizienz im Vergleich zu ARM; Das ist wahrscheinlich ein Worst-Case-Beispiel dafür, dass Thumb-Code weniger effizient als ARM ist, und selbst das ist nicht gerade schrecklich.

Ein weiterer kleiner Nachteil von Thumb2 gegenüber ARM: Im ARM-Code beginnen alle Anweisungen an Vollwortgrenzen, was die statische Analyse erleichtert. In Thumb2 können Befehle willkürlich an Halbwortgrenzen beginnen und Vollwortgrenzen überspannen. Eine statische Analyse kann daher viel schwieriger sein.

Ein bisschen ist Geschichte, Acorn wollte in den 1980er Jahren eine kundenspezifische CPU (z. B. mit eingebauter Speichersteuerung usw.) für einen neuen Computer (der 8-Bit-6502 begrenzte, was sie tun konnten). Sie sprachen mit Intel, aber Intel würde ihnen keine CPU lizenzieren.

Also entwarf Acorn eine sehr einfache RISC-CPU, aber da sie kein CPU-Hersteller waren, waren sie bereit, sie an jedermann zu lizenzieren (und brauchten so viel schnelles Geld, wie sie bekommen konnten!). (Ich glaube, die CPU hat beim ersten Mal funktioniert, teilweise weil sie so einfach war und der Designer während seiner Zeit an der Cambridge University viele Forschungs-CPUs entwickelt hat.)

Im Laufe der Jahre wurde es immer einfacher, das CPU-Design in das Chipdesign des Kunden einzubeziehen.

Der Chiphersteller fühlte sich bei der Lizenzierung von Acorn sicher, da er kein Konkurrent war. Auch dachte niemand, dass sie in die Heimatstadt eines Konkurrenten fahren würden, um eine Lizenz zu bekommen, da Acorn in Cambridge (der echten!) war . (Hat die Chance einer „Faktenfindungs“-Reise nach Cambridge, um Acorn zu besuchen, Einfluss auf die Short Listing von Optionen zu irgendeinem Zeitpunkt ….)

Viele der Designs, die die Acorn Risc Machine CPU enthalten, waren für eingebettete Systeme gedacht, bei denen der Stromverbrauch wichtig war. Auch für die Acorn Risc Machine CPU wurden günstige und gute Entwicklungstools geschaffen.

Als Mobiltelefone anfingen, benutzerdefinierte Chips mit einer eingebetteten CPU zu benötigen, wurde Acorn in ARM umbenannt und der Rest ist Geschichte. (Vielleicht war es auch ein bisschen, dass die anderen CPUs größtenteils von den USA kontrolliert wurden, aber Handys werden erst in Europa normal)

(Erinnert Sie irgendetwas davon an Microsoft und Dos mit einem kleinen unbekannten Team von IBM?)

Die Tatsache, dass der ARM damals (und immer noch) für viele Aufgaben eine der besten CPUs war, half auch - aber nur das "beste" CPU-Design zu haben, reicht nicht aus.

Abgesehen von technischen Problemen gibt es viele nicht-technische Gründe für ARM. Aber die schnelle Antwort lautet: Es ist nicht Intel (oder x86).

Wenn Sie sich ansehen, wo die CPU-F&E-Dollars derzeit investiert werden, fallen sie im Wesentlichen in zwei Lager: ARM und Intel. (Ich ignoriere kleine MCUs und werfe AMD mit Intel in einen Topf.) In PowerPC, MIPS, SPARC und andere große CPUs fließt sehr wenig Geld. ARM und Intel sind die einzigen, die noch stehen.

Mit Intel und anderen x86-CPUs erhalten Sie eine riesige Menge Legacy-Gepäck. Beispielsweise benötigen Sie einen Chipsatz, ein BIOS und andere Dinge. Selbst wenn die CPU super energieeffizient war, neigen diese anderen Geräte dazu, Ihr System zu belasten und es größer, leistungshungriger und teurer zu machen. Allein die Entwicklung einer Leiterplatte mit einer Intel-CPU ist ein großes Problem, und dann müssen Sie mit einem BIOS-Anbieter usw. verhandeln. Um die Sache noch schlimmer zu machen, wollen viele der Anbieter für Chipsätze, BIOS, Videochips usw. einfach nicht um Geschäfte mit den kleinen Leuten zu machen, die nicht weniger als eine Million Einheiten pro Jahr verkaufen.

Mit ARM haben Sie dieses Gepäck nicht. Es gibt viele Quellen für Chips, von Mikrocontroller-Produkten bis hin zu Multi-Core-Monstern. Sie müssen sich nicht um die Lizenzierung eines BIOS kümmern (was dem Besuch eines Gebrauchtwagenhändlers sehr ähnlich ist). Und Hersteller und Verkäufer sind im Allgemeinen nett zu Ihnen.

Vergleichen Sie ARM7 / ARM9 mit MIPS IV und es gibt kaum einen Vorteil außer den bereits erwähnten Lizenzierungsproblemen. Die Interna des MIPS-Befehlssatzes und des internen Busses machen es für bestimmte Arten von Designs überlegen (Leistung pro Kosten); Aus diesem Grund verwenden viele Wi-Fi-Router MIPS-Kerne anstelle von ARM-Kernen.

Da ARM-Kerne hauptsächlich auf Handheld-Geräte angewendet wurden, fügten die ASICs mehr Leistungssteuerungsfunktionen hinzu, während sich MIPS mehr auf die Leistung pro Zyklus als auf niedrigeren Stromverbrauch konzentriert. Der Vorteil von RISC gegenüber Intel x86 ist eine andere Diskussion.

Wirkliche Vorteile gibt es nicht. Angeschlossene DSP und andere Controller wie GSM machen sie so beliebt.