Arm-Architekturfamilie

ARM AArch64 (64/32-Bit)

Eingeführt	2011 ( 2011 )
Version	ARMv8-R, ARMv8-A, ARMv8.1-A, ARMv8.2-A, ARMv8.3-A, ARMv8.4-A, ARMv8.5-A, ARMv8.6-A, ARMv8.7-A, ARMv8.8-A, ARMv8.9-A, ARMv9.0-A, ARMv9.1-A, ARMv9.2-A, ARMv9.3-A, ARMv9.4-A, ARMv9.5-A, ARMv9.6-A, ARMv9.7-A
Codierung	AArch64 /A64 und AArch32 /A32 verwenden 32-Bit-Befehle, AArch32/T32 (Thumb-2) verwendet gemischte 16- und 32-Bit-Befehle [ 1 ].
Endianität	Bi (kleine Standardeinstellung)
Erweiterungen	SVE , SVE2, SME , SME2, ​​AES, SM3, SM4, SHA, CRC32, RNDR, TME; alle obligatorisch: Thumb-2 , Neon , VFPv4-D16, VFPv4; veraltet: Thumb und Jazelle
Register
Allzweck	31 × 64-Bit-Ganzzahlregister [ 1 ]
Gleitkommazahl	32 × 128-Bit -Register [ 1 ] für skalare 32- und 64-Bit -Gleitkommazahlen oder SIMD- Gleitkommazahlen oder Ganzzahlen; oder Kryptographie

Arm (stilisiert in Kleinbuchstaben als arm ) ^{[ a ]} ist eine Familie von RISC -Befehlssatzarchitekturen für Computerprozessoren . Arm Holdings entwickelt die Befehlssatzarchitektur und lizenziert sie an andere Unternehmen, die die physischen Geräte herstellen, welche den Befehlssatz nutzen. Das Unternehmen entwirft und lizenziert außerdem Kerne , die diese Befehlssatzarchitekturen implementieren.

Aufgrund ihrer geringen Kosten, ihres niedrigen Stromverbrauchs und ihrer geringen Wärmeentwicklung eignen sich ARM-Prozessoren für leichte, tragbare und akkubetriebene Geräte wie Smartphones , Laptops und Tablet-Computer sowie für eingebettete Systeme . ^{[ 3 ] [ 4 ] [ 5 ] [ 6 ]} ARM-Prozessoren werden jedoch auch in Desktop-PCs und Servern eingesetzt , darunter Fugaku , der von 2020 ^{[ 7 ]} bis 2022 schnellste Supercomputer der Welt. Mit über 230 Milliarden produzierten ARM-Chips ^{[ 8 ] [ 9 ]} seit mindestens 2003 und einer jährlich wachsenden Marktführerschaft ist ARM die am weitesten verbreitete Familie von Befehlssatzarchitekturen. ^{[ 10 ] [ 4 ] [ 11 ] [ 12 ] [ 13 ]}

Es gab mehrere Generationen des ARM-Designs. Der ursprüngliche ARM1 nutzte eine 32-Bit -interne Struktur, verfügte aber über einen 26-Bit -Adressraum , wodurch der Hauptspeicher auf 64 MB begrenzt war . Diese Beschränkung wurde in der ARMv3-Serie aufgehoben, die einen 32-Bit-Adressraum besitzt. Auch mehrere nachfolgende Generationen bis einschließlich ARMv7 blieben 32-Bit-Architektur. Die 2011 veröffentlichte ARMv8-A-Architektur führte mit ihrem neuen 32 -Bit-Befehlssatz fester Länge die Unterstützung für einen 64-Bit -Adressraum und 64-Bit-Arithmetik ein. ^{[ 14 ]} Arm Holdings hat zudem eine Reihe zusätzlicher Befehlssätze für verschiedene Anwendungsbereiche veröffentlicht: Die „Thumb“-Erweiterungen fügen sowohl 32- als auch 16-Bit-Befehle für eine höhere Codedichte hinzu , während Jazelle Befehle für die direkte Verarbeitung von Java-Bytecode bereitstellt . Zu den neueren Änderungen zählt die Einführung von Simultaneous Multithreading (SMT) zur Verbesserung der Leistung und Fehlertoleranz . ^{[ 15 ]}

Der erste große Erfolg von Acorn Computers war der BBC Micro , der im Dezember 1981 auf den Markt kam. Es handelte sich um einen relativ konventionellen Rechner, der auf der MOS Technology 6502 CPU basierte, aber dank des schnelleren dynamischen Direktzugriffsspeichers (DRAM) etwa doppelt so schnell war wie Konkurrenzmodelle wie der Apple II . Typischer DRAM taktete damals mit etwa 2 MHz; Acorn schloss einen Vertrag mit Hitachi über die Lieferung schnellerer 4-MHz-Bauteile ab. ^{[ 16 ]}

Rechner jener Zeit nutzten im Allgemeinen einen gemeinsamen Speicher für Prozessor und Framebuffer . Dadurch konnte der Prozessor den Bildschirminhalt schnell aktualisieren, ohne separate Ein-/Ausgabeoperationen durchführen zu müssen . Da die Videodarstellung präzise erfolgen musste, benötigte die Videohardware priorisierten Zugriff auf diesen Speicher. Aufgrund einer Besonderheit des 6502-Designs blieb der Speicher die Hälfte der Zeit ungenutzt. Durch den Betrieb der CPU mit 1 MHz konnte das Videosystem in diesen Leerlaufzeiten Daten lesen und die gesamte Bandbreite des RAM von 2 MHz nutzen. Beim BBC Micro ermöglichte die Verwendung von 4 MHz RAM die Anwendung derselben Technik, jedoch mit doppelter Geschwindigkeit. Dadurch übertraf er alle vergleichbaren Rechner auf dem Markt. ^{[ 17 ]}

1981 war auch das Jahr, in dem der IBM Personal Computer (PC) eingeführt wurde. Mit dem kurz zuvor erschienenen Intel 8088 , einer 16-Bit -CPU im Vergleich zum 8-Bit -Design des 6502, bot er eine höhere Gesamtleistung. Seine Einführung veränderte den Markt für Desktop-Computer grundlegend: Was in den fünf Jahren zuvor vorwiegend ein Markt für Hobby- und Spielecomputer gewesen war, entwickelte sich zu einem unverzichtbaren Werkzeug für Unternehmen, mit dem die älteren 8-Bit-Systeme schlichtweg nicht mehr mithalten konnten. Auch neuere 32-Bit -Systeme wie der Motorola 68000 ^{[ 18 ]} und der National Semiconductor NS32016 ^{[ 19 ]} kamen auf den Markt .

Acorn überlegte, wie man in diesem Markt konkurrieren könnte, und entwickelte einen neuen Entwurf namens Acorn Business Computer . Ziel war es, ein Gerät mit der zehnfachen Leistung des BBC Micro zum gleichen Preis zu produzieren. ^{[ 20 ]} Damit sollte der PC leistungsstärker und günstiger sein. Gleichzeitig machte die kürzlich erschienene Apple Lisa das Konzept der grafischen Benutzeroberfläche (GUI) einem breiteren Publikum bekannt und deutete an, dass die Zukunft Geräten mit GUI gehören würde. ^{[ 21 ]} Die Lisa kostete jedoch 9.995 US-Dollar, da sie mit zusätzlichen Chips, großem Arbeitsspeicher und einer Festplatte ausgestattet war – allesamt für damalige Verhältnisse sehr teuer. ^{[ 22 ]}

Die Ingenieure begannen daraufhin, alle verfügbaren CPU-Designs zu untersuchen. Ihr Fazit zu den bestehenden 16-Bit-Designs lautete, dass diese deutlich teurer und immer noch „ziemlich schlecht“ ^{[ 23 ]} waren und nur eine geringfügig höhere Leistung als ihr BBC-Micro-Design boten. Außerdem benötigten sie fast immer eine große Anzahl an Hilfschips, um überhaupt auf diesem Niveau zu funktionieren, was die Gesamtkosten des Computers in die Höhe trieb. Diese Systeme würden das Designziel schlichtweg nicht erreichen. ^{[ 23 ]} Sie zogen auch die neuen 32-Bit-Designs in Betracht, doch diese waren noch teurer und wiesen dieselben Probleme mit den Hilfschips auf. ^{[ 24 ]} Laut Sophie Wilson wiesen alle zu diesem Zeitpunkt getesteten Prozessoren eine vergleichbare Leistung mit einer Bandbreite von etwa 4 Mbit/s auf. ^{[ 25 ] [ b ]}

Zwei Schlüsselereignisse führten Acorn auf den Weg zu ARM. Zum einen die Veröffentlichung einer Reihe von Berichten der University of California, Berkeley , die nahelegten, dass ein einfaches Chipdesign dennoch eine extrem hohe Leistung erzielen konnte, deutlich höher als die der neuesten 32-Bit-Designs auf dem Markt. ^{[ 26 ]} Zum anderen der Besuch von Steve Furber und Sophie Wilson beim Western Design Center , einem Unternehmen von Bill Mensch und seiner Schwester Kathryn, ^{[ 27 ]} das als logischer Nachfolger des MOS-Teams galt und neue Versionen wie den WDC 65C02 anbot . Das Acorn-Team sah dort Schüler, die Chip-Layouts auf Apple II-Rechnern erstellten, was den Eindruck erweckte, dass dies jeder schaffen konnte. ^{[ 28 ] [ 29 ]} Im Gegensatz dazu zeigte ein Besuch bei einem anderen Designbüro, das an modernen 32-Bit-CPUs arbeitete, dass ein Team mit über einem Dutzend Mitgliedern bereits an Revision H seines Designs gearbeitet hatte, das aber dennoch Fehler aufwies. ^{[ c ]} Dies bestärkte sie Ende 1983 in ihrem Entschluss, mit der Entwicklung ihrer eigenen CPU zu beginnen: der Acorn RISC Machine. ^{[ 30 ]}

Die ursprünglichen Berkeley-RISC- Architekturen waren in gewisser Weise Lehrsysteme und nicht primär auf maximale Leistung ausgelegt. ARM ergänzte die registerintensiven Load/Store-Konzepte der RISC-Architektur um einige bewährte Designmerkmale des 6502. Besonders hervorzuheben war die Fähigkeit zur schnellen Interruptverarbeitung , wodurch die Maschinen ohne zusätzliche externe Hardware eine akzeptable Ein-/Ausgabeleistung boten . Um Interrupts mit ähnlicher Leistung wie der 6502 zu ermöglichen, beschränkte die ARM-Architektur ihren physischen Adressraum auf 64 MB adressierbaren Speicherplatz, was 26 Bit Adressierung erforderte. Da Befehle 4 Byte (32 Bit) lang waren und an 4-Byte-Grenzen ausgerichtet werden mussten, waren die unteren 2 Bit einer Befehlsadresse immer null. Dadurch benötigte der Programmzähler (PC) nur 24 Bit und konnte zusammen mit den 8-Bit -Prozessorflags in einem einzigen 32-Bit-Register gespeichert werden . Das bedeutete, dass beim Empfang einer Interruptanforderung der gesamte Maschinenzustand in einem einzigen Vorgang gespeichert werden konnte, während bei einem vollständigen 32-Bit-Wert des Programmzählers (PC) separate Vorgänge zum Speichern des PC und der Statusflags erforderlich gewesen wären. Diese Entscheidung halbierte den Interrupt-Overhead. ^{[ 31 ]}

Eine weitere Änderung, die hinsichtlich der praktischen Leistung besonders wichtig war, betraf die Modifizierung des Befehlssatzes zur Nutzung des Seitenmodus-DRAM . Der kürzlich eingeführte Seitenmodus ermöglichte es, aufeinanderfolgende Speicherzugriffe doppelt so schnell auszuführen, wenn sie sich annähernd an derselben Stelle, der sogenannten „Seite“, im DRAM-Chip befanden. Berkeleys Design berücksichtigte den Seitenmodus nicht und behandelte den gesamten Speicher gleich. Das ARM-Design fügte spezielle vektorähnliche Speicherzugriffsbefehle, die „S-Zyklen“, hinzu, mit denen sich mithilfe des Seitenmodus mehrere Register auf einer einzelnen Seite füllen oder sichern ließen. Dies verdoppelte die Speicherleistung, sofern diese Befehle verwendet werden konnten, und war insbesondere für die Grafikleistung von Bedeutung. ^{[ 32 ]}

Die Berkeley RISC-Architektur nutzte Registerfenster , um die Anzahl der Register-Speicherungen und -Wiederherstellungen bei Prozeduraufrufen zu reduzieren ; die ARM-Architektur übernahm dies nicht.

Wilson entwickelte den Befehlssatz und schrieb eine Prozessorsimulation in BBC BASIC , die auf einem BBC Micro mit einem zweiten 6502-Prozessor lief . ^{[ 33 ] [ 34 ]} Dies bestärkte die Ingenieure von Acorn in ihrer Annahme, auf dem richtigen Weg zu sein. Wilson wandte sich an den CEO von Acorn, Hermann Hauser , und bat um zusätzliche Ressourcen. Hauser gab seine Zustimmung und stellte ein kleines Team zusammen, um den eigentlichen Prozessor auf Basis von Wilsons Befehlssatzarchitektur zu entwickeln. ^{[ 35 ]} Das offizielle Acorn-RISC-Machine-Projekt startete im Oktober 1983.

Acorn wählte VLSI Technology als „Siliziumpartner“, da dieses Unternehmen ROMs und kundenspezifische Chips für Acorn lieferte. Acorn stellte das Design bereit, VLSI übernahm Layout und Produktion. Die ersten ARM-Silizium-Proben funktionierten bei Erhalt und Test am 26. April 1985 einwandfrei. ^{[ 3 ]} Diese als ARM1 bekannten Versionen takteten mit 6 MHz. ^{[ 36 ]}

Die erste ARM-Anwendung diente als zweiter Prozessor für den BBC Micro. Dort unterstützte er die Entwicklung von Simulationssoftware zur Fertigstellung der Support-Chips (VIDC, IOC, MEMC) und beschleunigte die CAD-Software, die in der ARM2-Entwicklung zum Einsatz kam. Anschließend schrieb Wilson BBC BASIC in ARM- Assemblersprache neu . Die beim Entwurf des Befehlssatzes gewonnenen umfassenden Kenntnisse ermöglichten einen sehr dichten Code, wodurch ARM BBC BASIC zu einem hervorragenden Test für jeden ARM-Emulator wurde.

ARM-Evaluierungssysteme mit ARM1-CPUs, die als Zweitprozessoren für BBC Micro- und Master-Rechner geliefert wurden, waren ab Juli 1986 ^{[ 37 ]} unter der Marke Acorn OEM Products für Entwickler und Forscher erhältlich. ^{[ 38 ]}

Der A500 Second Processor, ein zusätzlicher ARM1-basierter BBC Micro und Master Second Processor, verfügte über den ARM Support Chipset (VIDC, IOC, MEMC), war in der Lage, Videoausgabe zu erzeugen ^{[ 39 ]} und nahezu unabhängig vom Host BBC Micro zu arbeiten.

Die Ergebnisse der Simulationen auf den ARM1-Platinen führten Ende 1986 zur Einführung des ARM2-Designs mit 8 MHz und Anfang 1987 zur schnelleren Version mit 10 bis 12 MHz. ^{[ d ]} Eine wesentliche Änderung der zugrundeliegenden Architektur war die Hinzufügung eines Booth-Multiplizierers , da die Multiplikation zuvor in Software erfolgen musste. ^{[ 41 ]} Darüber hinaus ermöglichte ein neuer Fast Interrupt Request Mode (FIQ), die Register 8 bis 14 im Rahmen des Interrupts selbst zu ersetzen. Dadurch mussten FIQ-Anforderungen ihre Register nicht mehr sichern, was die Interrupts weiter beschleunigte. ^{[ 42 ]}

Der erste Einsatz des ARM2 erfolgte in internen Acorn A500 Entwicklungsmaschinen ^{[ 43 ]} sowie in den Personalcomputermodellen Acorn Archimedes A305, A310 und A440, die am 6. Juni 1987 auf den Markt kamen.

Laut Dhrystone- Benchmark war der ARM2 etwa siebenmal so leistungsstark wie ein typisches System mit 7 MHz 68000-Prozessor, wie beispielsweise der Amiga oder Macintosh SE . Er war doppelt so schnell wie ein Intel 80386 mit 16 MHz und etwa so schnell wie ein Multiprozessor- Superminicomputer vom Typ VAX-11/784 . Lediglich die RISC-basierten Workstations Sun SPARC und MIPS R2000 waren schneller . ^{[ 44 ]} Da die CPU für schnelle Ein-/Ausgabe ausgelegt war, verzichtete sie auf viele der in diesen Geräten üblichen Hilfschips; insbesondere fehlte ihr ein dedizierter DMA-Controller ( Direct Memory Access ), der häufig in Workstations zu finden war. Auch das Grafiksystem wurde auf Basis derselben Annahmen bezüglich Speicher und Timing vereinfacht. Das Ergebnis war ein deutlich vereinfachtes Design, das eine Leistung auf dem Niveau teurer Workstations bot, jedoch zu einem Preis, der dem zeitgenössischer Desktop-PCs ähnelte. ^{[ 44 ]}

Der ARM2 verfügte über einen 32-Bit -Datenbus , einen 26-Bit -Adressraum und 27 32-Bit -Register , von denen jeweils 16 (einschließlich des Programmzählers ) zugänglich waren. ^{[ 45 ]} Der ARM2 besaß lediglich 30.000 Transistoren ^{[ 46 ]} , im Vergleich zu Motorolas sechs Jahre älterem Modell 68000 mit rund 68.000. Diese Einfachheit resultierte größtenteils aus dem Verzicht auf Mikrocode , der etwa ein Viertel bis ein Drittel der Transistoren des 68000 ausmachte, und dem Fehlen eines Caches (wie bei den meisten CPUs jener Zeit) . Dank dieser Einfachheit konnte der ARM2 einen geringen Stromverbrauch und eine einfachere Wärmeableitung durch die geringere Anzahl an Transistoren erreichen. Dennoch bot ARM2 eine bessere Leistung als der zeitgenössische IBM PS/2 Model 50 von 1987 , der anfänglich einen Intel 80286 mit 1,8 MIPS bei 10 MHz nutzte, und später im Jahr 1987 die 2 MIPS des PS/2 70 mit seinem Intel 386 DX bei 16 MHz. ^{[ 47 ] [ 48 ]}

Der Nachfolger ARM3 verfügte über einen 4 KB großen Cache, was die Leistung weiter verbesserte. ^{[ 49 ]} Beim ARM6 wurde der Adressbus auf 32 Bit erweitert, der Programmcode musste jedoch aufgrund der für die Statusflags reservierten Bits im 26-Bit-Kompatibilitätsmodus weiterhin innerhalb der ersten 64 MB des Speichers liegen. ^{[ 50 ]}

1988 wurde Sanyo im Rahmen einer Vereinbarung mit VLSI Technology zum weltweiten Zweitlieferanten für den ARM2 und den zugehörigen Chipsatz. ^{[ 51 ]}

Ende der 1980er-Jahre begannen Apple Computer und VLSI Technology gemeinsam mit Acorn an neueren Versionen des ARM-Kerns zu arbeiten. 1990 gliederte Acorn das Entwicklungsteam in ein neues Unternehmen namens Advanced RISC Machines Ltd. aus ^{[ 52 ] [ 53 ] [ 54 ],} das 1998, nach dem Börsengang der Muttergesellschaft Arm Holdings plc an der Londoner Börse und der Nasdaq , zu ARM Ltd. wurde ^{[ 55 ]} . Die neue Zusammenarbeit zwischen Apple und ARM führte schließlich zum ARM6, der Anfang 1992 erstmals veröffentlicht wurde. Apple nutzte den auf dem ARM6 basierenden ARM610 als Grundlage für seinen Apple Newton PDA.

1994 nutzte Acorn den ARM610 als Hauptprozessor ( CPU) in seinen RiscPC -Computern. DEC lizenzierte die ARMv4-Architektur und entwickelte den StrongARM . ^{[ 56 ]} Bei 233  MHz verbrauchte diese CPU nur ein Watt (neuere Versionen verbrauchen deutlich weniger). Im Rahmen eines Vergleichs ging die Entwicklung später an Intel über, das die Gelegenheit nutzte, seine i960- Reihe mit dem StrongARM zu ergänzen. Intel entwickelte später eine eigene Hochleistungsimplementierung namens XScale , die später an Marvell verkauft wurde . Die Transistoranzahl des ARM-Kerns blieb während dieser Änderungen im Wesentlichen gleich; ARM2 hatte 30.000 Transistoren, ^{[ 57 ]} während die Anzahl bei ARM6 nur auf 35.000 anstieg. ^{[ 58 ]}

Im Jahr 2005 nutzten rund 98 % aller verkauften Mobiltelefone mindestens einen ARM-Prozessor. ^{[ 59 ]} Im Jahr 2010 meldeten Hersteller von Chips auf Basis der ARM-Architektur Auslieferungen von 6,1 Milliarden ARM-basierten Prozessoren . Diese entsprachen 95 % der Smartphones , 35 % der digitalen Fernsehgeräte und Set-Top-Boxen sowie 10 % der Mobilcomputer . 2011 war die 32-Bit-ARM-Architektur die am weitesten verbreitete Architektur in Mobilgeräten und die beliebteste 32-Bit-Architektur in eingebetteten Systemen. ^{[ 60 ]} Im Jahr 2013 wurden 10 Milliarden ARM-Prozessoren produziert ^{[ 61 ]} , und „ARM-basierte Chips sind in fast 60 Prozent der weltweiten Mobilgeräte verbaut“. ^{[ 62 ]}

Das Kerngeschäft von Arm Holdings besteht im Verkauf von IP-Cores , die Lizenznehmer zur Entwicklung von Mikrocontrollern (MCUs), CPUs und System-on-Chips auf Basis dieser Cores nutzen. Der Originaldesignhersteller ( ODM) kombiniert den ARM-Core mit weiteren Komponenten zu einem kompletten Gerät, das typischerweise kostengünstig in bestehenden Halbleiterfabriken gefertigt werden kann und dennoch eine hohe Leistungsfähigkeit bietet. Die erfolgreichste Implementierung ist der ARM7TDMI mit mehreren hundert Millionen verkauften Einheiten. Atmel war ein Vorreiter bei der Entwicklung von Embedded-Systemen auf Basis des ARM7TDMI.

Die in Smartphones, PDAs und anderen mobilen Geräten verwendeten ARM-Architekturen reichen von ARMv5 bis ARMv8-A .

Im Jahr 2009 brachten einige Hersteller Netbooks auf den Markt, die auf ARM-Architektur-CPUs basierten und damit in direkter Konkurrenz zu Netbooks mit Intel Atom- Prozessoren standen . ^{[ 63 ]}

Arm Holdings bietet verschiedene Lizenzbedingungen mit unterschiedlichen Kosten und Leistungen an. Alle Lizenznehmer erhalten von Arm Holdings eine integrierbare Hardwarebeschreibung des ARM-Kerns sowie ein komplettes Softwareentwicklungs-Toolset ( Compiler , Debugger , Software Development Kit ) und das Recht, hergestellte Siliziumchips mit der ARM-CPU zu verkaufen .

Zu den SoC-Paketen, die die Kerndesigns von ARM integrieren, gehören die ersten drei Generationen von Nvidia Tegra, die Quatro-Familie von CSR plc, Nova und NovaThor von ST-Ericsson, der Precision32 MCU von Silicon Labs, die OMAP- Produkte von Texas Instruments, die Hummingbird- und Exynos- Produkte von Samsung, A4 , A5 und A5X von Apple sowie i.MX von NXP .

Fabless -Lizenznehmer, die einen ARM-Kern in ihr eigenes Chipdesign integrieren möchten, sind in der Regel nur an einem fertigungsfertigen, verifizierten Halbleiter-IP-Kern interessiert . Für diese Kunden liefert Arm Holdings eine Gate-Netzlistenbeschreibung des gewählten ARM-Kerns sowie ein abstrahiertes Simulationsmodell und Testprogramme zur Unterstützung der Designintegration und -verifizierung. Ambitioniertere Kunden, darunter integrierte Gerätehersteller (IDM) und Foundry-Betreiber, entscheiden sich für den Erwerb des Prozessor-IP in synthetisierbarer RTL -Form ( Verilog ). Mit dem synthetisierbaren RTL kann der Kunde Optimierungen und Erweiterungen auf Architekturebene vornehmen. Dies ermöglicht es dem Entwickler, spezielle Designziele zu erreichen, die mit einer unveränderten Netzliste nicht realisierbar wären ( hohe Taktfrequenz , sehr geringer Stromverbrauch, Befehlssatzerweiterungen usw.). Arm Holdings räumt dem Lizenznehmer zwar nicht das Recht ein, die ARM-Architektur selbst weiterzuverkaufen, Lizenznehmer dürfen jedoch gefertigte Produkte wie Chips, Evaluierungsboards und komplette Systeme frei vertreiben. Für externe Foundry-Unternehmen gelten Sonderregelungen. Sie dürfen nicht nur fertige Siliziumchips mit ARM-Kernen verkaufen, sondern besitzen in der Regel auch das Recht, ARM-Kerne für andere Kunden nachzufertigen.

Arm Holdings legt die Preise für sein geistiges Eigentum anhand des wahrgenommenen Wertes fest. Leistungsschwächere ARM-Kerne haben in der Regel niedrigere Lizenzkosten als leistungsstärkere. Implementierungstechnisch betrachtet ist ein synthetisierbarer Kern teurer als ein fester Makrokern (Blackbox-Kern). Erschwerend kommt hinzu, dass Auftragsfertiger mit einer ARM-Lizenz, wie beispielsweise Samsung oder Fujitsu, ihren Kunden reduzierte Lizenzkosten anbieten können. Im Gegenzug für den Erwerb des ARM-Kerns über die hauseigenen Designdienstleistungen des Auftragsfertigers kann der Kunde die Zahlung der ARM-Lizenzgebühr im Voraus reduzieren oder ganz vermeiden.

Im Vergleich zu spezialisierten Halbleiterherstellern (wie TSMC und UMC ) ohne eigene Designdienstleistungen berechnen Fujitsu/Samsung das Zwei- bis Dreifache pro gefertigtem Wafer . Bei Anwendungen mit geringen bis mittleren Stückzahlen bietet ein Designdienstleister niedrigere Gesamtpreise (durch Subventionierung der Lizenzgebühren). Bei der Massenproduktion großer Stückzahlen reduziert die langfristige Kostensenkung durch niedrigere Waferpreise die Auswirkungen der einmaligen Entwicklungskosten (NRE ) von ARM, wodurch der spezialisierte Hersteller die bessere Wahl darstellt.

Zu den Unternehmen, die Chips mit von Arm entwickelten Kernen entwickelt haben, gehören die Annapurna Labs- Tochtergesellschaft von Amazon.com , ^{[ 64 ]} Analog Devices , Apple , AppliedMicro (jetzt: MACOM Technology Solutions ^{[ 65 ]} ), Atmel , Broadcom , Cavium , Cypress Semiconductor , Freescale Semiconductor (jetzt NXP Semiconductors ), Huawei , Intel , Maxim Integrated , Nvidia , NXP , Qualcomm , Renesas , Samsung Electronics , ST Microelectronics , Texas Instruments und Xilinx .

Im Februar 2016 kündigte ARM die Built on ARM Cortex Technology-Lizenz an, oft kurz Built on Cortex (BoC)-Lizenz genannt. Diese Lizenz ermöglicht es Unternehmen, mit ARM zusammenzuarbeiten und Modifikationen an ARM Cortex-Designs vorzunehmen. Diese Designmodifikationen werden nicht an andere Unternehmen weitergegeben. Diese semi-kundenspezifischen Kerndesigns bieten zudem Markenfreiheit, beispielsweise Kryo 280 .

Zu den Unternehmen, die derzeit Lizenznehmer der Built on ARM Cortex Technology sind, gehört Qualcomm . ^{[ 66 ]}

Unternehmen können außerdem eine ARM -Architekturlizenz erwerben , um eigene CPU-Kerne mithilfe der ARM-Befehlssätze zu entwickeln. Diese Kerne müssen vollständig mit der ARM-Architektur kompatibel sein. Zu den Unternehmen, die Kerne mit einer ARM-Architektur entwickelt haben, gehören Apple, Applied Micro (jetzt: Ampere Computing ), Broadcom, Cavium (jetzt: Marvell), Digital Equipment Corporation , Intel, Nvidia, Qualcomm, Samsung Electronics, Fujitsu und NUVIA Inc. (2021 von Qualcomm übernommen).

Am 16. Juli 2019 kündigte ARM ARM Flexible Access an. ARM Flexible Access bietet unbegrenzten Zugriff auf das enthaltene geistige Eigentum (IP) von ARM für Entwicklungszwecke. Lizenzgebühren pro Produkt werden fällig, sobald ein Kunde die Foundry-Tapeout- oder Prototyping-Phase erreicht. ^{[ 67 ] [ 68 ]}

75 % des neuesten geistigen Eigentums von ARM aus den letzten zwei Jahren sind in ARM Flexible Access enthalten. Stand: Oktober 2019.

• CPUs: Cortex-A5 , Cortex-A7 , Cortex-A32 , Cortex-A34 , Cortex-A35 , Cortex-A53 , Cortex-R5 , Cortex-R8 , Cortex-R52 , Cortex-M0 , Cortex-M0+ , Cortex-M3 , Cortex-M4 , Cortex-M7 , Cortex-M23 , Cortex-M33
• GPUs: Mali-G52 , Mali-G31 . Enthält Mali Driver Development Kits (DDK).
• Verbindungen: CoreLink NIC-400, CoreLink NIC-450, CoreLink CCI-400, CoreLink CCI-500, CoreLink CCI-550, ADB-400 AMBA, XHB-400 AXI-AHB
• Systemcontroller: CoreLink GIC-400, CoreLink GIC-500, PL192 VIC, BP141 TrustZone Memory Wrapper, CoreLink TZC-400, CoreLink L2C-310, CoreLink MMU-500, BP140 Speicherschnittstelle
• Sicherheits-IP: CryptoCell-312, CryptoCell-712, TrustZone Echter Zufallszahlengenerator
• Peripheriegeräte: PL011 UART, PL022 SPI, PL031 RTC
• Debugging & Trace: CoreSight SoC-400, CoreSight SDC-600, CoreSight STM-500, CoreSight System Trace Macrocell, CoreSight Trace Memory Controller
• Design-Kits: Corstone-101, Corstone-201
• Physikalische IP: Artisan PIK für Cortex-M33 TSMC 22ULL ​​einschließlich Speichercompiler, Logikbibliotheken, GPIOs und Dokumentation
• Werkzeuge & Materialien: Socrates IP-Tooling, ARM Design Studio, Virtuelle Systemmodelle
• Support: Standardmäßiger technischer Support für ARM, ARM-Online-Schulungen, Wartungsupdates, Gutschriften für Vor-Ort-Schulungen und Design-Reviews

Arm stellt eine Liste von Anbietern bereit, die ARM-Kerne in ihre Designs integrieren (anwendungsspezifische Standardprodukte (ASSP), Mikroprozessoren und Mikrocontroller). ^{[ 112 ]}

ARM-Prozessoren werden in einer Vielzahl von Produkten eingesetzt, insbesondere in PDAs und Smartphones . Beispiele hierfür sind Microsofts Surface der ersten Generation , Surface 2 und Pocket PCs (ab 2002 ), Apples iPads , Asus ' Eee Pad Transformer Tablet -Computer und diverse Chromebook- Laptops. Weitere Beispiele sind Apples iPhones und iPods , Canon PowerShot Digitalkameras , die Nintendo Switch , die Wii und der 3DS sowie TomTom Navigationssysteme .

Im Jahr 2005 beteiligte sich Arm an der Entwicklung des Computers SpiNNaker der Universität Manchester , der ARM-Kerne zur Simulation des menschlichen Gehirns nutzte . ^{[ 113 ]}

ARM-Chips werden auch in Raspberry Pi , BeagleBoard , BeagleBone , PandaBoard und anderen Einplatinencomputern verwendet , weil sie sehr klein und kostengünstig sind und nur sehr wenig Strom verbrauchen.

Die 32-Bit-ARM-Architektur ( ARM32 ), wie beispielsweise ARMv7-A (die AArch32 implementiert; siehe Abschnitt über Armv8-A für weitere Informationen), war im Jahr 2011 die am weitesten verbreitete Architektur in Mobilgeräten. ^{[ 60 ]}

Seit 1995 dienen verschiedene Versionen des ARM Architecture Reference Manual (siehe § Externe Links ) als primäre Dokumentationsquelle für die ARM-Prozessorarchitektur und den Befehlssatz. Darin werden Schnittstellen, die alle ARM-Prozessoren unterstützen müssen (wie z. B. die Befehlssemantik), von Implementierungsdetails unterschieden, die variieren können. Die Architektur hat sich im Laufe der Zeit weiterentwickelt, und die siebte Version, ARMv7, definiert drei Architekturprofile:

• Das A-Profil, das „Anwendungsprofil“, wird von 32-Bit-Kernen der Cortex-A- Serie und von einigen Nicht-ARM-Kernen implementiert.
• R-Profil, das „Echtzeit“-Profil, wird von den Kernen der Cortex-R- Serie implementiert.
• Das M-Profil, das „Mikrocontroller“-Profil, wird von den meisten Kernen der Cortex-M- Serie implementiert.

Obwohl die Architekturprofile ursprünglich für ARMv7 definiert wurden, definierte ARM später die ARMv6-M-Architektur (die vom Cortex M0 / M0+ / M1 verwendet wird ) als eine Teilmenge des ARMv7-M-Profils mit weniger Befehlen.

ARMv1

26-Bit-Adressierung – veraltet seit Juni 2000. ^{[ 114 ]}

ARMv2

Multiplikations- und Multiplikations-Akkumulationsbefehle; Unterstützung für Koprozessoren – alle Varianten sind seit Juni 2000 veraltet. ^{[ 114 ]}

ARMv2a

Atomare Lade- und Speicherbefehle.

ARMv3

32-Bit-Adressierung ^{[ 114 ]} - alle Varianten sind seit Juli 2005 veraltet. ^{[ 115 ]}

ARMv3G

Keine Unterstützung für 26-Bit-Adressierung. ^{[ 114 ]}

ARMv3M

Long- und Signum-Multiplikatoren. ^{[ 114 ]}

ARMv4

Halbwort-Lade- und Speicherbefehle; Vorzeichenerweiterungs-Byte- und Halbwort-Ladebefehle; Unterstützung für 26-Bit-Adressierung entfernt ^{[ 114 ]}

ARMv4xM

ARMv4, jedoch ohne lange Multiplikation ^{[ 114 ]} - veraltet seit Juli 2005 ^{[ 115 ]}

ARMv4T

ARMv4 plus Version 1 des Thumb -Befehlssatzes ^{[ 114 ]}

ARMv4TxM

ARMv4T, jedoch ohne lange Multiplikation ^{[ 114 ]} - veraltet seit Juli 2005 ^{[ 115 ]}

ARMv5

Anweisung zum Zählen führender Nullen ^{[ 114 ]} - veraltet seit Juli 2005 ^{[ 115 ]}

ARMv5xM

ARMv5, jedoch ohne lange Multiplikation ^{[ 114 ]} - veraltet seit Juli 2005 ^{[ 115 ]}

ARMv5T

ARMv5 plus Version 2 von Thumb ^{[ 114 ]}

ARMv5TxM

ARMv5T, jedoch ohne lange Multiplikation ^{[ 114 ]} - veraltet seit Juli 2005 ^{[ 115 ]}

ARMv5TE

ARMv5T plus erweiterte DSP-Befehle ^{[ 114 ]}

ARMv5TExP

ARMv5TE, jedoch ohne LDRD, MCRR, MRRC, PLD, und STRDerweiterte DSP-Befehle ^{[ 114 ]}

ARMv5TEJ

ARMv5TE plus Jazelle ^{[ 115 ]}

ARMv6

Vollständiger ARMv5TEJ; Byte-Umkehrbefehle; exklusive Zugriffslade- und Speicherbefehle; Byte- und Halbwort-Vorzeichenerweiterungs- und Nullerweiterungsbefehle; SIMD-Medienbefehle; Unterstützung für nicht ausgerichteten Zugriff ^{[ 115 ]}

ARMv6K

ARMv6 plus Befehle zur Unterstützung von Multiprozessorsystemen ^{[ 116 ]}

ARMv6T2

ARMv6 plus Thumb-2 Befehlssatz ^{[ 116 ]}

ARMv7

ARMv7-A, ARMv7-R

Optionale Division mit und ohne Vorzeichen; Speicher- und Synchronisationsbarrierenbefehle; Hinweisbefehl für Vorladebefehle ^{[ 116 ]}

ARMv7-M

Daumen-2 nur ^{[ 117 ]}

ARMv8

Es werden zwei Ausführungszustände eingeführt , AArch32 und AArch64 . Ersterer unterstützt den 32-Bit-ARM-Befehlssatz A32 und den Thumb-2-Befehlssatz T32, letzterer unterstützt einen neuen Befehlssatz mit 32 64-Bit-Registern, genannt A64.

ARMv8-A AArch32, ARMv8-R AArch32

Load-Acquire- und Store-Release-Befehle, Krypto-Befehle, Data-Barrier-Befehlserweiterungen, Send-Event-Locally-Befehl ^{[ 118 ]}

ARMv8-M

Variante Thumb-2 nur ^{[ 119 ]}

Mit Ausnahme des M-Profils spezifiziert die 32-Bit-ARM-Architektur mehrere CPU-Modi, abhängig von den implementierten Architekturmerkmalen. Die CPU kann sich zu jedem Zeitpunkt nur in einem Modus befinden, kann aber aufgrund externer Ereignisse (Interrupts) oder programmatisch zwischen den Modi wechseln. ^{[ 120 ]}

• Benutzermodus: Der einzige nicht privilegierte Modus.
• FIQ-Modus: Ein privilegierter Modus, der immer dann aktiviert wird, wenn der Prozessor eine schnelle Interruptanforderung akzeptiert .
• IRQ-Modus: Ein privilegierter Modus, der immer dann aktiviert wird, wenn der Prozessor eine Interruptanforderung akzeptiert.
• Supervisor-Modus (svc): Ein privilegierter Modus, der immer dann aktiviert wird, wenn die CPU zurückgesetzt wird oder eine SVC-Anweisung ausgeführt wird.
• Abbruchmodus: Ein privilegierter Modus, der immer dann aufgerufen wird, wenn eine Vorabruf- oder Datenabbruch-Ausnahme auftritt.
• Undefinierter Modus: Ein privilegierter Modus, der immer dann aufgerufen wird, wenn eine Ausnahme aufgrund undefinierter Anweisungen auftritt.
• Systemmodus (ARMv4 und höher): Der einzige privilegierte Modus, der nicht durch eine Ausnahme aufgerufen wird. Er kann nur durch Ausführen eines Befehls aufgerufen werden, der explizit in die Modusbits des Registers für den aktuellen Programmstatus (CPSR) aus einem anderen privilegierten Modus (nicht aus dem Benutzermodus) schreibt.
• Monitor-Modus (ARMv6 und ARMv7 Sicherheitserweiterungen, ARMv8 EL3): Es wird ein Monitor-Modus eingeführt, um die TrustZone-Erweiterung in ARM-Kernen zu unterstützen.
• Hyp-Modus (ARMv7 Virtualization Extensions, ARMv8 EL2): Ein Hypervisor-Modus, der die Virtualisierungsanforderungen von Popek und Goldberg für den nicht-sicheren Betrieb der CPU unterstützt. ^{[ 121 ] [ 122 ]}
• Thread-Modus (ARMv6-M, ARMv7-M, ARMv8-M): Ein Modus, der entweder privilegiert oder unprivilegiert konfiguriert werden kann. Ob der Haupt-Stackpointer (MSP) oder der Prozess-Stackpointer (PSP) verwendet wird, kann ebenfalls im CONTROL-Register mit privilegiertem Zugriff festgelegt werden. Dieser Modus ist für Benutzeraufgaben in RTOS-Umgebungen konzipiert, wird aber typischerweise in Bare-Metal-Systemen für Superloop-Operationen eingesetzt.
• Handler-Modus (ARMv6-M, ARMv7-M, ARMv8-M): Ein Modus speziell für die Ausnahmebehandlung (mit Ausnahme von RESET-Fehlern, die im Thread-Modus behandelt werden). Der Handler-Modus verwendet stets MSP und arbeitet auf privilegierter Ebene.

Die ursprüngliche ARM-Implementierung war festverdrahtet und enthielt keinen Mikrocode , ähnlich wie der viel einfachere 8-Bit- Prozessor 6502, der in früheren Acorn-Mikrocomputern verwendet wurde.

Die 32-Bit-ARM-Architektur (und größtenteils auch die 64-Bit-Architektur) umfasst die folgenden RISC-Funktionen:

• Load-Store-Architektur .
• Die ursprüngliche Architekturversion unterstützte keine nicht ausgerichteten Speicherzugriffe . ARMv6 und spätere Versionen, mit Ausnahme einiger Mikrocontroller-Versionen, unterstützen nicht ausgerichtete Zugriffe für Lade-/Speicherbefehle für Halbwort- und Einzelwortoperationen, jedoch mit Einschränkungen, wie beispielsweise dem Fehlen einer garantierten Atomarität . ^{[ 123 ] [ 124 ]}
• Einheitliche 16 × 32-Bit -Registerdatei (einschließlich Programmzähler, Stackpointer und Link-Register).
• Die feste Befehlsbreite von 32 Bit erleichterte die Dekodierung und das Pipelining , führte aber zu einer geringeren Codedichte . Später wurden mit dem Thumb-Befehlssatz 16-Bit-Befehle eingeführt, wodurch die Codedichte erhöht wurde.
• Größtenteils Ausführung in einem einzigen Taktzyklus.

Um den einfacheren Aufbau im Vergleich zu Prozessoren wie dem Intel 80286 und dem Motorola 68020 auszugleichen , wurden einige zusätzliche Designmerkmale verwendet:

• Die bedingte Ausführung der meisten Befehle reduziert den Verzweigungsaufwand und kompensiert das Fehlen einer Verzweigungsvorhersage in frühen Chips.
• Arithmetische Anweisungen ändern Bedingungscodes nur bei Bedarf.
• Der 32-Bit- Barrel-Shifter kann bei den meisten arithmetischen Befehlen und Adressberechnungen ohne Leistungseinbußen verwendet werden.
• Verfügt über leistungsstarke indizierte Adressierungsmodi .
• Ein Link-Register unterstützt schnelle Blattfunktionsaufrufe.
• Ein einfaches, aber schnelles Interrupt -Subsystem mit zwei Prioritätsstufen hat die Registerbänke umgeschaltet.

ARM beinhaltet Ganzzahlarithmetikoperationen für Addition, Subtraktion und Multiplikation; einige Versionen der Architektur unterstützen auch Divisionsoperationen.

ARM unterstützt 32-Bit × 32-Bit-Multiplikationen mit entweder einem 32-Bit- oder einem 64-Bit-Ergebnis, wobei Cortex-M0/M0+/M1-Kerne keine 64-Bit-Ergebnisse unterstützen. ^{[ 125 ]} Einige ARM-Kerne unterstützen außerdem 16-Bit × 16-Bit- und 32-Bit × 16-Bit-Multiplikationen.

Die Divide-Befehle sind nur in den folgenden ARM-Architekturen enthalten:

• Die Architekturen Armv7-M und Armv7E-M beinhalten immer Dividierbefehle. ^{[ 126 ]}
• Die Armv7-R-Architektur enthält immer Divide-Befehle im Thumb-Befehlssatz, optional aber auch im 32-Bit-Befehlssatz. ^{[ 127 ]}
• Die Armv7-A-Architektur enthält optional die Divide-Befehle. Diese Befehle sind möglicherweise nicht implementiert, nur im Thumb-Befehlssatz, sowohl im Thumb- als auch im ARM-Befehlssatz oder nur dann, wenn die Virtualisierungserweiterungen enthalten sind. ^{[ 127 ]}

Die Register R0 bis R7 sind in allen CPU-Modi gleich; sie werden niemals in Bänken aufgeteilt.

Die Register R8 bis R12 sind in allen CPU-Modi außer dem FIQ-Modus identisch. Der FIQ-Modus verfügt über eigene, separate Register R8 bis R12.

Die Register R13 und R14 sind in allen privilegierten CPU-Modi außer dem Systemmodus gebündelt. Das heißt, jeder Modus, der aufgrund einer Ausnahme aufgerufen werden kann, verfügt über eigene Register R13 und R14. Diese Register enthalten üblicherweise den Stackpointer bzw. die Rücksprungadresse von Funktionsaufrufen.

Aliasnamen:

• R13 wird auch als SP, der Stackpointer, bezeichnet .
• R14 wird auch als LR, das Link-Register , bezeichnet .
• R15 wird auch als PC, der Programmzähler, bezeichnet .

Das Register für den aktuellen Programmstatus (CPSR) hat die folgenden 32 Bits. ^{[ 128 ]}

• M (Bits 0–4) sind die Prozessormodus-Bits.
• T (Bit 5) ist das Thumb-Statusbit.
• F (Bit 6) ist das FIQ-Deaktivierungsbit.
• I (Bit 7) ist das IRQ-Deaktivierungsbit.
• A (Bit 8) ist das Bit zur Deaktivierung des Abbruchs bei ungenauen Daten.
• E (Bit 9) ist das Daten-Endianness-Bit.
• IT (Bits 10–15 und 25–26) sind die Wenn-Dann-Zustandsbits.
• GE (Bits 16–19) sind die Größer-oder-gleich-Bits.
• DNM (Bits 20–23) sind die Bits, die nicht verändert werden sollen.
• J (Bit 24) ist das Java-Statusbit.
• Q (Bit 27) ist das Sticky-Overflow-Bit.
• V (Bit 28) ist das Überlaufbit.
• C (Bit 29) ist das Übertrags-/Borrow-/Extend-Bit.
• Z (Bit 30) ist das Nullbit.
• N (Bit 31) ist das Minus-/Kleiner-als-Bit.

Nahezu jeder ARM-Befehl verfügt über eine bedingte Ausführungsfunktion namens Prädikation , die mit einem 4-Bit-Bedingungscode-Selektor (dem Prädikat) implementiert wird. Um eine unbedingte Ausführung zu ermöglichen, bewirkt einer der 4-Bit-Codes, dass der Befehl immer ausgeführt wird. Die meisten anderen CPU-Architekturen verwenden Bedingungscodes nur für Verzweigungsbefehle. ^{[ 129 ]}

Obwohl das Prädikat vier der 32 Bits eines Befehlscodes belegt und somit die für Speicherzugriffe verfügbaren Codierungsbits erheblich reduziert, vermeidet es Verzweigungsbefehle bei der Codegenerierung für kurze ifAnweisungen . Neben der Eliminierung der Verzweigungsbefehle selbst bleibt dadurch die Fetch/Decode/Execute-Pipeline erhalten, und zwar auf Kosten von nur einem Taktzyklus pro übersprungenem Befehl.

Ein Algorithmus, der ein gutes Beispiel für bedingte Ausführung liefert, ist der auf Subtraktion basierende euklidische Algorithmus zur Berechnung des größten gemeinsamen Teilers . In der Programmiersprache C kann der Algorithmus wie folgt geschrieben werden:

int ggT ( int a , int b ) { while ( a != b ) // Die Schleife wird ausgeführt, wenn a < b oder a > b, aber nicht, wenn a == b. if ( a > b ) // Wenn a > b, führen wir dies aus. a -= b ; else // Wenn a < b, führen wir das aus (kein "if (a < b)" nötig, da a != b in der while-Bedingung geprüft wird). b -= a ; return a ; }

Derselbe Algorithmus kann so umgeschrieben werden, dass er näher an den Ziel-ARM- Befehlen liegt , wie folgt:

Schleife : // Vergleiche a und b GT = a > b ; LT = a < b ; NE = a != b ;// Führe Operationen basierend auf den Flag-Ergebnissen durch, falls ( GT ) a -= b ; // Subtrahiere *nur*, wenn größer als falls ( LT ) b -= a ; // Subtrahiere *nur*, wenn kleiner als falls ( NE ) goto loop ; // Schleife *nur*, wenn die verglichenen Werte ungleich waren return a ;

und in Assemblersprache codiert als:

; Weise a dem Register r0 und b dem Register r1 zu. Schleife: CMP r0 , r1 ; Bedingung "NE" setzen, falls (a ≠ b), ; "GT" setzen, falls (a > b), ; oder "LT" setzen, falls (a < b) SUBGT r0 , r0 , r1 ; falls "GT" (Größer als), dann a = a − b SUBLT r1 , r1 , r0 ; falls "LT" (Kleiner als), dann b = b − a BNE Schleife ; falls "NE" (Ungleich), dann Schleife B lr ; zurück

Dadurch werden die Verzweigungen um die thenUND- elseKlauseln vermieden. Wenn r0UND r1gleich sind, wird keine der Anweisungen ausgeführt, wodurch die Notwendigkeit einer bedingten Verzweigung zur Durchführung der Prüfung am Anfang der Schleife SUBentfällt , wie es beispielsweise bei der Verwendung von (kleiner oder gleich) der Fall gewesen wäre. whileSUBLE

Eine Möglichkeit, wie der Thumb-Code eine dichtere Codierung ermöglicht, besteht darin, den Vier-Bit-Selektor aus den Nicht-Verzweigungsanweisungen zu entfernen.

Ein weiteres Merkmal des Befehlssatzes ist die Möglichkeit, Schiebe- und Rotationsoperationen in die Datenverarbeitungsbefehle (arithmetische, logische und Register-Register-Verschiebungen) zu integrieren, sodass beispielsweise die Anweisung in der Programmiersprache C :

a += ( j << 2 );

könnte als einwortige, einzyklusige Anweisung dargestellt werden: ^{[ 130 ]}

ADD Ra , Ra , Rj , LSL #2

Dies führt dazu, dass das typische ARM-Programm dichter ist als erwartet und weniger Speicherzugriffe benötigt; dadurch wird die Pipeline effizienter genutzt.

Der ARM-Prozessor verfügt außerdem über Merkmale, die bei anderen RISC-Architekturen selten zu finden sind, wie etwa die PC -relative Adressierung (tatsächlich ist beim 32-Bit -ARM ^{[ 1 ]} der PC eines seiner 16 Register) und Prä- und Postinkrement-Adressierungsmodi.

Der ARM-Befehlssatz wurde im Laufe der Zeit erweitert. Einige frühe ARM-Prozessoren (vor ARM7TDMI) verfügen beispielsweise über keinen Befehl zum Speichern einer Zwei-Byte-Menge.

Die ARM7-Architektur und frühere Implementierungen verfügen über eine dreistufige Pipeline : Abrufen, Dekodieren und Ausführen. Leistungsstärkere Designs wie der ARM9 besitzen komplexere Pipelines: Der Cortex-A8 hat dreizehn Stufen. Weitere Implementierungsänderungen zur Leistungssteigerung umfassen einen schnelleren Addierer und eine erweiterte Sprungvorhersagelogik . Der Unterschied zwischen den ARM7DI- und ARM7DMI-Kernen bestand beispielsweise in einem verbesserten Multiplizierer; daher das zusätzliche „M“.

Die ARM-Architektur (vor ARMv8) bietet eine nicht-invasive Möglichkeit zur Erweiterung des Befehlssatzes mithilfe von „Koprozessoren“, die über MCR, MRC, MRRC, MCRR und ähnliche Befehle adressiert werden können. Der Koprozessorraum ist logisch in 16 Koprozessoren mit den Nummern 0 bis 15 unterteilt, wobei Koprozessor 15 (cp15) für typische Steuerungsfunktionen wie die Cache-Verwaltung und den MMU- Betrieb auf Prozessoren mit einem solchen reserviert ist.

Bei ARM-basierten Systemen werden Peripheriegeräte üblicherweise an den Prozessor angebunden, indem ihre physischen Register in den ARM-Speicherbereich oder in den Koprozessorbereich abgebildet werden oder indem eine Verbindung zu einem anderen Gerät (einem Bus) hergestellt wird, der wiederum mit dem Prozessor verbunden ist. Koprozessorzugriffe weisen eine geringere Latenz auf, sodass einige Peripheriegeräte – beispielsweise ein XScale-Interrupt-Controller – auf beiden Wegen erreichbar sind: über den Speicher und über Koprozessoren.

In anderen Fällen integrieren Chipdesigner Hardware ausschließlich mithilfe des Koprozessormechanismus. Beispielsweise könnte eine Bildverarbeitungseinheit aus einem kleinen ARM7TDMI-Kern bestehen, der mit einem Koprozessor kombiniert ist, der über spezialisierte Operationen zur Unterstützung bestimmter HDTV-Transkodierungsprimitive verfügt.

Alle modernen ARM-Prozessoren verfügen über Hardware-Debugging-Funktionen, die es Software-Debuggern ermöglichen, Operationen wie Anhalten, schrittweises Ausführen und Setzen von Haltepunkten im Code ab einem Reset durchzuführen. Diese Funktionen basieren auf JTAG- Unterstützung, wobei einige neuere Kerne optional auch ARMs eigenes Zwei-Draht-Protokoll „SWD“ unterstützen. Bei ARM7TDMI-Kernen stand das „D“ für JTAG-Debugging-Unterstützung und das „I“ für das Vorhandensein eines „EmbeddedICE“-Debugging-Moduls. Für die ARM7- und ARM9-Kerngenerationen war EmbeddedICE über JTAG ein De-facto-Debugging-Standard, obwohl er architektonisch nicht garantiert war.

Die ARMv7-Architektur definiert grundlegende Debugging-Funktionen auf Architekturebene. Dazu gehören Haltepunkte, Überwachungspunkte und die Befehlsausführung im „Debug-Modus“. Ähnliche Funktionen standen auch für EmbeddedICE zur Verfügung. Sowohl der „Halt-Modus“ als auch der „Monitor-Modus“ werden unterstützt. Der eigentliche Übertragungsmechanismus für den Zugriff auf die Debugging-Funktionen ist architektonisch nicht spezifiziert, Implementierungen beinhalten jedoch in der Regel JTAG-Unterstützung.

Es gibt eine separate ARM-Debug-Architektur „CoreSight“, die von ARMv7-Prozessoren architektonisch nicht benötigt wird.

Der Debug Access Port (DAP) ist eine Implementierung einer ARM-Debug-Schnittstelle. ^{[ 131 ]} Es gibt zwei verschiedene unterstützte Implementierungen: den Serial Wire JTAG Debug Port (SWJ-DP) und den Serial Wire Debug Port (SW-DP). ^{[ 132 ]} CMSIS-DAP ist eine Standardschnittstelle, die beschreibt, wie verschiedene Debugging-Software auf einem Host-PC über USB mit der Firmware eines Hardware-Debuggers kommunizieren kann. Dieser wiederum kommuniziert über SWD oder JTAG mit einer CoreSight-fähigen ARM Cortex-CPU. ^{[ 133 ] [ 134 ] [ 135 ]}

Zur Verbesserung der ARM-Architektur für digitale Signalverarbeitung und Multimedia-Anwendungen wurden dem Befehlssatz DSP-Befehle hinzugefügt. ^{[ 136 ]} Diese werden durch ein „E“ im Namen der Architekturen ARMv5TE und ARMv5TEJ gekennzeichnet. E-Varianten umfassen auch T, D, M und I.

Die neuen Befehle sind in digitalen Signalprozessorarchitekturen (DSP) üblich. Sie umfassen Variationen der Multiplikation und Akkumulation mit Vorzeichen , der gesättigten Addition und Subtraktion sowie des Zählens führender Nullen .

Diese 1999 erstmals vorgestellte Erweiterung des Kernbefehlssatzes stand im Gegensatz zu ARMs früherem DSP-Coprozessor Piccolo, der einen separaten, inkompatiblen Befehlssatz mit einem eigenen Programmzähler verwendete. ^{[ 137 ]} Piccolo-Befehle nutzten ein separates Registerfile mit sechzehn 32-Bit-Registern. Einige Befehle kombinierten Register zu 48-Bit-Akkumulatoren, andere adressierten 16-Bit-Halbregister. Manche Befehle konnten zwei solcher 16-Bit-Werte parallel verarbeiten. Die Kommunikation mit dem Piccolo-Registerfile erfolgte über Lade- und Speicherbefehle des Piccolo -Coprozessors mithilfe zweier Puffer mit je acht 32-Bit-Einträgen. Ähnlich wie Hitachis SH-DSP und Motorolas 68356 verzichtete Piccolo auf dedizierten lokalen Speicher und nutzte die Bandbreite des ARM-Kerns für den Abruf von DSP-Operanden, was die Leistung bei parallelen Operationen beeinträchtigte. ^{[ 138 ]} Auch der spezielle Befehlssatz von Piccolo erwies sich nicht als „gutes Compilerziel“. ^{[ 137 ]}

Diese Technologie wurde in der ARMv6-Architektur eingeführt und war ein Vorläufer von Advanced SIMD, auch Neon genannt . ^{[ 139 ]}

Jazelle DBX (Direct Bytecode eXecution) ist eine Technik, die es ermöglicht, Java-Bytecode direkt in der ARM-Architektur als dritten Ausführungszustand (und Befehlssatz) neben dem bestehenden ARM- und Thumb-Modus auszuführen. Die Unterstützung dieses Zustands wird durch das „J“ in der ARMv5TEJ-Architektur sowie in den Kernbezeichnungen ARM9EJ-S und ARM7EJ-S gekennzeichnet. Ab ARMv6 ist diese Unterstützung erforderlich (mit Ausnahme des ARMv7-M-Profils), neuere Kerne bieten jedoch nur eine einfache Implementierung ohne Hardwarebeschleunigung.

Um die Dichte des kompilierten Codes zu verbessern, verfügen Prozessoren seit dem ARM7TDMI (veröffentlicht 1994 ^{[ 140 ]} ) über den komprimierten Thumb -Befehlssatz mit eigenem Zustand. (Das „T“ in „TDMI“ steht für Thumb.) In diesem Zustand führt der Prozessor den Thumb-Befehlssatz aus, eine kompakte 16-Bit-Kodierung für eine Teilmenge des ARM-Befehlssatzes. ^{[ 141 ]} Die meisten Thumb-Befehle werden direkt auf normale ARM-Befehle abgebildet. Die Speicherplatzersparnis ergibt sich daraus, dass einige Befehlsoperanden implizit sind und die Anzahl der Möglichkeiten im Vergleich zu den im ARM-Befehlssatzzustand ausgeführten ARM-Befehlen eingeschränkt wird.

In Thumb bieten die 16-Bit-Opcodes weniger Funktionalität. Beispielsweise sind nur Verzweigungen bedingt möglich, und viele Opcodes können nur auf die Hälfte aller Allzweckregister der CPU zugreifen. Die kürzeren Opcodes ermöglichen insgesamt eine höhere Codedichte, obwohl einige Operationen zusätzliche Befehle erfordern. Wenn die Speicherport- oder Busbreite auf weniger als 32 Bit beschränkt ist, ermöglichen die kürzeren Thumb-Opcodes eine höhere Leistung im Vergleich zu 32-Bit-ARM-Code, da weniger Programmcode über die begrenzte Speicherbandbreite in den Prozessor geladen werden muss.

Anders als bei Prozessorarchitekturen mit Befehlen variabler Länge (16 oder 32 Bit), wie beispielsweise dem Cray-1 und dem Hitachi SuperH , existieren die Befehlssätze von ARM und Thumb unabhängig voneinander. Eingebettete Hardware, wie der Game Boy Advance , verfügt typischerweise nur über einen kleinen RAM-Bereich, der über einen vollständigen 32-Bit-Datenpfad zugänglich ist; der Großteil wird über einen 16-Bit- oder schmaleren sekundären Datenpfad angesprochen. In diesem Fall ist es in der Regel sinnvoll, Thumb-Code zu kompilieren und einige der rechenintensivsten Abschnitte manuell mit vollständigen 32-Bit-ARM-Befehlen zu optimieren, indem diese breiteren Befehle in den über den 32-Bit-Bus zugänglichen Speicher ausgelagert werden.

Der erste Prozessor mit einem Thumb -Befehlsdecoder war der ARM7TDMI. Alle Prozessoren, die 32-Bit-Befehlssätze unterstützen, beginnend mit ARM9 und einschließlich XScale, verfügen über einen Thumb-Befehlsdecoder. Dieser beinhaltet Befehle, die vom Hitachi SuperH (1992) übernommen wurden, welcher von ARM lizenziert wurde. ^{[ 142 ]} Die kleinsten Prozessorfamilien von ARM (Cortex M0 und M1) implementieren für maximale Leistung in kostengünstigen Anwendungen ausschließlich den 16-Bit-Thumb-Befehlssatz. ARM-Prozessoren, die keine 32-Bit-Adressierung unterstützen, verzichten ebenfalls auf Thumb.

Die Thumb-2- Technologie wurde im ARM1156-Kern eingeführt , der 2003 vorgestellt wurde. Thumb-2 erweitert den auf 16 Bit begrenzten Befehlssatz von Thumb um zusätzliche 32-Bit-Befehle und ermöglicht so einen Befehlssatz variabler Länge. Ziel von Thumb-2 war es, eine ähnliche Codedichte wie Thumb bei vergleichbarer Performance wie der ARM-Befehlssatz auf 32-Bit-Speicher zu erreichen.

Thumb-2 erweitert den Thumb-Befehlssatz um Bitfeldmanipulation, Tabellenverzweigungen und bedingte Ausführung. Gleichzeitig wurde der ARM-Befehlssatz erweitert, um die gleiche Funktionalität in beiden Befehlssätzen zu gewährleisten. Eine neue „Unified Assembly Language“ (UAL) ermöglicht die Generierung von Thumb- oder ARM-Befehlen aus demselben Quellcode. Die auf ARMv7-Prozessoren verwendeten Thumb-Versionen sind im Wesentlichen so leistungsfähig wie ARM-Code (einschließlich der Möglichkeit, Interrupt-Handler zu schreiben). Dies erfordert etwas Sorgfalt und die Verwendung eines neuen „IT“-Befehls (If-Then), der die Ausführung von bis zu vier aufeinanderfolgenden Befehlen basierend auf einer geprüften Bedingung oder deren Umkehrung ermöglicht. Bei der Kompilierung in ARM-Code wird dieser Befehl ignoriert, bei der Kompilierung in Thumb hingegen erzeugt er einen tatsächlichen Befehl. Zum Beispiel:

; falls (r0 == r1) CMP r0 , r1 ITE EQ ; ARM: kein Code ... Thumb: IT-Anweisung ; dann r0 = r2; MOVEQ r0 , r2 ; ARM: bedingt; Thumb: Bedingung über ITE 'T' (dann) ; sonst r0 = r3; MOVNE r0 , r3 ; ARM: bedingt; Thumb: Bedingung über ITE 'E' (sonst) ; beachte, dass die Thumb MOV-Anweisung keine Bits zur Codierung von "EQ" oder "NE" hat.

Alle ARMv7-Chips unterstützen den Thumb-Befehlssatz. Alle Chips der Cortex-A-Serie, die ARMv7 unterstützen, alle Cortex-R-Serien und alle ARM11-Serien unterstützen sowohl den „ARM-Befehlssatzzustand“ als auch den „Thumb-Befehlssatzzustand“, während Chips der Cortex-M- Serie nur den Thumb-Befehlssatz unterstützen. ^{[ 143 ] [ 144 ] [ 145 ]}

ThumbEE ( in manchen ARM-Dokumentationen fälschlicherweise als Thumb-2EE bezeichnet), das als Jazelle RCT ^{[ 146 ]} (Runtime Compilation Target) vermarktet wurde, wurde 2005 angekündigt und 2011 eingestellt. Es kam erstmals im Cortex-A8- Prozessor zum Einsatz. ThumbEE ist ein vierter Befehlssatzstatus, der geringfügige Änderungen am erweiterten Thumb-2-Befehlssatz vornimmt. Diese Änderungen machen den Befehlssatz besonders geeignet für Code, der zur Laufzeit (z. B. durch JIT-Kompilierung ) in verwalteten Ausführungsumgebungen generiert wird . ThumbEE ist ein Ziel für Sprachen wie Java , C# , Perl und Python und ermöglicht es JIT-Compilern , kleineren kompilierten Code zu erzeugen, ohne die Leistung zu beeinträchtigen.

Zu den neuen Funktionen von ThumbEE gehören automatische Nullzeigerprüfungen bei jedem Lade- und Speicherbefehl, ein Befehl zur Überprüfung der Arraygrenzen sowie spezielle Befehle zum Aufruf eines Handlers. Da ThumbEE die Thumb-2-Technologie nutzt, ermöglicht es außerdem den Zugriff auf die Register r8–r15 (in denen der Zustand der Jazelle/DBX Java VM gespeichert ist). ^{[ 147 ]} Handler sind kleine, häufig aufgerufene Codeabschnitte, die üblicherweise zur Implementierung von Hochsprachen verwendet werden, beispielsweise zur Speicherzuweisung für ein neues Objekt. Diese Änderungen ergeben sich aus der Wiederverwendung einiger weniger Opcodes und der Kenntnis, dass sich der Kern im neuen ThumbEE-Zustand befindet.

Am 23. November 2011 erklärte Arm die Verwendung des ThumbEE-Befehlssatzes für veraltet ^{[ 148 ]} , und Armv8 entfernt die Unterstützung für ThumbEE.

Die VFP- Technologie (Vector Floating Point) ist eine Erweiterung der ARM-Architektur um eine Gleitkommaeinheit (FPU) ^{[ 149 ]} (in Armv8 anders implementiert – dort sind die Koprozessoren nicht definiert). Sie ermöglicht kostengünstige Gleitkomma- Berechnungen mit einfacher und doppelter Genauigkeit und ist vollständig mit dem ANSI/IEEE-Standard Std 754-1985 für binäre Gleitkommaarithmetik kompatibel . VFP eignet sich für eine Vielzahl von Anwendungen, darunter PDAs, Smartphones, Sprachkomprimierung und -dekomprimierung, 3D-Grafik und digitale Audioverarbeitung, Drucker, Set-Top-Boxen und Anwendungen im Automobilbereich. Die VFP-Architektur war ursprünglich für die Ausführung kurzer „Vektormodus“-Befehle vorgesehen. Diese verarbeiteten jedoch jedes Vektorelement sequenziell und erreichten daher nicht die Leistung echter SIMD-Vektorparallelität ( Single Instruction, Multiple Data ). Dieser Vektormodus wurde daher kurz nach seiner Einführung entfernt ^{[ 150 ]} und durch das deutlich leistungsfähigere Advanced SIMD, auch Neon genannt, ersetzt .

Einige Geräte wie der ARM Cortex-A8 verwenden ein abgespecktes VFPLite- Modul anstelle eines vollständigen VFP-Moduls und benötigen etwa zehnmal so viele Taktzyklen pro Gleitkommaoperation. ^{[ 151 ]} Architekturen vor ARMv8 implementierten Gleitkomma-/SIMD-Operationen mit der Coprozessorschnittstelle. Weitere Gleitkomma- und/oder SIMD-Einheiten in ARM-basierten Prozessoren mit Coprozessorschnittstelle sind FPA , FPE und iwMMXt . Einige davon wurden in Software durch Trapping implementiert, hätten aber auch in Hardware realisiert werden können. Sie bieten ähnliche Funktionen wie VFP, sind aber nicht opcode- kompatibel. FPA10 bietet zudem erweiterte Genauigkeit , implementiert jedoch die korrekte Rundung (gemäß IEEE 754) nur in einfacher Genauigkeit. ^{[ 152 ]}

VFPv1

Veraltet

VFPv2

Eine optionale Erweiterung des ARM-Befehlssatzes in den Architekturen ARMv5TE, ARMv5TEJ und ARMv6. VFPv2 verfügt über 16 64-Bit-FPU-Register.

VFPv3 oder VFPv3-D32

Implementiert auf den meisten Cortex-A8- und A9-ARMv7-Prozessoren. Es ist abwärtskompatibel zu VFPv2, kann jedoch keine Gleitkommaausnahmen abfangen. VFPv3 verfügt standardmäßig über 32 64-Bit-FPU-Register, fügt VCVT-Befehle zur Konvertierung zwischen Skalar-, Gleitkomma- und Double-Werten hinzu und erweitert VMOV um den Immediate-Modus, sodass Konstanten in FPU-Register geladen werden können.

VFPv3-D16

Wie oben, jedoch nur mit 16 64-Bit-FPU-Registern. Implementiert auf Cortex-R4- und R5-Prozessoren sowie auf dem Tegra 2 (Cortex-A9).

VFPv3-F16

Ungewöhnlich; es unterstützt IEEE754-2008 Halbgenauigkeit (16-Bit) Gleitkommazahlen als Speicherformat.

VFPv4 oder VFPv4-D32

Implementiert auf Cortex-A12- und A15-ARMv7-Prozessoren, verfügt Cortex-A7 optional über VFPv4-D32 im Falle einer FPU mit Neon. ^{[ 153 ]} VFPv4 besitzt standardmäßig 32 64-Bit-FPU-Register und erweitert die Funktionen von VFPv3 um Unterstützung für Halbgenauigkeit als Speicherformat sowie um FMAP- Befehle (Fused Multiply-Accumulate ).

VFPv4-D16

Wie oben, jedoch mit nur 16 64-Bit-FPU-Registern. Implementiert auf Cortex-A5- und A7-Prozessoren im Falle einer FPU ohne Neon. ^{[ 153 ]}

VFPv5-D16-M

Implementiert auf Cortex-M7, wenn die Option für Gleitkomma-Kerne mit einfacher und doppelter Genauigkeit vorhanden ist.

In Debian Linux und Derivaten wie Ubuntu und Linux Mint bezeichnet armhf ( ARM Hard Float ) die ARMv7-Architektur einschließlich der zusätzlichen Gleitkomma-Hardwareerweiterung VFP3-D16 (und Thumb-2). Softwarepakete und Cross-Compiler-Tools verwenden die Suffixe armhf bzw. arm/armel zur Unterscheidung. ^{[ 154 ]}

Die Advanced SIMD Extension (auch bekannt als Neon oder „MPE“ Media Processing Engine) ist ein kombinierter 64- und 128-Bit -SIMD-Befehlssatz, der standardisierte Beschleunigung für Medien- und Signalverarbeitungsanwendungen bietet. Neon ist in allen Cortex-A8-Geräten enthalten, bei Cortex-A9-Geräten jedoch optional. ^{[ 155 ]} Neon kann MP3-Audiodecodierung auf CPUs mit 10 MHz Taktfrequenz ausführen und den GSM Adaptive Multi-Rate (AMR) Sprachcodec mit 13 MHz nutzen. Es verfügt über einen umfassenden Befehlssatz, separate Registerdateien und unabhängige Ausführungshardware. ^{[ 156 ]} Neon unterstützt 8-, 16-, 32- und 64-Bit-Ganzzahl- und 32-Bit-Gleitkommadaten sowie SIMD-Operationen für die Audio- und Videoverarbeitung sowie für Grafik- und Spieleverarbeitung. In Neon unterstützt die SIMD bis zu 16 Operationen gleichzeitig. Die Neon-Hardware verwendet dieselben Gleitkommaregister wie VFP. Geräte wie der ARM Cortex-A8 und Cortex-A9 unterstützen 128-Bit-Vektoren, verarbeiten aber jeweils nur 64 Bit gleichzeitig ^{[ 151 ]} , während einige leistungsstärkere CPUs wie der Cortex-A15 128 Bit gleichzeitig verarbeiten können. ^{[ 157 ] [ 158 ]}

Eine Besonderheit von Neon auf Armv7-Geräten ist, dass alle subnormalen Zahlen auf Null gesetzt werden. Daher verwendet der GCC-funsafe-math-optimizations -Compiler Neon nur , wenn die Option zum Entfernen denormalisierter Zahlen aktiviert ist. Das seit Armv8 definierte „erweiterte“ Neon weist diese Besonderheit nicht auf, jedoch ist ab GCC 8.2 dieselbe Option weiterhin erforderlich, um Neon-Befehle zu aktivieren. ^{[ 159 ]} Andererseits betrachtet GCC Neon auf AArch64 für Armv8 als sicher.

ProjectNe10 ist ARMs erstes Open-Source-Projekt (seit seiner Gründung; ein älteres Projekt, das nun Mbed TLS heißt, wurde übernommen ). Die Ne10-Bibliothek enthält häufig verwendete, nützliche Funktionen, die sowohl in Neon als auch in C (aus Kompatibilitätsgründen) geschrieben sind. Die Bibliothek wurde entwickelt, um Entwicklern die Nutzung von Neon-Optimierungen zu ermöglichen, ohne Neon lernen zu müssen. Gleichzeitig dient sie als Sammlung hochoptimierter Neon-Intrinsic- und Assembler-Codebeispiele für gängige DSP-, Arithmetik- und Bildverarbeitungsroutinen. Der Quellcode ist auf GitHub verfügbar. ^{[ 160 ]}

Helium ist die M-Profile Vector Extension (MVE). Sie fügt mehr als 150 skalare und Vektorinstruktionen hinzu. ^{[ 161 ]}

Die als TrustZone-Technologie vermarkteten Sicherheitserweiterungen sind in ARMv6KZ- und späteren Anwendungsprofilarchitekturen implementiert. Sie bieten eine kostengünstige Alternative zum Hinzufügen eines weiteren dedizierten Sicherheitskerns zu einem SoC, indem sie zwei virtuelle Prozessoren mit hardwarebasierter Zugriffskontrolle bereitstellen. Dadurch kann der Anwendungskern zwischen zwei Zuständen, sogenannten „ Welten“ (um Verwechslungen mit anderen Bezeichnungen für Funktionsbereiche zu vermeiden), wechseln, um zu verhindern, dass Informationen von der vertrauenswürdigeren Welt (der sicheren Welt ) in die weniger vertrauenswürdige Welt (die normale Welt ) gelangen. ^{[ 162 ]} Dieser Weltenwechsel ist im Allgemeinen orthogonal zu allen anderen Fähigkeiten des Prozessors, sodass jede Welt unabhängig von der anderen mit demselben Kern arbeiten kann. Speicher und Peripheriegeräte werden über die Betriebswelt des Kerns informiert und können diese zur Zugriffskontrolle auf Geheimnisse und Code auf dem Gerät nutzen. ^{[ 163 ]}

Typischerweise wird in weniger vertrauenswürdigen Umgebungen ein umfangreiches Betriebssystem ausgeführt, während in vertrauenswürdigeren Umgebungen kleinerer, sicherheitsspezialisierter Code zum Einsatz kommt, um die Angriffsfläche zu verringern . Typische Anwendungen umfassen DRM- Funktionen zur Kontrolle der Mediennutzung auf ARM-basierten Geräten ^{[ 164 ]} und zur Verhinderung jeglicher unautorisierter Gerätenutzung.

Da die konkreten Implementierungsdetails proprietärer TrustZone-Implementierungen nicht öffentlich zugänglich gemacht wurden, ist in der Praxis unklar, welches Sicherheitsniveau für ein bestimmtes Bedrohungsmodell geboten wird ; sie sind jedoch nicht immun gegen Angriffe. ^{[ 165 ] [ 166 ]}

Open Virtualization ^{[ 167 ]} ist eine Open-Source-Implementierung der Trusted-World-Architektur für TrustZone.

AMD hat die TrustZone-Technologie lizenziert und in seine Secure Processor Technology integriert . ^{[ 168 ]} Die APUs von AMD enthalten einen Cortex-A5-Prozessor für die sichere Datenverarbeitung, der in einigen, aber nicht allen Produkten aktiviert ist. ^{[ 169 ] [ 170 ] [ 171 ]} Tatsächlich war der Cortex-A5 TrustZone-Kern bereits in früheren AMD-Produkten enthalten, wurde aber aus Zeitgründen nicht aktiviert. ^{[ 170 ]}

Samsung Knox nutzt TrustZone unter anderem zur Erkennung von Kernel-Modifikationen, zur Speicherung von Zertifikaten und zur Bestätigung von Schlüsseln. ^{[ 172 ]}

Die Sicherheitserweiterung, die unter dem Namen TrustZone für Armv8-M-Technologie vermarktet wird, wurde mit der Armv8-M-Architektur eingeführt. Obwohl sie ähnliche Konzepte wie TrustZone für Armv8-A enthält, unterscheidet sie sich architektonisch, da der Wechsel zwischen den Sicherheitswelten über Verzweigungsbefehle anstatt über Ausnahmen erfolgt. ^{[ 173 ]} Sie unterstützt zudem die sichere, verschachtelte Interruptbehandlung aus beiden Sicherheitswelten, unabhängig vom aktuellen Sicherheitsstatus. Zusammen ermöglichen diese Funktionen latenzarme Aufrufe der sicheren Welt und eine reaktionsschnelle Interruptbehandlung. ARM stellt einen Referenzstapel des Codes für die sichere Welt in Form von Trusted Firmware für M und PSA-zertifizierter Software bereit .

Ab ARMv6 unterstützt die ARM-Architektur den No-Execute-Page-Schutz , der als XN ( Execute Never) bezeichnet wird . ^{[ 174 ]}

Die Large Physical Address Extension (LPAE), die die Größe der physikalischen Adresse von 32 Bit auf 40 Bit erweitert, wurde 2011 in die Armv7-A-Architektur eingeführt. ^{[ 175 ]}

Die Größe der physikalischen Adresse kann bei Prozessoren, die auf der 64-Bit-Architektur (Armv8-A) basieren, sogar noch größer sein. Beispielsweise beträgt sie 44 Bit beim Cortex-A75 und Cortex-A65AE. ^{[ 176 ]}

Die nach der Architektur Armv8-A angekündigten Architekturen Armv8-R und Armv8-M weisen einige Gemeinsamkeiten mit Armv8-A auf. Allerdings enthält Armv8-M keine 64-Bit-AArch64-Befehle, und auch Armv8-R enthielt ursprünglich keine AArch64-Befehle; diese wurden später zu Armv8-R hinzugefügt.

Die im Februar 2019 angekündigte Armv8.1-M-Architektur ist eine Weiterentwicklung der Armv8-M-Architektur. Sie bietet unter anderem folgende neue Funktionen:

• Eine neue Erweiterung des Vektorbefehlssatzes. Die M-Profile Vector Extension (MVE), auch Helium genannt, ist für Anwendungen in der Signalverarbeitung und im maschinellen Lernen gedacht.
• Zusätzliche Befehlssatzerweiterungen für Schleifen und Verzweigungen (Verzweigungserweiterung mit geringem Overhead).
• Anleitung zur Unterstützung von Gleitkommazahlen mit halber Genauigkeit .
• Befehlssatzerweiterung für die TrustZone-Verwaltung der Gleitkommaeinheit (FPU).
• Neues Speicherattribut in der Speicherschutzeinheit (MPU).
• Verbesserungen im Debugging, einschließlich Performance Monitoring Unit (PMU), Unprivileged Debug Extension und zusätzlicher Debug-Unterstützung, konzentrieren sich auf die Entwicklung von Signalverarbeitungsanwendungen.
• Erweiterung der Zuverlässigkeits-, Verfügbarkeits- und Wartungsfreundlichkeitsfunktionen (RAS).

Die im Oktober 2011 angekündigte ^{[ 14 ]} Armv8-A (oft einfach ARMv8 genannt, obwohl auch Armv8-R verfügbar ist) stellt eine grundlegende Änderung der ARM-Architektur dar. Sie unterstützt zwei Ausführungszustände : einen 64-Bit-Zustand namens AArch64 und einen 32-Bit-Zustand namens AArch32 . Im AArch64-Zustand wird der neue 64-Bit -Befehlssatz A64 unterstützt; im AArch32-Zustand werden zwei Befehlssätze unterstützt: der ursprüngliche 32-Bit-Befehlssatz A32 und der 32-Bit-Befehlssatz Thumb-2 T32 . AArch32 bietet Kompatibilität im Benutzermodus mit Armv7-A. Der Prozessorzustand kann sich bei einer Ausnahmebehandlung ändern. Dies ermöglicht die Ausführung von 32-Bit-Anwendungen im AArch32-Zustand unter einem 64-Bit-Betriebssystem, dessen Kernel im AArch64-Zustand ausgeführt wird, und erlaubt es einem 32-Bit-Betriebssystem, im AArch32-Zustand unter der Kontrolle eines 64-Bit- Hypervisors im AArch64-Zustand zu laufen. ^{[ 1 ]} ARM kündigte seine Cortex-A53- und Cortex-A57-Kerne am 30. Oktober 2012 an. ^{[ 80 ]} Apple brachte als erstes Unternehmen einen Armv8-A-kompatiblen Kern in einem Endkundenprodukt auf den Markt ( Apple A7 im iPhone 5S ). AppliedMicro demonstrierte Armv8-A als erstes Unternehmen mithilfe eines FPGA . ^{[ 177 ]} Der erste Armv8-A- SoC von Samsung ist der Exynos 5433, der im Galaxy Note 4 verwendet wird und über zwei Cluster mit jeweils vier Cortex-A57- und Cortex-A53-Kernen in einer big.LITTLE- Konfiguration verfügt. Es läuft jedoch nur im AArch32-Modus. ^{[ 178 ]}

Sowohl AArch32 als auch AArch64 werden von Armv8-A mit VFPv3/v4 und dem erweiterten SIMD-Standard (Neon) unterstützt. Zusätzlich werden kryptografische Befehle für AES , SHA-1 / SHA-256 und Arithmetik endlicher Körper implementiert . ^{[ 179 ]} AArch64 wurde mit Armv8-A und dessen nachfolgenden Revisionen eingeführt. Die 32-Bit-Architekturen Armv8-R und Armv8-M enthalten AArch64 nicht.

Ein ARMv8-A-Prozessor kann AArch32 und/oder AArch64 unterstützen; er kann AArch32 und AArch64 auf niedrigeren Ausnahmeebenen und nur AArch64 auf höheren Ausnahmeebenen unterstützen. ^{[ 180 ]} Beispielsweise unterstützt der ARM Cortex-A32 nur AArch32, ^{[ 181 ]} der ARM Cortex-A34 nur AArch64, ^{[ 182 ]} und der ARM Cortex-A72 sowohl AArch64 als auch AArch32. ^{[ 183 ]} Ein ARMv9-A-Prozessor muss AArch64 auf allen Ausnahmeebenen unterstützen und kann AArch32 auf EL0 unterstützen. ^{[ 180 ]}

Optionale AArch64-Unterstützung wurde dem Armv8-R-Profil hinzugefügt, wobei der Cortex-R82 der erste ARM-Kern war, der sie implementierte. ^{[ 184 ]} Sie fügt den A64-Befehlssatz hinzu.

Die im März 2021 angekündigte aktualisierte Architektur legt den Fokus auf sichere Ausführung und Kompartimentierung . ^{[ 185 ] [ 186 ]} Die ersten ARMv9-A-Prozessoren, darunter Cortex-A510, Cortex-A710 und Cortex-X2, wurden später im selben Jahr veröffentlicht. ^{[ 187 ] [ 188 ]}

Arm SystemReady ist ein Konformitätsprogramm, das die Interoperabilität von Betriebssystemen auf Arm-basierter Hardware – von Rechenzentrumsservern bis hin zu industriellen Edge- und IoT-Geräten – sicherstellt. Die wichtigsten Bausteine ​​des Programms sind die Spezifikationen für die minimalen Hardware- und Firmware-Anforderungen, auf die sich die Betriebssysteme und Hypervisoren verlassen können. Diese Spezifikationen sind: ^{[ 189 ]}

• Basis-Systemarchitektur (BSA) ^{[ 190 ]} und die marktsegmentspezifischen Ergänzungen (z. B. PC-BSA, Server-BSA) ^{[ 191 ]}
• Basis-Boot-Anforderungen (BBR) ^{[ 192 ]} und Basis-Boot-Sicherheitsanforderungen (BBSR) ^{[ 193 ]}

Diese Spezifikationen werden gemeinsam von Arm und seinen Partnern im System Architecture Advisory Committee (SystemArchAC) entwickelt .

Die Architecture Compliance Suite (ACS) umfasst Testwerkzeuge zur Überprüfung der Konformität mit diesen Spezifikationen. Die Arm SystemReady Requirements Specification dokumentiert die Anforderungen der Zertifizierungen. ^{[ 194 ]}

Dieses Programm wurde 2020 von Arm auf dem ersten DevSummit -Event vorgestellt. Sein Vorgänger, Arm ServerReady, wurde 2018 auf der Arm TechCon präsentiert. Das Programm umfasst derzeit zwei Produktlinien:

• SystemReady-Band: Dieses Band konzentriert sich auf die Interoperabilität von Betriebssystemen für ACPI- Umgebungen (Advanced Configuration and Power Interface), in denen generische Betriebssysteme ohne Modifikationen auf neuer oder älterer Hardware installiert werden können. Dieses Band ist relevant für Systeme, die Windows- , Linux- , VMware- und BSD- Umgebungen verwenden. ^{[ 195 ]}
• SystemReady Devicetree-Band: Dieses Band optimiert Installation und Bootvorgang für eingebettete Systeme, bei denen Devicetree die bevorzugte Methode zur Hardwarebeschreibung ist, mit Fokus auf Vorwärtskompatibilität. Dies gilt insbesondere für Linux- Distributionen und BSD- Umgebungen. ^{[ 196 ]}

PSA Certified (ehemals Platform Security Architecture) ist ein architekturunabhängiges Sicherheitsframework und Bewertungsschema. Es dient der Absicherung von IoT-Geräten ( Internet der Dinge ), die auf System-on-a-Chip (SoC)-Prozessoren basieren. ^{[ 197 ]} Es wurde eingeführt, um die Sicherheit dort zu erhöhen, wo eine vollständige Trusted Execution Environment zu groß oder zu komplex ist. ^{[ 198 ]}

Die Architektur wurde 2017 von Arm auf der jährlichen TechCon- Konferenz vorgestellt. ^{[ 198 ] [ 199 ]} Obwohl das Schema architekturunabhängig ist, wurde es zunächst auf Arm Cortex-M-Prozessorkernen implementiert, die für den Einsatz in Mikrocontrollern vorgesehen sind. PSA Certified umfasst frei verfügbare Bedrohungsmodelle und Sicherheitsanalysen, die den Prozess zur Auswahl von Sicherheitsfunktionen in gängigen IoT-Produkten veranschaulichen. ^{[ 200 ]} Es bietet außerdem frei herunterladbare API-Pakete (Application Programming Interface), Architekturspezifikationen, Open-Source-Firmware-Implementierungen und zugehörige Testsuiten. ^{[ 201 ]}

Nach der Entwicklung des Architektursicherheitsframeworks im Jahr 2017 wurde das PSA-zertifizierte Zertifizierungsprogramm zwei Jahre später auf der Embedded World 2019 eingeführt. ^{[ 202 ]} PSA Certified bietet ein mehrstufiges Sicherheitsbewertungsschema für Chiphersteller, Betriebssystemanbieter und Hersteller von IoT-Geräten. ^{[ 203 ]} Im Rahmen der Präsentation auf der Embedded World wurde Chipherstellern die Zertifizierung der Stufe 1 vorgestellt. Gleichzeitig wurde ein Entwurf für den Schutz der Stufe 2 präsentiert. ^{[ 204 ]} Die Zertifizierung der Stufe 2 wurde im Februar 2020 zu einem anwendbaren Standard. ^{[ 205 ]}

Die Zertifizierung wurde von den PSA Joint Stakeholders entwickelt, um einen Security-by-Design-Ansatz für eine Vielzahl von IoT-Produkten zu ermöglichen. PSA-zertifizierte Spezifikationen sind implementierungs- und architekturunabhängig und können daher auf jeden Chip, jede Software oder jedes Gerät angewendet werden. ^{[ 206 ] [ 204 ]} Die Zertifizierung trägt außerdem zur Verringerung der Branchenfragmentierung für Hersteller und Entwickler von IoT-Produkten bei . ^{[ 207 ]}

Der erste 32-Bit-ARM-basierte Personalcomputer, der Acorn Archimedes , war ursprünglich für den Betrieb eines ambitionierten Betriebssystems namens ARX vorgesehen . Die Rechner wurden mit RISC OS ausgeliefert , das auch auf späteren ARM-basierten Systemen von Acorn und anderen Herstellern zum Einsatz kam. Einige frühe Acorn-Rechner konnten zudem eine Unix- Portierung namens RISC iX ausführen. (Beide sind nicht mit RISC/os zu verwechseln , einer zeitgenössischen Unix-Variante für die MIPS-Architektur.)

Die 32-Bit-ARM-Architektur wird von einer Vielzahl eingebetteter und Echtzeit-Betriebssysteme unterstützt , darunter:

Stand März 2024 war die 32-Bit-ARM-Architektur die primäre Hardwareumgebung für die meisten mobilen Betriebssysteme, wie beispielsweise die folgenden. Viele dieser Plattformen, wie Android und Apple iOS, haben sich jedoch zur 64-Bit-ARM-Architektur weiterentwickelt:

Früher, aber jetzt eingestellt:

Die 32-Bit-ARM-Architektur wird von RISC OS und von mehreren Unix-ähnlichen Betriebssystemen unterstützt, darunter:

• FreeBSD
• NetBSD
• OpenBSD
• OpenSolaris ^{[ 212 ]}
• mehrere Linux- Distributionen, wie zum Beispiel:
  • Debian
  • Armbian
  • Gentoo
  • Ubuntu
  • Raspberry Pi OS (ehemals Raspbian)
  • Slackware

• INTEGRITÄT ^{[ 213 ]}
• OSE ^{[ 214 ]}
• SCIOPTA ^{[ 211 ]}
• seL4 ^{[ 215 ]}
• Pharos ^{[ 209 ]}
• FreeRTOS
• QNX ^{[ 216 ]}
• VxWorks ^{[ 217 ]}
• Zephyr

• Android unterstützt Armv8-A ab Android Lollipop (5.0).
• iOS unterstützt Armv8-A ab iOS 7 auf 64-Bit -Apple-SoCs . iOS 11 und spätere Versionen sowie iPadOS unterstützen ausschließlich 64-Bit-ARM-Prozessoren und -Anwendungen.
• HarmonyOS wurde speziell für ARM-Prozessoren entwickelt, beginnend mit der Markteinführung im Jahr 2024 in Version 5.0 und späteren Versionen.
• Mobian
• PostmarketOS
• Arch Linux ARM
• Manjaro ^{[ 218 ]}

• Die Unterstützung für Armv8-A wurde Ende 2012 in die Linux-Kernel- Version 3.7 integriert. ^{[ 219 ]} Armv8-A wird von einer Reihe von Linux-Distributionen unterstützt , wie zum Beispiel:
  • Debian ^{[ 220 ] [ 221 ]}
  • Armbian
  • Alpine Linux
  • Ubuntu ^{[ 222 ]}
  • Fedora ^{[ 223 ]}
  • NixOS ^{[ 224 ]}
  • openSUSE ^{[ 225 ]}
  • SUSE Linux Enterprise ^{[ 226 ]}
  • RHEL ^{[ 227 ]}
  • Raspberry Pi OS (ehemals Raspbian)
  • Slackware
• Die Unterstützung für Armv8-A wurde Ende 2014 in FreeBSD integriert. ^{[ 228 ]}
• OpenBSD bietet seit 2023 Unterstützung für Armv8. ^{[ 229 ]}
• NetBSD bietet seit Anfang 2018 Unterstützung für Armv8. ^{[ 230 ]}
• Windows – Windows 10 führt 32-Bit- x86- und 32-Bit-ARM-Anwendungen ^{[ 231 ]} sowie native ARM64-Desktop-Apps aus; ^{[ 232 ] [ 233 ]} Windows 11 führt native ARM64-Apps aus und kann außerdem x86- und x86-64-Apps per Emulation ausführen. Die Unterstützung für 64-Bit-ARM-Apps im Microsoft Store ist seit November 2018 verfügbar. ^{[ 234 ]}
• macOS unterstützt ARM seit Ende 2020; die erste Version mit ARM-Unterstützung war macOS Big Sur . ^{[ 235 ]} Rosetta 2 bietet Unterstützung für x86-64 -Anwendungen, jedoch keine Virtualisierung von x86-64-Computerplattformen. ^{[ 236 ]}

Für ARM neu kompilierte und mit Winelib (aus dem Wine -Projekt) verknüpfte Windows-Anwendungen laufen auf 32-Bit- oder 64-Bit-ARM-Systemen unter Linux, FreeBSD oder anderen kompatiblen Betriebssystemen. ^{[ 237 ] [ 238 ]} x86-Binärdateien, z. B. solche, die nicht speziell für ARM kompiliert wurden, konnten zwar mit QEMU und Wine (unter Linux und anderen Systemen) auf ARM-Systemen demonstriert werden , erreichen aber nicht die volle Geschwindigkeit und Funktionalität wie mit Winelib.

• Amber – ein Open-Source-Prozessorkern, der mit ARM kompatibel ist
• AMULET – eine asynchrone Implementierung der ARM-Architektur
• Apple Silicon
• ARM-akkreditierter Ingenieur – Zertifizierungsprogramm
• ARM big.LITTLE – ARMs heterogene Computerarchitektur
  • DynamIQ
• ARMulator – ein Befehlssatzsimulator
• Vergleich von ARM-Prozessoren
• Vergleich der Befehlssatzarchitekturen
• Meltdown (Sicherheitslücke) ^{[ 239 ]}
• Computer mit reduziertem Befehlssatz (RISC)
• RISC-V
• Spectre (Sicherheitslücke)
• Unicore – eine 32-Register-Architektur, die im Wesentlichen auf einem 32-Bit-ARM basiert.