Arm-Architektur

ARM

Designer	Sophie Wilson Steve Furber Acorn Computers/Arm Ltd.
Bits	32-Bit, 64-Bit
Eingeführt	1985; vor 37 Jahren
Aufbau	RISC
Typ	Register-Register
Verzweigung	Bedingungscode, Vergleich und Verzweigung
Offen	Proprietär

ARM 64/32-Bit

Eingeführt	2011; vor 11 Jahren ⓘ
Version	ARMv8-A, ARMv8.1-A, ARMv8.2-A, ARMv8.3-A, ARMv8.4-A, ARMv8.5-A, ARMv8.6-A, ARMv8-R, ARMv9
Kodierung	AArch64/A64 und AArch32/A32 verwenden 32-Bit-Anweisungen, T32 (Thumb-2) verwendet gemischte 16- und 32-Bit-Anweisungen
Endianness	Bi (wenig als Standard)
Erweiterungen	SVE, SVE2, SME, AES, SHA, TME; alle obligatorisch: Thumb-2, Neon, VFPv4-D16, VFPv4; veraltet: Jazelle
Register
Allgemeiner Zweck	31 × 64-Bit-Integer-Register
Fließkomma	32 × 128-Bit-Register für skalare 32- und 64-Bit-FP oder SIMD-FP oder Ganzzahl; oder Kryptographie

ARM 32-Bit (Cortex)

Version	ARMv9-R, ARMv9-M, ARMv8-R, ARMv8-M, ARMv7-A, ARMv7-R, ARMv7E-M, ARMv7-M, ARMv6-M ⓘ
Kodierung	32-Bit, außer Thumb-2-Erweiterungen, die gemischte 16- und 32-Bit-Anweisungen verwenden.
Endianness	Bi (wenig als Standard)
Erweiterungen	Thumb-2, Neon, Jazelle, AES, SHA, DSP, Saturated, FPv4-SP, FPv5, Helium
Register
Allgemeiner Zweck	15 × 32-Bit-Integer-Register, einschließlich R14 (Link-Register), aber nicht R15 (PC)
Fließkomma	Bis zu 32 × 64-Bit-Register, SIMD/Gleitkomma (optional)

ARM 32-Bit (Vorläufer)

Version	ARMv6, ARMv5, ARMv4T, ARMv3, ARMv2 ⓘ
Kodierung	32-Bit, außer Thumb-Erweiterung verwendet gemischte 16- und 32-Bit-Befehle.
Endianness	Bi (wenig als Standard) in ARMv3 und höher
Erweiterungen	Thumb, Jazelle
Register
Allgemeiner Zweck	15 × 32-Bit-Integer-Register, einschließlich R14 (Link-Register), aber nicht R15 (PC, 26-Bit-Adressierung in älteren Versionen)
Fließkomma	Keine

ARM (stilisiert in Kleinbuchstaben als arm, früher ein Akronym für Advanced RISC Machines und ursprünglich Acorn RISC Machine) ist eine Familie von RISC-Befehlssatzarchitekturen (Reduced Instruction Set Computer) für Computerprozessoren, die für verschiedene Umgebungen konfiguriert sind. Arm Ltd. entwickelt die Architekturen und lizenziert sie an andere Unternehmen, die ihre eigenen Produkte entwerfen, die eine oder mehrere dieser Architekturen implementieren, einschließlich System-on-Chip- (SoC) und System-on-Module- (SOM) Designs, die verschiedene Komponenten wie Speicher, Schnittstellen und Funkgeräte enthalten. Das Unternehmen entwirft auch Kerne, die diese Befehlssatzarchitekturen implementieren, und vergibt Lizenzen für diese Entwürfe an viele Unternehmen, die diese Kernentwürfe in ihre eigenen Produkte einbauen. ⓘ

Es hat mehrere Generationen des ARM-Designs gegeben. Der ursprüngliche ARM1 verwendete eine interne 32-Bit-Struktur, hatte aber einen 26-Bit-Adressraum, der ihn auf 64 MB Hauptspeicher beschränkte. Diese Beschränkung wurde mit der ARMv3-Serie aufgehoben, die einen 32-Bit-Adressraum hat, und mehrere weitere Generationen bis hin zu ARMv7 blieben bei 32 Bit. Die 2011 eingeführte ARMv8-A-Architektur unterstützt mit ihrem neuen 32-Bit-Befehlssatz mit fester Länge nun auch einen 64-Bit-Adressraum und 64-Bit-Arithmetik. Arm Ltd. hat außerdem eine Reihe zusätzlicher Befehlssätze für verschiedene Regeln veröffentlicht; die "Thumb"-Erweiterung fügt sowohl 32- als auch 16-Bit-Befehle für eine verbesserte Codedichte hinzu, während Jazelle Befehle für die direkte Verarbeitung von Java-Bytecode hinzufügt. Zu den neueren Änderungen gehört das Hinzufügen von simultanem Multithreading (SMT) zur Verbesserung der Leistung oder Fehlertoleranz. ⓘ

Aufgrund ihrer geringen Kosten, des minimalen Stromverbrauchs und der geringeren Wärmeentwicklung im Vergleich zu ihren Konkurrenten sind ARM-Prozessoren für leichte, tragbare, batteriebetriebene Geräte wie Smartphones, Laptops, Tablet-Computer und andere eingebettete Systeme besonders geeignet. ARM-Prozessoren werden jedoch auch für Desktops und Server verwendet, darunter auch für den schnellsten Supercomputer der Welt im Jahr 2020 (Fugaku). Mit über 200 Milliarden produzierten ARM-Chips (Stand 2021) ist ARM die am weitesten verbreitete Familie von Befehlssatzarchitekturen (ISA) und die am meisten produzierte ISAs. Derzeit gibt es die weit verbreiteten Cortex-Kerne, ältere "klassische" Kerne und spezielle SecurCore-Kerne, für die jeweils Varianten mit oder ohne optionale Funktionen erhältlich sind. ⓘ

Das Logo der Firma Arm ⓘ

ARM-Prozessor von Conexant, der u. a. in Routern verwendet wird ⓘ

Die Arm-Architektur (in älterer Schreibweise ARM-Architektur) ist ein ursprünglich 1983 vom britischen Computerunternehmen Acorn entwickeltes Mikroprozessor-Design, das seit 1990 von der aus Acorn ausgelagerten Firma ARM Limited weiterentwickelt wird. ARM stand für Acorn RISC Machines, später für Advanced RISC Machines. Obwohl der Name außerhalb der IT-Fachwelt wenig bekannt ist, gehören Implementierungen dieses Typs weltweit zu den meistverbreiteten Mikroprozessoren. ⓘ

Geschichte

BBC Micro

Der erste große Erfolg von Acorn Computers war der BBC Micro, der im Dezember 1981 vorgestellt wurde. Es handelte sich dabei um einen relativ konventionellen Rechner, der auf der 6502-CPU von MOS Technology basierte, aber aufgrund der Verwendung eines schnelleren dynamischen Direktzugriffsspeichers (DRAM) etwa doppelt so leistungsfähig war wie konkurrierende Modelle wie der Apple II. Typische DRAMs dieser Zeit liefen mit etwa 2 MHz; Acorn vereinbarte mit Hitachi eine Lieferung von schnelleren 4-MHz-Teilen. ⓘ

Die damaligen Rechner teilten sich in der Regel den Speicher mit dem Prozessor und dem Framebuffer, so dass der Prozessor den Inhalt des Bildschirms schnell aktualisieren konnte, ohne eine separate Eingabe/Ausgabe (E/A) vornehmen zu müssen. Da das Timing der Videowiedergabe sehr anspruchsvoll ist, musste die Videohardware vorrangig auf diesen Speicher zugreifen können. Aufgrund einer Eigenart des 6502-Designs ließ die CPU den Speicher die Hälfte der Zeit unangetastet. Dadurch, dass die CPU mit 1 MHz lief, konnte das Videosystem während dieser Ausfallzeiten Daten lesen und so die gesamte Bandbreite von 2 MHz des RAMs nutzen. Beim BBC Micro konnte durch die Verwendung von 4-MHz-RAM die gleiche Technik eingesetzt werden, allerdings mit doppelter Geschwindigkeit. Damit übertraf er alle vergleichbaren Geräte auf dem Markt. ⓘ

Acorn Business Computer

1981 war auch das Jahr, in dem der IBM Personal Computer eingeführt wurde. Durch die Verwendung des kürzlich eingeführten Intel 8088, einer 16-Bit-CPU im Vergleich zum 8-Bit-Design des 6502, konnte er eine höhere Gesamtleistung bieten. Seine Einführung veränderte den Desktop-Computermarkt radikal: Was in den fünf Jahren zuvor hauptsächlich ein Hobby- und Spielemarkt gewesen war, begann sich zu einem unverzichtbaren Geschäftsinstrument zu entwickeln, bei dem die früheren 8-Bit-Designs einfach nicht mithalten konnten. Auch neuere 32-Bit-Designs kamen auf den Markt, wie der Motorola 68000 und der National Semiconductor NS32016. ⓘ

Acorn begann zu überlegen, wie man auf diesem Markt konkurrieren konnte, und entwickelte ein neues Papierdesign mit dem Namen Acorn Business Computer. Sie setzten sich das Ziel, einen Computer mit der zehnfachen Leistung des BBC Micro zu produzieren, aber zum gleichen Preis. Damit würde er den PC übertreffen und preislich unterbieten. Zur gleichen Zeit wurde mit der Einführung der Apple Lisa das Konzept der grafischen Benutzeroberfläche (GUI) einem breiteren Publikum vorgestellt, und es wurde vermutet, dass die Zukunft den Computern mit einer GUI gehören würde. Die Lisa kostete jedoch 9.995 Dollar, da sie mit Support-Chips, großen Mengen an Speicher und einer Festplatte ausgestattet war, die damals sehr teuer waren. ⓘ

Die Ingenieure begannen daraufhin, alle verfügbaren CPU-Designs zu untersuchen. Sie kamen zu dem Schluss, dass die vorhandenen 16-Bit-Designs viel teurer und immer noch "ein bisschen mies" 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 von Unterstützungschips, um auch nur auf diesem Niveau arbeiten zu können, was die Kosten für den Computer insgesamt in die Höhe trieb. Diese Systeme würden das Entwicklungsziel einfach nicht erreichen. Sie zogen auch die neuen 32-Bit-Designs in Betracht, aber diese kosteten noch mehr und hatten die gleichen Probleme mit den Support-Chips. Laut Sophie Wilson zeigten alle damals getesteten Prozessoren mit einer Bandbreite von etwa 4 Mbit/Sekunde ungefähr die gleiche Leistung. ⓘ

Zwei wichtige Ereignisse führten Acorn auf den Weg zu ARM. Das eine war die Veröffentlichung einer Reihe von Berichten der Universität von Kalifornien, Berkeley, die nahelegten, dass ein einfaches Chipdesign dennoch eine extrem hohe Leistung haben könnte, die weit über der der neuesten 32-Bit-Designs auf dem Markt lag. Der zweite Grund war ein Besuch von Steve Furber und Sophie Wilson beim Western Design Center, einem von Bill Mensch und seiner Schwester geführten Unternehmen, das zum logischen Nachfolger des MOS-Teams geworden war und neue Versionen wie den WDC 65C02 anbot. Das Acorn-Team sah High-School-Schüler, die Chip-Layouts auf Apple-II-Maschinen produzierten, was darauf hindeutete, dass es jeder tun konnte. Ein Besuch bei einer anderen Entwicklungsfirma, die an einer modernen 32-Bit-CPU arbeitete, zeigte dagegen, dass ein Team mit mehr als einem Dutzend Mitgliedern bereits an der Revision H ihres Entwurfs arbeitete und dieser noch immer Fehler enthielt. Dies bestärkte sie Ende 1983 in ihrer Entscheidung, mit der Entwicklung einer eigenen CPU zu beginnen, der Acorn RISC Machine. ⓘ

Design-Konzepte

Die ursprünglichen Berkeley-RISC-Entwürfe waren in gewisser Weise Lehrsysteme, die nicht speziell für eine hohe Leistung konzipiert waren. Zu den grundlegenden registerlastigen und Lade-/Speicherkonzepten des RISC fügte ARM eine Reihe der gut angenommenen Entwurfsmerkmale des 6502 hinzu. Dazu gehörte in erster Linie die Fähigkeit, Interrupts schnell zu bedienen, wodurch die Maschinen ohne zusätzliche externe Hardware eine angemessene Ein-/Ausgabeleistung bieten konnten. Um Interrupts mit ähnlicher Leistung wie beim 6502 anbieten zu können, beschränkte der ARM-Entwurf seinen physikalischen Adressraum auf 64 MB adressierbaren Gesamtraum, was 26 Bit Adresse erforderte. Da die Befehle 4 Byte (32 Bit) lang waren und an 4-Byte-Grenzen ausgerichtet werden mussten, waren die unteren 2 Bit einer Befehlsadresse immer Null. Dies bedeutete, dass der Programmzähler (PC) nur 24 Bits lang sein musste, so dass er zusammen mit den 8-Bit-Prozessor-Flags in einem einzigen 32-Bit-Register gespeichert werden konnte. Das bedeutete, dass beim Empfang einer Unterbrechung der gesamte Maschinenzustand in einer einzigen Operation gespeichert werden konnte, während bei einem vollen 32-Bit-Wert des PC separate Operationen zur Speicherung des PC und der Statusflags erforderlich gewesen wären. Durch diese Entscheidung konnte der Interrupt-Overhead halbiert werden. ⓘ

Eine weitere Änderung, die im Hinblick auf die praktische Leistung mit am wichtigsten ist, war die Modifizierung des Befehlssatzes, um die Vorteile des Seitenmodus-DRAM zu nutzen. Der vor kurzem eingeführte Seitenmodus ermöglichte es, dass aufeinanderfolgende Speicherzugriffe doppelt so schnell abliefen, wenn sie sich ungefähr an der gleichen Stelle oder "Seite" im DRAM-Chip befanden. Der Berkeley-Entwurf berücksichtigte den Seitenmodus nicht und behandelte alle Speicher gleich. Der ARM-Entwurf fügte spezielle vektorähnliche Speicherzugriffsbefehle, die "S-Zyklen", hinzu, die zum Füllen oder Speichern mehrerer Register in einer einzigen Seite im Seitenmodus verwendet werden konnten. Dies verdoppelte die Speicherleistung, wenn sie verwendet werden konnten, und war besonders wichtig für die Grafikleistung. ⓘ

Die Berkeley-RISC-Entwürfe verwendeten Registerfenster, um die Anzahl der Registerspeicherungen und -wiederherstellungen bei Prozeduraufrufen zu reduzieren; der ARM-Entwurf übernahm dies nicht. ⓘ

Wilson entwickelte den Befehlssatz und schrieb eine Simulation des Prozessors in BBC BASIC, die auf einem BBC Micro mit einem zweiten 6502-Prozessor lief. Dies überzeugte die Acorn-Ingenieure davon, dass sie auf dem richtigen Weg waren. Wilson wandte sich an den Geschäftsführer von Acorn, Hermann Hauser, und bat um mehr Ressourcen. Hauser stimmte zu und stellte ein kleines Team zusammen, um den eigentlichen Prozessor auf der Grundlage von Wilsons ISA zu entwickeln. Das offizielle Acorn RISC Machine-Projekt begann im Oktober 1983. ⓘ

ARM1

ARM1 2. Prozessor für den BBC Micro ⓘ

Acorn entschied sich für VLSI Technology als "Siliziumpartner", da sie eine Quelle für ROMs und kundenspezifische Chips für Acorn waren. Acorn lieferte das Design und VLSI das Layout und die Produktion. Die ersten Muster des ARM-Siliziums funktionierten ordnungsgemäß, als sie am 26. April 1985 eintrafen und getestet wurden. Diese als ARM1 bezeichneten Versionen liefen mit 6 MHz. ⓘ

Der erste Einsatz des ARM war als zweiter Prozessor für den BBC Micro, wo er bei der Entwicklung von Simulationssoftware half, um die Entwicklung der Support-Chips (VIDC, IOC, MEMC) abzuschließen, und die CAD-Software für die ARM2-Entwicklung beschleunigte. Anschließend schrieb Wilson BBC BASIC in ARM-Assemblersprache um. Dank der gründlichen Kenntnisse, die er bei der Entwicklung des Befehlssatzes gewonnen hatte, konnte der Code sehr dicht sein, so dass ARM BBC BASIC ein extrem guter Test für jeden ARM-Emulator ist. ⓘ

ARM2

Die Ergebnisse der Simulationen auf den ARM1-Boards führten Ende 1986 zur Einführung des ARM2-Designs, das mit 8 MHz lief, und Anfang 1987 zu einer beschleunigten Version mit 10 bis 12 MHz. Eine wesentliche Änderung der zugrundeliegenden Architektur war die Hinzufügung eines Booth-Multiplikators, während die Multiplikation zuvor in Software durchgeführt werden musste. Außerdem ermöglichte ein neuer Fast-Interrupt-Request-Modus, kurz FIQ, den Austausch der Register 8 bis 14 als Teil des Interrupts selbst. Dies bedeutete, dass FIQ-Anfragen ihre Register nicht auslagern mussten, was die Interrupts weiter beschleunigte. ⓘ

Der ARM2 war etwa siebenmal so leistungsfähig wie ein typisches 7-MHz-System auf 68000-Basis wie der Commodore Amiga oder der Macintosh SE. Er war doppelt so schnell wie ein Intel 80386 mit 16 MHz und etwa genauso schnell wie ein VAX-11/784-Multiprozessor-Superminicomputer. Die einzigen Systeme, die ihn übertrafen, waren die RISC-basierten Workstations Sun SPARC und MIPS R2000. Da die CPU für Hochgeschwindigkeits-E/A ausgelegt war, konnte sie auf viele der in diesen Rechnern vorhandenen Unterstützungschips verzichten; insbesondere fehlte ein dedizierter DMA-Controller (Direct Memory Access), wie er häufig in Workstations zu finden war. Auch das Grafiksystem wurde auf der Grundlage derselben grundlegenden Annahmen über Speicher und Timing vereinfacht. Das Ergebnis war ein drastisch vereinfachtes Design, das eine Leistung auf dem Niveau teurer Workstations bot, aber zu einem Preis, der dem moderner Desktops entsprach. ⓘ

Der ARM2 verfügte über einen 32-Bit-Datenbus, einen 26-Bit-Adressraum und 27 32-Bit-Register, von denen 16 gleichzeitig zugänglich sind (einschließlich PC). Der ARM2 hatte nur 30.000 Transistoren, verglichen mit dem sechs Jahre älteren Modell 68000 von Motorola mit rund 68.000. Ein Großteil dieser Einfachheit ist auf das Fehlen von Mikrocode zurückzuführen, der etwa ein Viertel bis ein Drittel der Transistoren des 68000 ausmacht, sowie auf das Fehlen eines Cache (wie bei den meisten CPUs dieser Zeit). Diese Einfachheit ermöglichte es dem ARM2, einen niedrigen Stromverbrauch zu haben und dennoch eine bessere Leistung als der Intel 80286 zu bieten. ⓘ

Das Nachfolgemodell ARM3 wurde mit einem 4-KB-Cache ausgestattet, was die Leistung weiter verbesserte. Beim ARM6 wurde der Adressbus auf 32 Bit erweitert, aber der Programmcode musste wegen der reservierten Bits für die Statusflags immer noch innerhalb der ersten 64 MB des Speichers im 26-Bit-Kompatibilitätsmodus liegen. ⓘ

Erweiterte RISC-Maschinen Ltd. - ARM6

Mikroprozessor-basiertes System auf einem Chip ⓘ

Chip eines ARM610-Mikroprozessors ⓘ

In den späten 1980er Jahren begannen Apple Computer und VLSI Technology 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, das 1998 mit dem Börsengang der Muttergesellschaft Arm Holdings plc an der Londoner Börse und der NASDAQ in ARM Ltd. umbenannt wurde. Aus der neuen Apple-ARM-Arbeit ging schließlich der ARM6 hervor, der Anfang 1992 erstmals veröffentlicht wurde. Apple verwendete den ARM6-basierten ARM610 als Grundlage für seinen Apple Newton PDA. ⓘ

Frühe Lizenznehmer

1994 verwendete Acorn den ARM610 als Hauptzentraleinheit (CPU) in seinen RiscPC-Computern. DEC lizenzierte die ARMv4-Architektur und produzierte den StrongARM. Mit 233 MHz verbrauchte diese CPU nur ein Watt (neuere Versionen verbrauchen weit weniger). Diese Arbeit wurde später im Rahmen eines Rechtsstreits an Intel übergeben, und Intel nutzte die Gelegenheit, um seine i960-Reihe mit dem StrongARM zu ergänzen. Später entwickelte Intel seine eigene Hochleistungsimplementierung namens XScale, die es inzwischen an Marvell verkauft hat. Die Transistorzahl des ARM-Kerns blieb während dieser Änderungen im Wesentlichen gleich; ARM2 hatte 30.000 Transistoren, während ARM6 nur auf 35.000 anstieg. ⓘ

Marktanteil

Im Jahr 2005 verwendeten etwa 98 % aller verkauften Mobiltelefone mindestens einen ARM-Prozessor. Im Jahr 2010 meldeten die Hersteller von Chips, die auf ARM-Architekturen basieren, einen Absatz von 6,1 Milliarden ARM-basierten Prozessoren, was 95 % der Smartphones, 35 % der digitalen Fernsehgeräte und Set-Top-Boxen und 10 % der mobilen Computer entspricht. Im Jahr 2011 war die 32-Bit-ARM-Architektur die am weitesten verbreitete Architektur in mobilen Geräten und die beliebteste 32-Bit-Architektur in eingebetteten Systemen. Im Jahr 2013 wurden 10 Milliarden Stück produziert, und "ARM-basierte Chips finden sich in fast 60 Prozent der weltweiten Mobilgeräte". ⓘ

Lizenzierung

Chip eines STM32F103VGT6 ARM Cortex-M3-Mikrocontrollers mit 1 MB Flash-Speicher von STMicroelectronics ⓘ

Kern-Lizenz

Das Hauptgeschäft von Arm Ltd. ist der Verkauf von IP-Cores, die Lizenznehmer zur Entwicklung von Mikrocontrollern (MCUs), CPUs und System-on-Chips auf der Grundlage dieser Cores verwenden. Der Hersteller des Originaldesigns kombiniert den ARM-Kern mit anderen Teilen, um ein komplettes Gerät herzustellen, das in der Regel in bestehenden Halbleiterfabriken zu geringen Kosten gebaut werden kann und dennoch eine beachtliche Leistung bietet. Die erfolgreichste Implementierung ist der ARM7TDMI, von dem Hunderte von Millionen Stück verkauft wurden. Atmel war ein Vorreiter bei der Entwicklung von ARM7TDMI-basierten eingebetteten Systemen. ⓘ

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

Im Jahr 2009 führten einige Hersteller Netbooks mit ARM-Architektur-CPUs ein, die in direkter Konkurrenz zu Netbooks mit Intel-Atom-Prozessoren stehen. ⓘ

Arm Ltd. bietet eine Vielzahl von Lizenzbedingungen an, die sich hinsichtlich der Kosten und des Leistungsumfangs unterscheiden. Arm Ltd. stellt allen Lizenznehmern eine integrierbare Hardwarebeschreibung des ARM-Kerns sowie ein vollständiges Softwareentwicklungs-Toolset (Compiler, Debugger, Software Development Kit) und das Recht zum Verkauf von hergestelltem Silizium mit der ARM-CPU zur Verfügung. ⓘ

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

Fabless-Lizenznehmer, die einen ARM-Kern in ihr eigenes Chipdesign integrieren möchten, sind in der Regel nur daran interessiert, einen fertigungsfertigen, verifizierten Halbleiterkern mit geistigem Eigentum zu erwerben. Für diese Kunden liefert Arm Ltd. eine Gatternetzlistenbeschreibung des gewählten ARM-Kerns, zusammen mit einem abstrahierten Simulationsmodell und Testprogrammen zur Unterstützung der Designintegration und -verifizierung. Anspruchsvollere Kunden, darunter Hersteller von integrierten Bauelementen (IDM) und Foundry-Betreiber, entscheiden sich für den Erwerb der Prozessor-IP in synthetisierbarer RTL-Form (Verilog). Mit dem synthetisierbaren RTL hat der Kunde die Möglichkeit, Optimierungen und Erweiterungen auf Architekturebene vorzunehmen. Dadurch kann der Designer exotische Designziele erreichen, die mit einer unmodifizierten Netzliste nicht möglich sind (hohe Taktrate, sehr geringer Stromverbrauch, Befehlssatzerweiterungen usw.). Während Arm Ltd. dem Lizenznehmer nicht das Recht einräumt, die ARM-Architektur selbst weiterzuverkaufen, können Lizenznehmer hergestellte Produkte wie Chip-Bausteine, Evaluierungsboards und komplette Systeme frei verkaufen. Einen Sonderfall stellen die Merchant Foundries dar, die nicht nur fertiges Silizium mit ARM-Kernen verkaufen dürfen, sondern im Allgemeinen auch das Recht haben, ARM-Kerne für andere Kunden weiterzuverarbeiten. ⓘ

Arm Ltd. legt die Preise für sein geistiges Eigentum auf der Grundlage des wahrgenommenen Wertes fest. Leistungsschwächere ARM-Cores haben in der Regel niedrigere Lizenzkosten als leistungsstärkere. In Bezug auf die Implementierung kostet ein synthetisierbarer Kern mehr als ein harter Makrokern (Blackbox). Erschwerend kommt hinzu, dass eine Foundry, die über eine ARM-Lizenz verfügt, wie Samsung oder Fujitsu, ihren Fab-Kunden niedrigere Lizenzkosten anbieten kann. Im Gegenzug für den Erwerb des ARM-Kerns durch die internen Design-Services der Foundry kann der Kunde die Zahlung der ARM-Lizenzgebühr reduzieren oder ganz abschaffen. ⓘ

Im Vergleich zu dedizierten Halbleiter-Foundries (wie TSMC und UMC) ohne eigene Design-Services verlangen Fujitsu/Samsung das Zwei- bis Dreifache pro hergestelltem Wafer. Für Anwendungen mit geringen bis mittleren Stückzahlen bietet eine Design-Service-Foundry niedrigere Gesamtpreise (durch Subventionierung der Lizenzgebühr). Bei großvolumigen Massenbauteilen verringert die langfristige Kostensenkung, die durch niedrigere Waferpreise erreicht werden kann, die Auswirkungen der NRE-Kosten (Non-Recurring Engineering) von ARM, so dass eine spezielle Foundry die bessere Wahl ist. ⓘ

Zu den Unternehmen, die Chips mit von Arm Holdings entwickelten Kernen entwickelt haben, gehören die Amazon.com-Tochter Annapurna Labs, Analog Devices, Apple, AppliedMicro (jetzt: MACOM Technology Solutions), 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. ⓘ

Lizenz für ARM-Cortex-Technologie

Im Februar 2016 kündigte ARM die "Built on ARM Cortex Technology"-Lizenz an, oft abgekürzt als "Built on Cortex"-Lizenz (BoC). Diese Lizenz erlaubt es Unternehmen, mit ARM zusammenzuarbeiten und Änderungen an ARM Cortex-Designs vorzunehmen. Diese Designänderungen werden nicht an andere Unternehmen weitergegeben. Diese Semi-Custom-Core-Designs haben auch Markenfreiheit, zum Beispiel Kryo 280. ⓘ

Zu den Unternehmen, die derzeit Lizenznehmer der Built on ARM Cortex-Technologie sind, gehört Qualcomm. ⓘ

Architektonische Lizenz

Unternehmen können auch eine ARM-Architekturlizenz erwerben, um ihre eigenen CPU-Kerne unter Verwendung der ARM-Befehlssätze zu entwickeln. Diese Kerne müssen vollständig mit der ARM-Architektur übereinstimmen. Zu den Unternehmen, die Kerne entwickelt haben, die eine ARM-Architektur umsetzen, gehören Apple, AppliedMicro (jetzt: Ampere Computing), Broadcom, Cavium (jetzt: Marvell), Digital Equipment Corporation, Intel, Nvidia, Qualcomm, Samsung Electronics, Fujitsu und NUVIA Inc. ⓘ

ARM Flexible Access

Am 16. Juli 2019 kündigte ARM den ARM Flexible Access an. ARM Flexible Access bietet unbegrenzten Zugang zu enthaltenem geistigen Eigentum (IP) von ARM für die Entwicklung. Sobald ein Kunde das Foundry Tapeout oder Prototyping erreicht hat, werden Lizenzgebühren pro Produkt fällig. ⓘ

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).
• Interconnect: CoreLink NIC-400, CoreLink NIC-450, CoreLink CCI-400, CoreLink CCI-500, CoreLink CCI-550, ADB-400 AMBA, XHB-400 AXI-AHB
• System-Steuerungen: CoreLink GIC-400, CoreLink GIC-500, PL192 VIC, BP141 TrustZone Memory Wrapper, CoreLink TZC-400, CoreLink L2C-310, CoreLink MMU-500, BP140 Memory Interface
• Sicherheits-IP: CryptoCell-312, CryptoCell-712, TrustZone True Random Number Generator
• Peripherie-Controller: PL011 UART, PL022 SPI, PL031 RTC
• Debug & 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 Speicher-Compiler, Logik-Bibliotheken, GPIOs und Dokumentation
• Werkzeuge und Materialien: Socrates IP ToolingARM Design Studio, Virtuelle Systemmodelle
• Unterstützung: Technischer Standard-Support von ARM, ARM-Online-Schulungen, Wartungs-Updates, Gutschriften für Vor-Ort-Schulungen und Design-Reviews ⓘ

Kerne

Architektur	Kern Bit-Breite	Kerne		Profil	Referenz- renzen ⓘ
		Arm Ltd.	Drittanbieter
ARMv1	32	ARM1		Klassisch
ARMv2	32	ARM2, ARM250, ARM3	Amber, STORM Open Soft Core	Klassisch
ARMv3	32	ARM6, ARM7		Klassisch
ARMv4	32	ARM8	StrongARM, FA526, ZAP Offener Quellprozessorkern	Klassisch
ARMv4T	32	ARM7TDMI, ARM9TDMI, SecurCore SC100		Klassisch
ARMv5TE	32	ARM7EJ, ARM9E, ARM10E	XScale, FA626TE, Feroceon, PJ1/Mohawk	Klassisch
ARMv6	32	ARM11		Klassisch
ARMv6-M	32	ARM Cortex-M0, ARM Cortex-M0+, ARM Cortex-M1, SecurCore SC000		Mikrocontroller
ARMv7-M	32	ARM Cortex-M3, SecurCore SC300	Apfel M7	Mikrocontroller
ARMv7E-M	32	ARM Cortex-M4, ARM Cortex-M7		Mikrocontroller
ARMv8-M	32	ARM-Cortex-M23, ARM-Cortex-M33		Mikrocontroller
ARMv7-R	32	ARM Cortex-R4, ARM Cortex-R5, ARM Cortex-R7, ARM Cortex-R8		Echtzeit
ARMv8-R	32	ARM Cortex-R52		Echtzeit
	64	ARM Cortex-R82		Echtzeit
ARMv7-A	32	ARM Cortex-A5, ARM Cortex-A7, ARM Cortex-A8, ARM Cortex-A9, ARM Cortex-A12, ARM Cortex-A15, ARM Cortex-A17	Qualcomm Scorpion/Krait, PJ4/Sheeva, Apple Swift (A6, A6X)	Anwendung
ARMv8-A	32	ARM Cortex-A32		Anwendung
	64/32	ARM Cortex-A35, ARM Cortex-A53, ARM Cortex-A57, ARM Cortex-A72, ARM Cortex-A73	X-Gene, Nvidia Denver 1/2, Cavium ThunderX, AMD K12, Apple Cyclone (A7)/Typhoon (A8, A8X)/Twister (A9, A9X)/Hurricane+Zephyr (A10, A10X), Qualcomm Kryo, Samsung M1/M2 ("Mongoose") /M3 ("Meerkat")	Anwendung
	64	ARM Cortex-A34		Anwendung
ARMv8.1-A	64/32	TBA	Cavium ThunderX2	Anwendung
ARMv8.2-A	64/32	ARM Cortex-A55, ARM Cortex-A75, ARM Cortex-A76, ARM Cortex-A77, ARM Cortex-A78, ARM Cortex-X1, ARM Neoverse N1	Nvidia Carmel, Samsung M4 ("Cheetah"), Fujitsu A64FX (ARMv8 SVE 512-bit)	Anwendung
	64	ARM Cortex-A65, ARM Neoverse E1 mit simultanem Multithreading (SMT), ARM Cortex-A65AE (auch mit z. B. ARMv8.4 Dot Product; für sicherheitskritische Aufgaben wie fortgeschrittene Fahrerassistenzsysteme (ADAS))	Apple Monsoon+Mistral (A11) (September 2017)	Anwendung
ARMv8.3-A	64/32	TBA		Anwendung
	64	TBA	Apple Vortex+Tempest (A12, A12X, A12Z), Marvell ThunderX3 (v8.3+)	Anwendung
ARMv8.4-A	64/32	TBA		Anwendung
	64	ARM Neoverse V1	Apple Lightning+Thunder (A13), Apple Firestorm+Icestorm (A14), Apple Firestorm+Icestorm (M1)	Anwendung
ARMv8.5-A	64/32	TBA		Anwendung
	64	TBA	Apple Avalanche+Blizzard (A15)	Anwendung
ARMv8.6-A	64	TBA		Anwendung
ARMv8.7-A	64	TBA		Anwendung
ARMv9-A	64	ARM Cortex-A510, ARM Cortex-A710, ARM Cortex-X2, ARM Neoverse N2		Anwendung

Arm Holdings stellt eine Liste von Anbietern zur Verfügung, die ARM-Cores in ihre Designs implementieren (anwendungsspezifische Standardprodukte (ASSP), Mikroprozessoren und Mikrocontroller). ⓘ

Anwendungsbeispiele für ARM-Cores

Tronsmart MK908, ein Rockchip-basierter Quad-Core-Android-"Mini-PC", mit einer microSD-Karte daneben für einen Größenvergleich ⓘ

ARM-Kerne werden in einer Reihe von Produkten eingesetzt, insbesondere in PDAs und Smartphones. Einige Beispiele für Computer sind Microsofts Surface der ersten Generation, Surface 2 und Pocket PC-Geräte (ab 2002), Apples iPads und Asus' Eee Pad Transformer Tablet-Computer sowie mehrere Chromebook-Laptops. Weitere Produkte sind Apples iPhone-Smartphones und die tragbaren Mediaplayer iPod, Canon PowerShot-Digitalkameras, die Nintendo Switch-Hybridkonsole, der Wii-Sicherheitsprozessor und die 3DS-Handheld-Spielkonsolen sowie die TomTom-Navigationssysteme mit Abbiegefunktion. ⓘ

Im Jahr 2005 beteiligte sich Arm Holdings an der Entwicklung des Computers SpiNNaker der Universität Manchester, der ARM-Kerne zur Simulation des menschlichen Gehirns verwendete. ⓘ

ARM-Chips werden auch in Raspberry Pi, BeagleBoard, BeagleBone, PandaBoard und anderen Einplatinencomputern verwendet, da sie sehr klein und preiswert sind und nur wenig Strom verbrauchen. ⓘ

32-Bit-Architektur

Ältere Versionen der beliebten Raspberry Pi-Einplatinencomputer wie dieser Raspberry Pi 2 aus dem Jahr 2015 wurden mit einem ARMv7 betrieben. ⓘ

Ein ARMv7 wird auch für die CuBox-Familie von Einplatinencomputern verwendet. ⓘ

Die 32-Bit-ARM-Architektur (ARM32), wie z. B. ARMv7-A (die AArch32 implementiert; siehe Abschnitt über ARMv8-A), war 2011 die am häufigsten verwendete Architektur in mobilen Geräten. ⓘ

Seit 1995 sind die verschiedenen Versionen des ARM-Architektur-Referenzhandbuchs (siehe § Externe Links) die wichtigste Quelle für die Dokumentation der ARM-Prozessorarchitektur und des Befehlssatzes, wobei zwischen Schnittstellen, die alle ARM-Prozessoren unterstützen müssen (z. B. die Befehlssemantik), und Implementierungsdetails, die variieren können, unterschieden wird. Die Architektur hat sich im Laufe der Zeit weiterentwickelt, und die Version sieben der Architektur, ARMv7, definiert drei Architektur-"Profile":

• A-Profil, das "Anwendungs"-Profil, das von den 32-Bit-Kernen der Cortex-A-Serie und von einigen Nicht-ARM-Kernen implementiert wird
• R-Profil, das "Echtzeit"-Profil, das von den Cortex-R-Kernen implementiert wird
• M-Profil, das "Mikrocontroller"-Profil, das von den meisten Kernen der Cortex-M-Serie implementiert wird ⓘ

Obwohl die Architekturprofile zunächst für ARMv7 definiert wurden, definierte ARM später die ARMv6-M-Architektur (die von den Cortex M0/M0+/M1 verwendet wird) als Teilmenge des ARMv7-M-Profils mit weniger Anweisungen. ⓘ

CPU-Modi

Mit Ausnahme des M-Profils sieht die 32-Bit-ARM-Architektur mehrere CPU-Modi vor, die von den implementierten Architekturmerkmalen abhängen. Zu jedem Zeitpunkt kann sich die CPU nur in einem Modus befinden, aber sie kann aufgrund externer Ereignisse (Interrupts) oder programmgesteuert den Modus wechseln. ⓘ

• Benutzermodus: Der einzige nichtprivilegierte Modus.
• FIQ-Modus: Ein privilegierter Modus, der immer dann aktiviert wird, wenn der Prozessor eine schnelle Interrupt-Anforderung akzeptiert.
• IRQ-Modus: Ein privilegierter Modus, der immer dann aktiviert wird, wenn der Prozessor einen Interrupt akzeptiert.
• Supervisor-Modus (svc): Ein privilegierter Modus, der immer dann aktiviert wird, wenn die CPU zurückgesetzt wird oder wenn eine SVC-Anweisung ausgeführt wird.
• Abbruchmodus: Ein privilegierter Modus, der immer dann aufgerufen wird, wenn eine Prefetch-Abbruch- oder Datenabbruch-Ausnahme auftritt.
• Undefinierter Modus: Ein privilegierter Modus, der immer dann aktiviert wird, wenn eine undefinierte Befehlsausnahme auftritt.
• Systemmodus (ARMv4 und höher): Der einzige privilegierte Modus, der nicht durch eine Ausnahme ausgelöst wird. Er kann nur durch die Ausführung eines Befehls erreicht werden, der explizit in die Modusbits des Current Program Status Register (CPSR) aus einem anderen privilegierten Modus (nicht aus dem Benutzermodus) schreibt.
• Monitor-Modus (ARMv6 und ARMv7 Security Extensions, ARMv8 EL3): Ein Monitor-Modus wird eingeführt, um die TrustZone-Erweiterung in ARM-Cores zu unterstützen.
• Hyp-Modus (ARMv7 Virtualisierungserweiterungen, ARMv8 EL2): Ein Hypervisor-Modus, der die Popek- und Goldberg-Virtualisierungsanforderungen für den unsicheren Betrieb der CPU unterstützt.
• Thread-Modus (ARMv6-M, ARMv7-M, ARMv8-M): Ein Modus, der entweder als privilegiert oder unprivilegiert angegeben werden kann. Ob der Hauptstapelzeiger (Main Stack Pointer, MSP) oder der Prozessstapelzeiger (Process Stack Pointer, PSP) verwendet wird, kann ebenfalls im CONTROL-Register mit privilegiertem Zugriff angegeben werden. Dieser Modus ist für Benutzeraufgaben in RTOS-Umgebungen gedacht, wird aber typischerweise in Bare-Metal für Super-Loops verwendet.
• Handler-Modus (ARMv6-M, ARMv7-M, ARMv8-M): Ein Modus für die Behandlung von Ausnahmen (mit Ausnahme von RESET, die im Thread-Modus behandelt werden). Der Handler-Modus verwendet immer MSP und arbeitet auf privilegierter Ebene. ⓘ

Befehlssatz

Die ursprüngliche (und spätere) ARM-Implementierung war fest verdrahtet, ohne Mikrocode, wie der viel einfachere 8-Bit-Prozessor 6502, der in früheren Acorn-Mikrocomputern verwendet wurde. ⓘ

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

• Laden/Speichern-Architektur.
• Keine Unterstützung für nicht ausgerichtete Speicherzugriffe in der ursprünglichen Version der Architektur. ARMv6 und spätere Versionen, mit Ausnahme einiger Mikrocontroller-Versionen, unterstützen ausrichtungsfreie Zugriffe für Halbwort- und Einzelwort-Lade-/Speicherbefehle mit einigen Einschränkungen, wie z. B. keine garantierte Atomizität.
• Einheitliche 16 × 32-Bit-Registerdatei (einschließlich Programmzähler, Stack-Pointer und Link-Register).
• Feste Befehlsbreite von 32 Bit zur Erleichterung der Dekodierung und des Pipelining, allerdings auf Kosten einer geringeren Codedichte. Später wurden mit dem Thumb-Befehlssatz 16-Bit-Befehle hinzugefügt und die Codedichte erhöht.
• Hauptsächlich Ausführung in einem Taktzyklus. ⓘ

Um das einfachere Design im Vergleich zu Prozessoren wie dem Intel 80286 und dem Motorola 68020 zu kompensieren, wurden einige zusätzliche Designmerkmale verwendet:

• Die bedingte Ausführung der meisten Befehle reduziert den Verzweigungsaufwand und kompensiert das Fehlen eines Verzweigungsprädiktors in den frühen Chips.
• Arithmetische Befehle ändern die Bedingungscodes nur, wenn dies gewünscht wird.
• 32-Bit Barrel Shifter kann ohne Leistungseinbußen bei den meisten arithmetischen Befehlen und Adressberechnungen verwendet werden.
• Verfügt über leistungsstarke indizierte Adressierungsmodi.
• Ein Link-Register unterstützt schnelle Leaf-Funktionsaufrufe.
• Ein einfaches, aber schnelles Interrupt-Subsystem mit 2 Prioritätsebenen hat geschaltete Registerbänke. ⓘ

Arithmetische Befehle

ARM umfasst ganzzahlige arithmetische Operationen für Addition, Subtraktion und Multiplikation; einige Versionen der Architektur unterstützen auch Divisionsoperationen. ⓘ

ARM unterstützt 32-Bit × 32-Bit-Multiplikationen mit einem 32-Bit-Ergebnis oder einem 64-Bit-Ergebnis, obwohl Cortex-M0 / M0+ / M1-Kerne keine 64-Bit-Ergebnisse unterstützen. Einige ARM-Kerne unterstützen auch 16-Bit × 16-Bit- und 32-Bit × 16-Bit-Multiplikationen. ⓘ

Die Divisionsbefehle sind nur in den folgenden ARM-Architekturen enthalten:

• ARMv7-M- und ARMv7E-M-Architekturen enthalten immer Divisionsbefehle.
• Die ARMv7-R-Architektur enthält immer Divisionsbefehle im Thumb-Befehlssatz, aber optional in ihrem 32-Bit-Befehlssatz.
• Die ARMv7-A-Architektur enthält optional die Divisionsbefehle. Die Befehle sind möglicherweise nicht implementiert oder nur im Thumb-Befehlssatz implementiert oder sowohl im Thumb- als auch im ARM-Befehlssatz implementiert oder implementiert, wenn die Virtualisierungserweiterungen enthalten sind. ⓘ

Register

Register in verschiedenen CPU-Modi

usr	sys	svc	abt	und	irq	fiq ⓘ
R0
R1
R2
R3
R4
R5
R6
R7
R8						R8_fiq
R9						R9_fiq
R10						R10_fiq
R11						R11_fiq
R12						R12_fiq
R13		R13_svc	R13_abt	R13_und	R13_irq	R13_fiq
R14		R14_svc	R14_abt	R14_und	R14_irq	R14_fiq
R15
CPSR
		SPSR_svc	SPSR_abt	SPSR_und	SPSR_irq	SPSR_fiq

Die Register R0 bis R7 sind in allen CPU-Betriebsarten gleich; sie werden nie in einer Bank gespeichert. ⓘ

Die Register R8 bis R12 sind in allen CPU-Modi mit Ausnahme des FIQ-Modus identisch. Der FIQ-Modus hat seine eigenen Register R8 bis R12. ⓘ

R13 und R14 sind in allen privilegierten CPU-Modi außer dem Systemmodus belegt. Das heißt, jeder Modus, der aufgrund einer Ausnahme aufgerufen werden kann, hat seine eigenen R13 und R14. Diese Register enthalten im Allgemeinen den Stack-Zeiger und die Rücksprungadresse von Funktionsaufrufen. ⓘ

Aliasnamen:

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

Das Current Program Status Register (CPSR) hat die folgenden 32 Bits. ⓘ

• M (Bits 0-4) sind die Prozessormodus-Bits.
• T (Bit 5) ist das Thumb-Status-Bit.
• F (Bit 6) ist das FIQ-Sperrbit.
• I (Bit 7) ist das IRQ-Sperrbit.
• A (Bit 8) ist das unpräzise Datenabbruch-Sperrbit.
• E (Bit 9) ist das Daten-Endianness-Bit.
• IT (Bits 10-15 und 25-26) sind die Wenn-Dann-Statusbits.
• GE (Bits 16-19) ist das Größer-als-oder-Gleich-Bit.
• DNM (Bits 20-23) sind die Nicht-Ändern-Bits.
• J (Bit 24) ist das Java-Status-Bit.
• Q (Bit 27) ist das Sticky-Overflow-Bit.
• V (Bit 28) ist das Überlaufbit.
• C (Bit 29) ist das Carry/Borrow/Extend-Bit.
• Z (Bit 30) ist das Null-Bit.
• N (Bit 31) ist das negative/weniger als Bit. ⓘ

Bedingte Ausführung

Der ARM-Befehlssatz enthält einige Besonderheiten, die zur Effizienz der Architektur beitragen:

• Praktisch alle Befehle können bedingt ausgeführt werden ("conditional execution"). Damit entfällt in vielen Standardsituationen die Notwendigkeit für Programmsprünge, z. B. in vielen If/Else-Abfragen (man vermeidet Programmsprünge, weil diese die Pipeline des Prozessors leeren, und dadurch Wartezyklen entstehen). Zum Kodieren der Bedingung werden die ersten 4 Bits eines jeden Befehles im Maschinencode bzw. ein Suffix im Mnemonic verwendet. ⓘ

Beispiel

CMP    r0, r1            ;(setzt Bedingungsbits)            ; "CMP" bedeutet:   "CoMPare"
ADDGE  r2, r2, r3        ;if r0 >= r1 then r2 := r2 + r3    ; "ADDGE" bedeutet: "ADD if Greater or Equal"
ADDLT  r2, r2, r4        ;            else r2 := r2 + r4    ; "ADDLT" bedeutet: "ADD if Less Than"

• Der Bedingungs-Code 1111 stand zu Beginn für die Condition NV (never), diese Befehle werden also nie ausgeführt. Diese Opcodes werden in neueren CPUs für spezielle Befehle wie PLD und BLX verwendet (die dann nicht mehr bedingt ausgeführt werden können), von der Benutzung beliebiger Opcodes mit Kondition NV für NOPs wird daher abgeraten ("deprecated").
• Wahlweise können die Statusbits als Folge des Befehls aktualisiert werden. Dies wird durch das Suffix S im Assemblercode gekennzeichnet und kann mit der bedingten Ausführung kombiniert werden. ⓘ

Beispiel

CMP    r0, r1            ;(setzt Bedingungsbits)
ADDGES r2, r4, r5        ;if r0 >= r1 then r2 := r4 + r5
BCS    overflow          ;verzweige bei Überlauf der Addition

• Die ARM verfügt über einen Barrel-Shifter im B-Pfad der ALU; sämtliche Befehle, die mit dem zweiten Operanden arbeiten, erlauben die Angabe eines 4-bit breiten Shift- oder Roll-Faktors.

Beispiel

ADD  r2, r3, r3, lsl #2  ;r2 := r3 + (r3 << 2)
                         ;   := r3 + 4*r3
                         ;   := 5*r3

• Neuere ARM-CPUs kennen SIMD-Befehle. ⓘ

Fast jeder ARM-Befehl verfügt über eine bedingte Ausführungsfunktion, die so genannte 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 haben nur Bedingungscodes für Verzweigungsbefehle. ⓘ

Obwohl das Prädikat vier der 32 Bits in einem Befehlscode beansprucht und somit die für Verschiebungen in Speicherzugriffsanweisungen verfügbaren Kodierungsbits erheblich reduziert, werden dadurch Verzweigungsanweisungen bei der Codegenerierung für kleine if-Anweisungen vermieden. Abgesehen davon, dass die Verzweigungsanweisungen selbst entfallen, bleibt dadurch die Fetch/Decode/Execute-Pipeline auf Kosten von nur einem Zyklus pro übersprungener Anweisung erhalten. ⓘ

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

Derselbe Algorithmus kann in einer Weise umgeschrieben werden, die den Ziel-ARM-Befehlen näher kommt, als:

und in Assembler kodiert werden als:

wodurch die Verzweigungen um die then- und else-Klauseln vermieden werden. Wenn r0 und r1 gleich sind, wird keiner der SUB-Befehle ausgeführt, wodurch die Notwendigkeit einer bedingten Verzweigung zur Implementierung der while-Prüfung am Anfang der Schleife entfällt, wenn beispielsweise SUBLE (less than or equal) verwendet worden wäre. ⓘ

Eine der Möglichkeiten, mit denen Thumb-Code eine dichtere Kodierung bietet, besteht darin, den Vier-Bit-Selektor aus Nicht-Verzweigungsanweisungen zu entfernen. ⓘ

Andere Merkmale

Ein weiteres Merkmal des Befehlssatzes ist die Möglichkeit, Verschiebungen und Drehungen in die Datenverarbeitungsbefehle (arithmetische, logische und Register-Register-Bewegung) einzubinden, so dass beispielsweise die Anweisung in der Sprache C:

als Ein-Wort-, Ein-Zyklus-Befehl wiedergegeben werden kann:

Dies führt dazu, dass ein typisches ARM-Programm dichter ist als erwartet und weniger Speicherzugriffe hat; die Pipeline wird also effizienter genutzt. ⓘ

Der ARM-Prozessor verfügt auch über Merkmale, die bei anderen RISC-Architekturen selten zu finden sind, wie die PC-relative Adressierung (beim 32-Bit-ARM ist der PC eines der 16 Register) und die Pre- und Post-Increment-Adressierungsmodi. ⓘ

Der ARM-Befehlssatz hat sich im Laufe der Zeit erweitert. Einige frühe ARM-Prozessoren (vor ARM7TDMI) haben beispielsweise keinen Befehl zum Speichern einer Zwei-Byte-Menge. ⓘ

Die ARM-CPU ist eine RISC-Architektur und kennt als solche drei Kategorien von Befehlen:

• Befehle zum Zugriff auf den Speicher (Load/Store),
• arithmetische oder logische Befehle für Werte in Registern,
• Befehle zum Ändern des Programmflusses (Sprünge, Unterprogrammaufrufe). ⓘ

Beispiel

ADD  r0, r1, r2   ;r0 := r1 + r2

Die ARM ist sowohl Little-Endian- als auch Big-Endian-kompatibel, kann also mit beiden Byte-Reihenfolgen umgehen, was angesichts des Einsatzzwecks als Standard-CPU in Kommunikationsgeräten ein deutlicher Vorteil ist. Der Standardmodus der ARM ist Little-Endian. ⓘ

Daten und Code (BE32)

• ARMv4
• ARMv5
• ARMv6 ⓘ

Nur Daten (BE8)

• ARMv6
• ARMv7
• ARMv8 ⓘ

Pipelines und andere Implementierungsprobleme

Der ARM7 und frühere Implementierungen haben eine dreistufige Pipeline; die Stufen sind Abruf, Dekodierung und Ausführung. Leistungsstärkere Designs, wie der ARM9, haben tiefere Pipelines: Der Cortex-A8 hat dreizehn Stufen. Zu den zusätzlichen Implementierungsänderungen für mehr Leistung gehören ein schnellerer Addierer und eine umfangreichere Verzweigungsvorhersagelogik. Der Unterschied zwischen den ARM7DI- und ARM7DMI-Kernen bestand beispielsweise in einem verbesserten Multiplizierer; daher das zusätzliche "M". ⓘ

Koprozessoren

Die ARM-Architektur (vor ARMv8) bietet eine nicht-intrusive Möglichkeit zur Erweiterung des Befehlssatzes durch "Koprozessoren", die mit MCR-, MRC-, MRRC-, MCRR- und ähnlichen Befehlen angesprochen werden können. Der Koprozessorraum ist logisch in 16 Koprozessoren mit Nummern von 0 bis 15 unterteilt, wobei der Koprozessor 15 (cp15) für einige typische Kontrollfunktionen wie die Verwaltung der Caches und den Betrieb der MMU bei Prozessoren mit einer solchen reserviert ist. ⓘ

In ARM-basierten Maschinen werden Peripheriegeräte in der Regel an den Prozessor angeschlossen, indem ihre physischen Register in den ARM-Speicherbereich oder in den Koprozessorbereich abgebildet werden, oder indem sie an ein anderes Gerät (einen Bus) angeschlossen werden, das wiederum an den Prozessor angeschlossen ist. Coprozessor-Zugriffe haben eine geringere Latenzzeit, so dass einige Peripheriegeräte, z. B. ein XScale-Interrupt-Controller, auf beiden Wegen zugänglich sind: über den Speicher und über Coprozessoren. ⓘ

In anderen Fällen integrieren die Chipdesigner die Hardware nur über den Coprozessor-Mechanismus. Eine Bildverarbeitungs-Engine könnte beispielsweise aus einem kleinen ARM7TDMI-Kern bestehen, der mit einem Coprozessor kombiniert ist, der spezielle Operationen zur Unterstützung einer bestimmten Gruppe von HDTV-Transkodierungsprimitiven bietet. ⓘ

Die ARM ist als Mikroprozessor-Kern in eingebetteten Systemen gedacht, in denen meist keine Gleitkomma-Arithmetik benötigt wird. Der ARM wurde jedoch speziell im Hinblick auf Erweiterbarkeit um Coprozessoren entwickelt und besitzt ein eigenes Coprozessor-Interface und Befehle für optionale Coprozessoren. ⓘ

Fehlersuche

Alle modernen ARM-Prozessoren verfügen über Hardware-Debugging-Funktionen, die es Software-Debuggern ermöglichen, Operationen wie Anhalten, Stepping und Breakpointing von Code ab Reset durchzuführen. Diese Einrichtungen sind mit JTAG-Unterstützung aufgebaut, obwohl einige neuere Cores optional ARMs eigenes Zweidraht-"SWD"-Protokoll unterstützen. Bei ARM7TDMI-Cores steht das "D" für JTAG-Debug-Unterstützung und das "I" für das Vorhandensein eines "EmbeddedICE"-Debug-Moduls. Für die ARM7- und ARM9-Core-Generationen war EmbeddedICE über JTAG ein De-facto-Debug-Standard, wenn auch nicht architektonisch garantiert. ⓘ

Die ARMv7-Architektur definiert grundlegende Debugging-Funktionen auf Architekturebene. Dazu gehören Breakpoints, Watchpoints und die Ausführung von Befehlen in einem "Debug-Modus"; ähnliche Möglichkeiten waren auch mit EmbeddedICE verfügbar. Sowohl "Halt Mode" als auch "Monitor Mode" Debugging werden unterstützt. Der tatsächliche Transportmechanismus, der für den Zugriff auf die Debug-Funktionen verwendet wird, ist architektonisch nicht spezifiziert, aber die Implementierungen beinhalten im Allgemeinen JTAG-Unterstützung. ⓘ

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

Debug-Access-Port

Der Debug Access Port (DAP) ist eine Implementierung einer ARM-Debug-Schnittstelle. Es gibt zwei verschiedene unterstützte Implementierungen, den Serial Wire JTAG Debug Port (SWJ-DP) und den Serial Wire Debug Port (SW-DP). CMSIS-DAP ist eine Standardschnittstelle, die beschreibt, wie verschiedene Debugging-Software auf einem Host-PC über USB mit der auf einem Hardware-Debugger laufenden Firmware kommunizieren kann, die wiederum über SWD oder JTAG mit einer CoreSight-fähigen ARM Cortex CPU kommuniziert. ⓘ

Anweisungen zur DSP-Erweiterung

Um die ARM-Architektur für digitale Signalverarbeitung und Multimedia-Anwendungen zu verbessern, wurden DSP-Befehle in den Befehlssatz aufgenommen. Diese sind durch ein "E" im Namen der ARMv5TE und ARMv5TEJ Architekturen gekennzeichnet. E-Varianten bedeuten auch T, D, M und I. ⓘ

Die neuen Befehle sind in Architekturen für digitale Signalprozessoren (DSP) üblich. Sie umfassen Variationen der vorzeichenbehafteten Multiplikation/Akkumulation, der gesättigten Addition und Subtraktion sowie der Zählung führender Nullen. ⓘ

SIMD-Erweiterungen für Multimedia

Diese Befehle wurden in der ARMv6-Architektur eingeführt und waren ein Vorläufer von Advanced SIMD, auch Neon genannt. ⓘ

Jazelle

Jazelle DBX (Direct Bytecode eXecution) ist eine Technik, mit der Java-Bytecode direkt in der ARM-Architektur als dritter Ausführungszustand (und Befehlssatz) neben dem bestehenden ARM- und Thumb-Modus ausgeführt werden kann. Die Unterstützung für diesen Zustand wird durch das "J" in der ARMv5TEJ-Architektur und in den ARM9EJ-S- und ARM7EJ-S-Kernnamen gekennzeichnet. Die Unterstützung dieses Zustands ist ab ARMv6 erforderlich (mit Ausnahme des ARMv7-M-Profils), obwohl neuere Kerne nur eine triviale Implementierung enthalten, die keine Hardwarebeschleunigung bietet. ⓘ

Thumb

Um die Dichte des kompilierten Codes zu verbessern, verfügen Prozessoren seit dem ARM7TDMI (erschienen 1994) über den Thumb-Befehlssatz, der einen eigenen Status hat. (Das "T" in "TDMI" steht für die Thumb-Funktion.) In diesem Zustand führt der Prozessor den Thumb-Befehlssatz aus, eine kompakte 16-Bit-Kodierung für eine Teilmenge des ARM-Befehlssatzes. Die meisten der Thumb-Befehle werden direkt auf normale ARM-Befehle abgebildet. Die Platzersparnis ergibt sich daraus, dass einige der Befehlsoperanden implizit sind und die Anzahl der Möglichkeiten im Vergleich zu den ARM-Befehlen, die im ARM-Befehlssatzzustand ausgeführt werden, begrenzt ist. ⓘ

In Thumb haben die 16-Bit-Opcodes weniger Funktionalität. So können z. B. nur Verzweigungen bedingt sein, und viele Opcodes sind auf den Zugriff auf nur die Hälfte aller Allzweckregister der CPU beschränkt. Durch die kürzeren Opcodes wird die Codedichte insgesamt verbessert, auch wenn für einige Operationen zusätzliche Anweisungen erforderlich sind. In Situationen, in denen die Breite des Speicherports oder -busses auf weniger als 32 Bit beschränkt ist, ermöglichen die kürzeren Thumb-Opcodes eine Leistungssteigerung im Vergleich zu 32-Bit-ARM-Code, da bei der begrenzten Speicherbandbreite weniger Programmcode in den Prozessor geladen werden muss. ⓘ

Im Gegensatz zu Prozessorarchitekturen mit Befehlen variabler Länge (16- oder 32-Bit), wie dem Cray-1 und dem Hitachi SuperH, existieren die ARM- und Thumb-Befehlssätze unabhängig voneinander. Eingebettete Hardware, wie z. B. der Game Boy Advance, verfügt in der Regel über eine kleine Menge RAM, auf die über einen vollständigen 32-Bit-Datenpfad zugegriffen werden kann; auf den Großteil wird über einen 16-Bit- oder schmaleren sekundären Datenpfad zugegriffen. In dieser Situation ist es in der Regel sinnvoll, Thumb-Code zu kompilieren und einige der rechenintensivsten Abschnitte mit vollen 32-Bit-ARM-Befehlen von Hand zu optimieren und diese breiteren Befehle in den über den 32-Bit-Bus zugänglichen Speicher zu legen. ⓘ

Der erste Prozessor mit einem Thumb-Befehlsdecoder war der ARM7TDMI. Alle ARM9- und späteren Familien, einschließlich XScale, verfügen über einen Thumb-Befehlsdecoder. Er enthält Anweisungen, die vom Hitachi SuperH (1992) übernommen wurden, der von ARM lizenziert wurde. Die kleinsten Prozessorfamilien von ARM (Cortex M0 und M1) implementieren nur den 16-Bit-Thumb-Befehlssatz, um maximale Leistung bei kostengünstigen Anwendungen zu erzielen. ⓘ

Thumb-2

Die Thumb-2-Technologie wurde mit dem ARM1156-Kern eingeführt, der 2003 angekündigt wurde. Thumb-2 erweitert den begrenzten 16-Bit-Befehlssatz von Thumb um zusätzliche 32-Bit-Befehle, um den Befehlssatz breiter zu gestalten und so einen Befehlssatz mit variabler Länge zu schaffen. Ein erklärtes Ziel von Thumb-2 war es, eine ähnliche Codedichte wie Thumb mit einer ähnlichen Leistung 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 erhalten. Eine neue "Unified Assembly Language" (UAL) unterstützt die Erzeugung von Thumb- und ARM-Befehlen aus demselben Quellcode; Thumb-Versionen auf ARMv7-Prozessoren sind im Wesentlichen genauso leistungsfähig wie ARM-Code (einschließlich der Möglichkeit, Interrupt-Handler zu schreiben). Dies erfordert ein wenig Sorgfalt und die Verwendung eines neuen "IT"-Befehls (if-then), der die Ausführung von bis zu vier aufeinanderfolgenden Befehlen auf der Grundlage einer getesteten Bedingung oder deren Umkehrung ermöglicht. Bei der Kompilierung in ARM-Code wird diese Anweisung ignoriert, aber bei der Kompilierung in Thumb-Code wird eine tatsächliche Anweisung erzeugt. Ein Beispiel:

Alle ARMv7-Chips unterstützen den Thumb-Befehlssatz. Alle Chips der Cortex-A-Serie, Cortex-R-Serie und ARM11-Serie unterstützen sowohl den "ARM-Befehlssatzstatus" als auch den "Thumb-Befehlssatzstatus", während die Chips der Cortex-M-Serie nur den Thumb-Befehlssatz unterstützen. ⓘ

Thumb-Ausführungsumgebung (ThumbEE)

ThumbEE (in einigen ARM-Dokumentationen fälschlicherweise als Thumb-2EE bezeichnet), das als Jazelle RCT (Runtime Compilation Target) vermarktet wurde, wurde 2005 angekündigt und 2011 außer Kraft gesetzt. Es erschien erstmals im Cortex-A8-Prozessor. ThumbEE ist ein vierter Befehlssatzstatus, der kleine Ä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 erzeugt wird. ThumbEE ist ein Ziel für Sprachen wie Java, C#, Perl und Python und ermöglicht es JIT-Compilern, kleineren kompilierten Code ohne Leistungseinbußen auszugeben. ⓘ

Zu den neuen Funktionen von ThumbEE gehören die automatische Überprüfung von Nullzeigern bei jedem Lade- und Speicherbefehl, ein Befehl zur Überprüfung von Array-Grenzen und spezielle Befehle, die einen Handler aufrufen. Da ThumbEE die Thumb-2-Technologie nutzt, bietet es außerdem Zugriff auf die Register r8-r15 (in denen der Jazelle/DBX-Java-VM-Status gespeichert wird). Handler sind kleine Abschnitte häufig aufgerufenen Codes, die üblicherweise zur Implementierung von Hochsprachen verwendet werden, z. B. zur Zuweisung von Speicher für ein neues Objekt. Diese Änderungen ergeben sich aus der Wiederverwendung einer Handvoll von Opcodes und dem Wissen, dass sich der Kern im neuen ThumbEE-Zustand befindet. ⓘ

Am 23. November 2011 hat Arm Holdings jegliche Verwendung des ThumbEE-Befehlssatzes abgelehnt, und ARMv8 entfernt die Unterstützung für ThumbEE. ⓘ

Fließkommazahlen (VFP)

Die VFP-Technologie (Vector Floating Point) ist eine Erweiterung der ARM-Architektur um eine Fließkommaeinheit (FPU) als Coprozessor (in ARMv8 anders implementiert - Coprozessoren sind dort nicht definiert). Sie bietet kostengünstige Gleitkommaberechnungen mit einfacher und doppelter Genauigkeit, die vollständig mit dem ANSI/IEEE Std 754-1985 Standard for Binary Floating-Point Arithmetic konform sind. VFP bietet Gleitkommaberechnungen für ein breites Spektrum von Anwendungen wie PDAs, Smartphones, Sprachkomprimierung und -dekomprimierung, dreidimensionale Grafiken und digitales Audio, Drucker, Set-Top-Boxen und Automobilanwendungen. Die VFP-Architektur sollte die Ausführung kurzer "Vektormodus"-Befehle unterstützen, die jedoch jedes Vektorelement sequentiell bearbeiteten und somit nicht die Leistung echter SIMD-Vektorparallelität (Single Instruction, Multiple Data) boten. Dieser Vektormodus wurde daher kurz nach seiner Einführung entfernt und durch das wesentlich leistungsfähigere Advanced SIMD, auch Neon genannt, ersetzt. ⓘ

Einige Geräte wie der ARM Cortex-A8 haben ein reduziertes VFPLite-Modul anstelle eines vollständigen VFP-Moduls und benötigen etwa zehnmal mehr Taktzyklen pro Float-Operation. Die Vor-ARMv8-Architektur implementierte Fließkomma/SIMD mit der Coprozessor-Schnittstelle. Andere Fließkomma- und/oder SIMD-Einheiten in ARM-basierten Prozessoren, die die Coprozessor-Schnittstelle nutzen, sind FPA, FPE, iwMMXt, von denen einige durch Trapping in Software implementiert wurden, aber auch in Hardware hätten implementiert werden können. Sie bieten einige der gleichen Funktionen wie VFP, sind aber nicht opcode-kompatibel mit ihm. FPA10 bietet ebenfalls eine erweiterte Genauigkeit, implementiert aber die korrekte Rundung (die nach IEEE 754 erforderlich ist) nur in einfacher Genauigkeit. ⓘ

VFPv1

Veraltet

VFPv2

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

VFPv3 oder VFPv3-D32

Implementiert auf den meisten Cortex-A8 und A9 ARMv7 Prozessoren. Es ist abwärtskompatibel mit VFPv2, außer dass es keine Fließkomma-Ausnahmen abfangen kann. VFPv3 hat standardmäßig 32 64-Bit-FPU-Register, fügt VCVT-Befehle hinzu, um zwischen Skalar, Float und Double zu konvertieren, und fügt den Immediate Mode zu VMOV hinzu, so dass Konstanten in FPU-Register geladen werden können.

VFPv3-D16

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

VFPv3-F16

Unüblich; unterstützt IEEE754-2008 halbpräzise (16-Bit) Gleitkommazahlen als Speicherformat.

VFPv4 oder VFPv4-D32

Implementiert auf Cortex-A12 und A15 ARMv7 Prozessoren, Cortex-A7 hat optional VFPv4-D32 im Falle einer FPU mit Neon. VFPv4 verfügt standardmäßig über 32 64-Bit-FPU-Register und fügt den Funktionen von VFPv3 sowohl die Unterstützung von Halbpräzision als Speicherformat als auch fusionierte Multiplikations- und Akkumulationsbefehle hinzu.

VFPv4-D16

Wie oben, aber mit nur 16 64-Bit-FPU-Registern. Implementiert auf Cortex-A5 und A7 Prozessoren im Falle einer FPU ohne Neon.

VFPv5-D16-M

Implementiert auf Cortex-M7, wenn die Option für einen einfach- und doppeltpräzisen Gleitkommakern besteht. ⓘ

In Debian Linux und Derivaten wie Ubuntu und Linux Mint bezieht sich armhf (ARM hard float) auf die ARMv7-Architektur, einschließlich der zusätzlichen VFP3-D16-Gleitkomma-Hardware-Erweiterung (und Thumb-2) oben. Softwarepakete und Cross-Compiler-Tools verwenden zur Unterscheidung die Suffixe armhf vs. arm/armel. ⓘ

Erweiterte SIMD (Neon)

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-Bausteinen enthalten, in Cortex-A9-Bausteinen ist es jedoch optional. Neon kann MP3-Audiodekodierung auf CPUs ausführen, die mit 10 MHz laufen, und den GSM Adaptive Multi-Rate (AMR) Sprachcodec mit 13 MHz betreiben. Er verfügt über einen umfassenden Befehlssatz, separate Registerdateien und unabhängige Ausführungshardware. Neon unterstützt 8-, 16-, 32- und 64-Bit-Ganzzahl- und 32-Bit-Gleitkommadaten sowie SIMD-Operationen für die Verarbeitung von Audio- und Videodaten sowie von Grafik- und Spieldaten. In Neon unterstützt SIMD bis zu 16 Operationen gleichzeitig. Die Neon-Hardware verwendet dieselben Gleitkommaregister wie VFP. Bausteine wie der ARM Cortex-A8 und Cortex-A9 unterstützen 128-Bit-Vektoren, führen aber jeweils 64 Bits aus, während neuere Cortex-A15-Bausteine 128 Bits gleichzeitig ausführen können. ⓘ

Eine Besonderheit von Neon in ARMv7-Bausteinen ist, dass es alle subnormalen Zahlen auf Null setzt, weshalb der GCC-Compiler es nicht verwenden kann, es sei denn, -funsafe-math-optimizations, das den Verlust von Denormalen erlaubt, ist aktiviert. "Enhanced" Neon, das seit ARMv8 definiert ist, hat diese Eigenart nicht, aber seit GCC 8.2 ist das gleiche Flag immer noch erforderlich, um Neon-Befehle zu aktivieren. Andererseits hält der GCC Neon auf AArch64 für ARMv8 für sicher. ⓘ

ProjectNe10 ist das erste Open-Source-Projekt von ARM (von Anfang an; während sie ein älteres Projekt, das jetzt Mbed TLS heißt, übernommen haben). Die Ne10-Bibliothek besteht aus einer Reihe allgemeiner, nützlicher Funktionen, die sowohl in Neon als auch in C (aus Kompatibilitätsgründen) geschrieben sind. Die Bibliothek wurde erstellt, um Entwicklern die Möglichkeit zu geben, Neon-Optimierungen zu nutzen, ohne Neon lernen zu müssen, aber sie dient auch als eine Reihe von hochoptimierten Neon-Intrinsic- und Assembler-Code-Beispielen für gängige DSP-, Arithmetik- und Bildverarbeitungsroutinen. Der Quellcode ist auf GitHub verfügbar. ⓘ

ARM Helium-Technologie

Helium ist die M-Profile Vector Extension (MVE). Sie fügt mehr als 150 skalare und vektorielle Anweisungen hinzu. ⓘ

Sicherheitserweiterungen

TrustZone (für Cortex-A-Profil)

Die Sicherheitserweiterungen, die als TrustZone-Technologie vermarktet werden, sind in ARMv6KZ und späteren Anwendungsprofilarchitekturen enthalten. Sie bietet eine kostengünstige Alternative zum Hinzufügen eines weiteren dedizierten Sicherheitskerns zu einem SoC, indem sie zwei virtuelle Prozessoren bereitstellt, die durch eine hardwarebasierte Zugriffskontrolle unterstützt werden. Dadurch kann der Anwendungskern zwischen zwei Zuständen umschalten, die als Welten bezeichnet werden (um Verwechslungen mit anderen Bezeichnungen für Fähigkeitsdomänen zu vermeiden), um zu verhindern, dass Informationen von der vertrauenswürdigeren Welt in die weniger vertrauenswürdige Welt durchsickern. Dieser Weltenwechsel ist im Allgemeinen orthogonal zu allen anderen Fähigkeiten des Prozessors, so dass jede Welt unabhängig von der anderen arbeiten kann, während sie denselben Kern verwendet. Der Speicher und die Peripheriegeräte erhalten dann Kenntnis von der Betriebswelt des Kerns und können dies nutzen, um den Zugriff auf Geheimnisse und Code auf dem Gerät zu kontrollieren. ⓘ

In der Regel wird in der weniger vertrauenswürdigen Welt ein umfangreiches Betriebssystem ausgeführt, während in der vertrauenswürdigeren Welt ein kleinerer sicherheitsspezifischer Code ausgeführt wird, um die Angriffsfläche zu verringern. Typische Anwendungen sind DRM-Funktionen zur Kontrolle der Nutzung von Medien auf ARM-basierten Geräten und zur Verhinderung einer nicht genehmigten Nutzung des Geräts. ⓘ

Da die spezifischen Implementierungsdetails proprietärer TrustZone-Implementierungen in der Praxis nicht zur Überprüfung offengelegt wurden, ist unklar, welcher Grad an Sicherheit für ein bestimmtes Bedrohungsmodell geboten wird, aber sie sind nicht immun gegen Angriffe. ⓘ

Open Virtualization ist eine Open-Source-Implementierung der Trusted-World-Architektur für TrustZone. ⓘ

AMD hat die TrustZone-Technologie lizenziert und in seine sichere Prozessortechnologie integriert. Die APUs von AMD, die in einigen, aber nicht allen Produkten aktiviert sind, enthalten einen Cortex-A5-Prozessor für die sichere Verarbeitung. Tatsächlich war der Cortex-A5 TrustZone-Kern bereits in früheren AMD-Produkten enthalten, wurde aber aus Zeitgründen nicht aktiviert. ⓘ

Samsung Knox verwendet TrustZone für Zwecke wie die Erkennung von Änderungen am Kernel, die Speicherung von Zertifikaten und die Beglaubigung von Schlüsseln. ⓘ

TrustZone für ARMv8-M (für das Cortex-M-Profil)

Die Sicherheitserweiterung, die als TrustZone für ARMv8-M-Technologie vermarktet wird, wurde mit der ARMv8-M-Architektur eingeführt. Sie enthält zwar ähnliche Konzepte wie TrustZone für ARMv8-A, hat aber ein anderes architektonisches Design, da die Weltumschaltung mithilfe von Verzweigungsanweisungen und nicht mithilfe von Ausnahmen erfolgt. Sie unterstützt außerdem eine sichere, verschachtelte Interrupt-Behandlung aus beiden Welten, unabhängig vom aktuellen Sicherheitsstatus. Zusammen sorgen diese Funktionen für geringe Latenzzeiten bei Aufrufen der sicheren Welt und eine reaktionsschnelle Interrupt-Behandlung. ARM bietet einen Referenzstapel mit sicherem Weltcode in Form von Trusted Firmware for M und PSA Certified. ⓘ

No-Execute-Page-Schutz

Ab ARMv6 unterstützt die ARM-Architektur den No-Execute-Page-Schutz, der als XN bezeichnet wird, für eXecute Never. ⓘ

Große physikalische Adresserweiterung (LPAE)

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 aufgenommen. Im Cortex-A75 und Cortex-A65AE ist die physikalische Adressgröße mit 44 Bit größer. ⓘ

ARMv8-R und ARMv8-M

Die Architekturen ARMv8-R und ARMv8-M, die nach der Architektur ARMv8-A angekündigt wurden, haben einige Merkmale mit ARMv8-A gemeinsam. ARMv8-M enthält jedoch keine 64-Bit AArch64-Befehle, und ARMv8-R enthielt ursprünglich keine AArch64-Befehle; diese Befehle wurden später zu ARMv8-R hinzugefügt. ⓘ

ARMv8.1-M

Die ARMv8.1-M-Architektur, die im Februar 2019 angekündigt wurde, ist eine Weiterentwicklung der ARMv8-M-Architektur. Sie bringt neue Funktionen, darunter:

• Eine neue Vektor-Befehlssatzerweiterung. Die M-Profile Vector Extension (MVE), oder Helium, ist für Signalverarbeitungs- und Machine-Learning-Anwendungen gedacht.
• Zusätzliche Erweiterungen des Befehlssatzes für Schleifen und Verzweigungen (Low Overhead Branch Extension).
• Befehle für die Unterstützung von halbpräzisen Gleitkommazahlen.
• Befehlssatzerweiterung für die TrustZone-Verwaltung für die Fließkommaeinheit (FPU).
• Neues Speicherattribut in der Memory Protection Unit (MPU).
• Verbesserungen im Bereich Debugging, einschließlich Performance Monitoring Unit (PMU), Unprivileged Debug Extension und zusätzlicher Debugging-Unterstützung mit Schwerpunkt auf der Entwicklung von Signalverarbeitungsanwendungen.
• Erweiterung der Zuverlässigkeit, Verfügbarkeit und Wartbarkeit (RAS). ⓘ

64/32-Bit-Architektur

ARMv8-A-Plattform mit Cortex A57/A53 MPCore big.LITTLE CPU-Chip ⓘ

ARMv8

ARMv8-A

Die im Oktober 2011 angekündigte ARMv8-A-Plattform (oft als ARMv8 bezeichnet, aber auch als ARMv8-R erhältlich) stellt eine grundlegende Änderung der ARM-Architektur dar. Sie fügt eine optionale 64-Bit-Architektur hinzu (z. B. ist der Cortex-A32 eine 32-Bit-ARMv8-A-CPU, während die meisten ARMv8-A-CPUs 64-Bit unterstützen), die "AArch64" genannt wird, und den damit verbundenen neuen "A64"-Befehlssatz. AArch64 bietet Benutzerraumkompatibilität mit ARMv7-A, der 32-Bit-Architektur, die dort als "AArch32" bezeichnet wird, und dem alten 32-Bit-Befehlssatz, der jetzt "A32" heißt. Der Thumb-Befehlssatz wird als "T32" bezeichnet und hat kein 64-Bit-Gegenstück. ARMv8-A ermöglicht die Ausführung von 32-Bit-Anwendungen in einem 64-Bit-Betriebssystem und die Kontrolle eines 32-Bit-Betriebssystems durch einen 64-Bit-Hypervisor. ARM kündigte seine Cortex-A53 und Cortex-A57 Kerne am 30. Oktober 2012 an. Apple war das erste Unternehmen, das einen ARMv8-A-kompatiblen Kern in einem Verbraucherprodukt veröffentlichte (Apple A7 im iPhone 5S). AppliedMicro war das erste Unternehmen, das ARMv8-A mit Hilfe eines FPGA demonstrierte. Der erste ARMv8-A-SoC von Samsung ist der Exynos 5433, der im Galaxy Note 4 verwendet wird. Er verfügt über zwei Cluster aus vier Cortex-A57- und Cortex-A53-Kernen in einer big.LITTLE-Konfiguration, läuft jedoch nur im AArch32-Modus. ⓘ

Sowohl für AArch32 als auch für AArch64 macht ARMv8-A VFPv3/v4 und erweiterte SIMD (Neon) zum Standard. Außerdem werden Kryptographiebefehle hinzugefügt, die AES, SHA-1/SHA-256 und Finite-Field-Arithmetik unterstützen. AArch64 wurde mit ARMv8-A und seiner nachfolgenden Revision eingeführt. AArch64 ist in den 32-Bit-Architekturen ARMv8-R und ARMv8-M nicht enthalten. ⓘ

ARMv8-R

Die optionale AArch64-Unterstützung wurde dem ARMv8-R-Profil hinzugefügt, wobei der Cortex-R82 der erste ARM-Core ist, der sie implementiert. Er fügt den A64-Befehlssatz hinzu. ⓘ

ARMv9

ARMv9-A

Die im März 2021 angekündigte, aktualisierte Architektur legt den Schwerpunkt auf sichere Ausführung und Kompartimentierung. ⓘ

Arm SystemReady

Arm SystemReady, früher Arm ServerReady genannt, ist ein Zertifizierungsprogramm, das dabei hilft, generische Standard-Betriebssysteme und Hypervisoren auf Arm-basierten Systemen zu installieren, von Servern in Rechenzentren bis hin zu industriellen Edge- und IoT-Geräten. Die wichtigsten Bausteine des Programms sind die Spezifikationen für die Mindestanforderungen an Hardware und Firmware, auf die sich die Betriebssysteme und Hypervisoren stützen können. Diese Spezifikationen sind:

• Base System Architecture (BSA) und die marktsegmentspezifischen Ergänzungen (z. B. Server BSA supplement)
• Base Boot Requirements (BBR) und Base Boot Security Requirements (BBR) ⓘ

Diese Spezifikationen werden von Arm Holdings und seinen Partnern im System Architecture Advisory Committee (SystemArchAC) mitentwickelt. ⓘ

Die Architecture Compliance Suite (ACS) ist das Testwerkzeug, mit dem die Einhaltung dieser Spezifikationen überprüft werden kann. Die Arm SystemReady Requirements Specification dokumentiert die Anforderungen der Zertifizierungen. ⓘ

Dieses Programm wurde von Arm Holdings im Jahr 2020 auf dem ersten DevSummit Event vorgestellt. Sein Vorgänger Arm ServerReady wurde 2018 auf der Arm TechCon Veranstaltung vorgestellt. Dieses Programm umfasst derzeit vier Bänder:

• SystemReady SR: Dieses Band ist für Server, die Betriebssysteme und Hypervisoren unterstützen, die UEFI, ACPI und SMBIOS-Schnittstellen erwarten. Windows Server, Red Hat Enterprise Linux und VMware ESXi-Arm erfordern diese Schnittstellen, während andere Linux- und BSD-Distributionen ebenfalls unterstützt werden können.
• SystemReady LS: Dieses Band ist für Server, die von Hyperscalern zur Unterstützung von Linux-Betriebssystemen verwendet werden, die LinuxBoot-Firmware zusammen mit den ACPI- und SMBIOS-Schnittstellen erwarten.
• SystemReady ES: Dieser Bereich ist für industrielle Edge- und IoT-Geräte gedacht, die Betriebssysteme und Hypervisoren unterstützen, die UEFI-, ACPI- und SMBIOS-Schnittstellen erwarten. Windows IoT Enterprise, Red Hat Enterprise Linux und VMware ESXi-Arm erfordern diese Schnittstellen, während andere Linux- und BSD-Distributionen ebenfalls unterstützt werden können.
• SystemReady IR: Dieser Bereich ist für industrielle Edge- und IoT-Geräte gedacht, die Betriebssysteme unterstützen, die UEFI- und Devicetree-Schnittstellen erwarten. Embedded Linux (z. B. Yocto) und einige Linux/BSD-Distros (z. B. Fedora, Ubuntu, Debian und OpenSUSE) können ebenfalls unterstützt werden. ⓘ

Mit der Fertigstellung der 64-Bit-Mikroarchitektur Armv8 im Jahre 2012 waren die Voraussetzungen für einen Einsatz von ARM-Prozessoren in Serversystemen gegeben. ARM stand hier vor der Aufgabenstellung, ein komplettes Marktsegment zu definieren, da Serversysteme auch spezialisierte Betriebssysteme und Anwendungen benötigen. Unter Mitarbeit von Red Hat und anderen Betriebssystemherstellern entstand 2016 die Server Base System Architecture (SBSA), eine Spezifikation, die alle Hardware-Schnittstellen beinhaltet, die auf einem Serversystem für das Betriebssystem benötigt werden. Daraufhin entstanden ARM-Linux-Server-Distributionen von Red Hat, SuSE und Ubuntu sowie eine Windows-ARM-Server-Variante von Microsoft, welche wiederum eine Basis von wichtigen Infrastrukturanwendungen zur Verfügung stellen. Die Arm-Architektur ist auch für dieses Marktsegment wegen ihrer geringen Leistungsaufnahme (Preis / Watt und Preis / Performance Index) interessant, weswegen ARM Serverprozessoren auch für Höchstleistungsrechner und Supercomputer bewirbt. ⓘ

Mehrere Partner (Architektur-Lizenznehmer) entwickelten daraufhin ARM-Server-Prozessoren:

• X-Gene bzw. EMag und Altra-CPUs von Ampere (ex Applied Micro),
• ThunderX von Cavium, verbaut im Supercomputer ASTRA am Sandia-Laboratory
• Centriq von Qualcomm,
• A64FX von Fujitsu, diese CPU ist die erste Realisierung der Scalable-Vector-Extension-Spezifikation, eine SIMD-Einheit für energieeffizientes Höchstleistungsrechnen. Die CPU ist im Fugaku (Supercomputer) verbaut. ⓘ

Im Herbst 2018 gibt ARM dann eine eigene Roadmap über Technologien für Server-Prozessoren, genannt Neoverse heraus. Dies dokumentiert, dass weitere ARM-Entwicklungen und Support für die Entwicklungspartner zu erwarten sind. ⓘ

PSA-zertifiziert

PSA Certified, früher Platform Security Architecture genannt, ist ein architekturunabhängiger Sicherheitsrahmen und ein Bewertungsschema. Es soll dazu beitragen, Geräte des Internets der Dinge (IoT) zu sichern, die auf System-on-Chip (SoC)-Prozessoren aufgebaut sind. Sie wurde eingeführt, um die Sicherheit zu erhöhen, wenn eine vollständig vertrauenswürdige Ausführungsumgebung zu groß oder zu komplex ist. ⓘ

Die Architektur wurde von Arm Holdings im Jahr 2017 auf der jährlichen TechCon-Veranstaltung vorgestellt. 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 Entscheidung über Sicherheitsmerkmale in gängigen IoT-Produkten veranschaulichen. Darüber hinaus bietet es frei herunterladbare API-Pakete (Application Programming Interface), Architekturspezifikationen, Open-Source-Firmware-Implementierungen und entsprechende Testsuiten. ⓘ

Nach der Entwicklung des Architektur-Sicherheitsrahmens im Jahr 2017 wurde das PSA Certified-Zertifizierungssystem zwei Jahre später auf der Embedded World 2019 vorgestellt. PSA Certified bietet ein mehrstufiges Sicherheitsbewertungsschema für Chip-Anbieter, OS-Anbieter und IoT-Gerätehersteller. In der Präsentation auf der Embedded World wurde Chip-Anbietern die Level-1-Zertifizierung vorgestellt. Gleichzeitig wurde ein Entwurf für den Level-2-Schutz vorgestellt. Die Level-2-Zertifizierung wird im Februar 2020 zu einem brauchbaren Standard. ⓘ

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, sodass sie auf jeden Chip, jede Software und jedes Gerät angewendet werden können. Die Zertifizierung beseitigt auch die Fragmentierung der Branche für Hersteller und Entwickler von IoT-Produkten. ⓘ

Unterstützung von Betriebssystemen

32-Bit-Betriebssysteme

Historische Betriebssysteme

Der erste 32-Bit-Personalcomputer auf ARM-Basis, der Acorn Archimedes, war ursprünglich für die Ausführung eines anspruchsvollen Betriebssystems namens ARX vorgesehen. Die Maschinen wurden mit RISC OS ausgeliefert, das auch auf späteren ARM-basierten Systemen von Acorn und anderen Anbietern verwendet wurde. Einige frühe Acorn-Maschinen waren auch in der Lage, eine Unix-Portierung namens RISC iX auszuführen. (Beides ist nicht zu verwechseln mit RISC/os, einer zeitgenössischen Unix-Variante für die MIPS-Architektur). ⓘ

Eingebettete Betriebssysteme

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

• A2
• Android
• ChibiOS/RT
• Deos
• DRYOS
• eCos
• embOS
• FreeBSD
• FreeRTOS
• Integrität
• Linux
• Mikrocontroller-Betriebssysteme
• Mbed
• MINIX 3
• MQX
• Nukleus PLUS
• NuttX
• Eingebettetes Betriebssystem (OSE)
• OS-9
• Pharos
• Plan 9
• PikeOS
• QNX
• RIOT
• RTEMS
• RTXC Quadros
• SCIOPTA
• ThreadX
• TizenRT
• T-Kernel
• VxWorks
• Windows Eingebettet Kompakt
• Windows 10 IoT-Kern
• Zephyr ⓘ

Betriebssysteme für mobile Geräte

Die 32-Bit-ARM-Architektur ist die primäre Hardware-Umgebung für die meisten Betriebssysteme für mobile Geräte wie z. B.:

• Android
• BlackBerry OS/BlackBerry 10
• Chrome OS
• Mobian
• Sailfish
• PostmarketOS
• Tizen
• Ubuntu Touch
• webOS

Ehemals, aber jetzt eingestellt:

• Bada
• Firefox OS
• MeeGo
• iOS 10 und früher
• Symbian
• Windows 10 Mobil
• Windows RT
• Windows Phone
• Windows Mobile ⓘ

Desktop-/Server-Betriebssysteme

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

• FreeBSD
• NetBSD
• OpenBSD
• OpenSolaris
• mehrere Linux-Distributionen, wie z.B.:
  • Debian
  • Armbian
  • Gentoo
  • Ubuntu
  • Raspberry Pi OS (ehemals Raspbian)
  • Slackware ⓘ

64-Bit-Betriebssysteme

Eingebettete Betriebssysteme

• Integrität
• OSE
• SCIOPTA
• seL4
• Pharos
• FreeRTOS
• QNX
• Zephyr ⓘ

Betriebssysteme für mobile Geräte

• Android unterstützt ARMv8-A in Android Lollipop (5.0) und höher.
• iOS unterstützt ARMv8-A in iOS 7 und später auf 64-Bit-SoCs von Apple. iOS 11 und später unterstützt nur 64-Bit-ARM-Prozessoren und -Anwendungen.
• Mobian
• PostmarketOS
• Arch Linux ARM
• Manjaro ⓘ

Desktop-/Server-Betriebssysteme

• Die Unterstützung für ARMv8-A wurde Ende 2012 in die Linux-Kernelversion 3.7 aufgenommen. ARMv8-A wird von einer Reihe von Linux-Distributionen unterstützt, wie z. B.:
  • Debian
  • Armbian
  • Alpine Linux
  • Ubuntu
  • Fedora
  • openSUSE
  • SUSE Linux Enterprise
  • RHEL
  • Raspberry Pi OS (ehemals Raspbian, Beta-Version ab Anfang 2022)
• Die Unterstützung für ARMv8-A wurde Ende 2014 in FreeBSD integriert.
• OpenBSD bietet seit 2017 experimentelle ARMv8-Unterstützung.
• NetBSD bietet seit Anfang 2018 ARMv8-Unterstützung.
• Windows 10 - führt 32-Bit-"x86- und 32-Bit-ARM-Anwendungen" sowie native ARM64-Desktop-Anwendungen aus. Unterstützung für 64-Bit-ARM-Apps im Microsoft Store ist seit November 2018 verfügbar.
• macOS hat ARM-Unterstützung ab macOS Big Sur ab Ende 2020. Rosetta 2 bietet Unterstützung für x86-64-Anwendungen, aber keine Virtualisierung von x86-64-Computerplattformen. ⓘ

Portierung auf 32- oder 64-Bit-ARM-Betriebssysteme

Windows-Anwendungen, die für ARM neu kompiliert und mit Winelib aus dem Wine-Projekt verknüpft wurden, können auf 32-Bit- oder 64-Bit-ARM unter Linux, FreeBSD oder anderen kompatiblen Betriebssystemen ausgeführt werden. x86-Binärdateien, die nicht speziell für ARM kompiliert wurden, wurden unter Verwendung von QEMU mit Wine (unter Linux und anderen Betriebssystemen) auf ARM vorgeführt, funktionieren jedoch nicht mit der vollen Geschwindigkeit oder der gleichen Leistungsfähigkeit wie mit Winelib. ⓘ

Einsatzgebiet

IoT-Geräte

Auch auf dem Raspberry Pi ist ein Ein-Chip-System von Broadcom mit einem ARM-Mikroprozessor verbaut. ⓘ

Ausführungsmodi

Die ARM kennt mehrere Ausführungsmodi, die über bestimmte Ereignisse betreten werden und teilweise dem ausgeführten Code zusätzliche Privilegien einräumen. Im Einzelnen sind das:

• User-Mode: normaler User-Code
• Supervisor-Mode (SVC): privilegierte Betriebssystem-Tasks, Eintritt z. B. durch Aufruf eines Software-Interrupts (SWI)
• Hypervisor-Mode (HYP): privilegierte Tasks zur Erfüllung von Hypervisor-Funktionen
• Interrupt-Mode (IRQ): Eintritt durch Auftreten eines äußeren Interrupt-Requests während der Befehlsverarbeitung
• Fast-Interrupt-Mode (FIQ): Eintritt durch Auftreten eines äußeren Fast-Interrupt-Requests. Fast-Interrupts werden meist nur für besonders zeitkritische Ereignisse benutzt (siehe Echtzeitsysteme).
• Memory-Abort (ABT): tritt auf, wenn eine Datenanforderung nicht erfüllt werden kann.
• Undefined-Instruction-Exception (UND): Eintritt durch Auftreten einer unbekannten Instruktion. Wird z. B. zur Emulation eines Gleitkomma-Coprozessors verwendet. ⓘ

r13, r14 und das Statusregister werden für die Interrupt- und Exception-Modi gespiegelt (sogenannte Schattenregister), so dass Ausnahmebehandlungsroutinen sich nicht um die Sicherung des User-Stackpointers oder Link-Registers zu kümmern brauchen. Für die Fast Interrupts werden zusätzlich r8...r12 gespiegelt und stehen so dem Programmierer einer Interrupt-Service-Routine direkt zur Verfügung, ohne dass er den Inhalt dieser Register vorher sichern müsste. ⓘ

Multi-Kern CPUs

DynamIQ

2017 führte Arm DynamIQ ein; eine DynamIQ Shared Unit (DSU) verwaltet mehrere CPU-Cores in einem Cluster mit gemeinsamem L3-Cache und gemeinsamer Anbindung nach außen. Arm erweiterte dabei das Big.LITTLE-Konzept in mehreren Punkten:

• in DynamIQ können bis zu 6 Cluster unterschiedlicher oder gleicher CPU-Kerne zusammenarbeiten, es können beliebige "Mischungen" angebunden werden
• in einem Cluster können bis zu 8 CPU-Kerne enthalten sein, denen je Cluster ein gemeinsamer L3-Cache zur Verfügung steht
• die Kerne sind mit geringerer Latenz an den CoreLink genannten Cache Coherent Interconnect (CCI) angekoppelt, alle Cluster können auf den Level-3-Cache zugreifen, Tasks können damit gleichzeitig auf mehrere Cluster verteilt werden.
• Bis zu 24 Kerne können angeschlossen werden
• Das Memoryinterface kann über 1 oder 2 je 128- oder 256-bit breite AMBA ACE oder AMBA CHI Ports angebunden werden
• Bis zu 6 Hauptspeicherkanäle können angebunden werden
• Die Cluster und einzelne Kerne können mit unterschiedlichen Frequenzen und Spannung betrieben werden, was zu einer höheren Energieeffizienz führt
• neben Cortex-A-CPU-Kernen können auch andere „Beschleuniger“ angebunden werden ⓘ

2021 stellte Arm zusammen mit den ersten ARMv9-CPU-Cores Cortex-A510, -A710 und -X2 eine neue DynamIQ Shared Unit vor, DSU-110 genannt:

• Organisation in zwei bi-direktionale Ringe mit je vier Knoten
• Der L3 ist in bis zu 8 Slices aufgeteilt, auf die parallel zugegriffen werden kann; Arm verspricht eine bis zu fünffache Bandbreite
• Es können nun bis zu 16 MB gemeinsame L3 verwaltet werden
• Unterstützung von Memory Tagged Extensions (MTE)
• Der ebenfalls neue CoreLink CI-700 kann nun über 1, 2 oder 4 je 256-bit breite AMBA CHI Ports angebunden werden ⓘ

Die DynamIQ-CCI-Einheiten werden für SoCs ausschließlich zusammen mit den Arm-eigenen 64-Bit-Kernen A55 und A510, A75 bis A710 und X1/X2 angeboten. ⓘ

Server Interconnect

2014 stellte Arm eine Familie von Systemlösungen für Server-CPUs vor, die CCN-500 Interconnect Serie, die je nach Modell zwischen 4 und 12 Cluster mit je 4 CPU-Kernen in einem koherenten Netzwerk vereinen konnte; es waren 2 bis 4 Speicherkanäle möglich, der gemeinsame L3-Cache umfasste bis zu 8 bzw. bis zu 32 MB. ⓘ

2016 stellte Arm den Nachfolger, den CMN-600 Interconnect vor, der bis zu 32 Cluster mit je 4 CPU-Kernen in einem koherenten Mesh-Netzwerk mit 64 (8 × 8) Knoten vereinen kann. Es sind bis zu 8 Speicherkanäle und 4 CCIX-Ports (seit Revision 2) möglich und der gemeinsame L3-Cache kann bis zu 128 MB umfassen. ⓘ

2021 wurde von Arm der Interconnect CMN-700 vorgestellt. In einem kohärenten Mesh-Netzwerk mit 144 (12 × 12) Knoten können nun 256 CPU-Cores, 40 Speichercontroller (DRAM, HBM) und 32 CCIX-Ports eingebunden werden und der gemeinsame L3-Cache kann bis zu 512 MB umfassen. ⓘ

Versionen

ARMv2 (1986)

Die ARMv2-Architektur umfasst zwei Familien: ARM2 und ARM3. ⓘ

Der ARM2 ist ein von dem englischen Unternehmen Acorn Computers Ltd. entwickelter 32-Bit-RISC-Prozessor. Dieser wurde 1986 veröffentlicht und ab 1987 im Acorn Archimedes eingesetzt. Beim Standardtakt von 8 MHz wurden für damalige Verhältnisse unglaubliche 4 MIPS erreicht. 1991 erschien der ARM250, der ebenfalls auf dem ARM2 basierte, aber nun mit 12 MHz getaktet war und 7 MIPS erreichte. Außerdem wurden eine MMU-Einheit sowie ein Grafik- und IO-Prozessor integriert. Eingesetzt wurde diese CPU nur in den Archimedes-Modellen A3010, A3020 und A4000. ⓘ

Der ARM3 ist ebenfalls ein 32-Bit-RISC-Prozessor, der von Acorn Computers Ltd. entwickelt wurde. Er wurde 1989 veröffentlicht und in den Archimedes-Modellen A540, A5000 und A4 eingesetzt. Bei diesem Prozessor hat Acorn erstmals einen Cache mit 4 KiB integriert. Mit einer Taktfrequenz von 25 MHz erreicht der ARM3 12 MIPS. ⓘ

ARMv3 (1991)

Der ARM6 ist ein von der mittlerweile gegründeten ARM Limited 1991 veröffentlichter 32-Bit RISC-Prozessor, der als CPU beispielsweise im Apple Newton oder Acorns Risc PC eingesetzt wurde. Der CPU-Takt betrug 12–33 MHz. ⓘ

ARMv4 (1993)

32-bit ARM 60 RISC in einer 3DO-Spielkonsole FZ-10 (1993) ⓘ

Der ARM7TDMI war das Low-End-Modell der ARM-Familie und wurde vor allem als Komponente in SoCs für Mobiltelefone und andere portable Kommunikations- oder Multimediageräte verwendet, darunter der Game Boy Advance, Nintendo DS (als Subprozessor) und Nintendo 3DS (ebenso als Subprozessor). Die Kürzel im Modellnamen stehen für Thumb Instruction Set (Programmspeichersparender 16-Bit-Modus des 32-Bit-Kernes), Debug Port, 64-Bit-Result Multiplier und Embedded ICE Modul. ⓘ

Der ARM7TDMI hat eine dreistufige Pipeline und einen gemeinsamen Bus für Instruktionen und Daten. ⓘ

Der gemeinsam mit DEC entwickelte ARM StrongARM war die erste Abspaltung der Arm-Architektur, die 1995 als SA-110 im Newton 2000 durch einen Stromsparmodus für lange Akkulaufzeiten sorgte. Der Nachfolger SA-1100 (1997) war mit einer LCD-Schnittstelle, einer MCP-Audio/Touchscreen-Schnittstelle, PCMCIA-Unterstützung, IrDA, USB und DMA-Controller eines der ersten System-on-a-Chip. ⓘ

ARMv5TE (1997)

Die Architekturversion 5TE wurde von ARM in den Prozessormodellen ARM7EJ, ARM9E und ARM10E implementiert. ARM9 ist eine Weiterentwicklung der StrongARM- und ARM8-Prozessoren. Der wesentliche Unterschied des ARM9 gegenüber dem ARM7 ist je ein getrennter Bus für Instruktionen und Daten (Harvard-Architektur). Meist werden diese an separate Caches für Daten und Instruktionen angeschlossen. Außerdem hat der ARM9 eine fünfstufige Pipeline und kann so höhere Taktraten erreichen und weist bessere CPI-Werte (Cycles per Instruction) auf. Wird der ARM9 ohne Caches an einem externen Speicher mit nur einem Datenbus betrieben, schrumpft der Geschwindigkeitsvorteil gegenüber dem ARM7-Design wegen häufiger Pipeline-Stalls mit einer höheren "Penalty" durch die längere Pipeline. Ohne Cache kann in einem solchen ungünstigen Szenario ein ARM7 aufgrund seiner kürzeren Pipeline trotz eines deutlich niedrigeren Taktes schneller sein. Allerdings sollte dieser Fall in realen Systemen nicht auftreten, da ein ARM9 teurer ist und nur wegen seiner besseren Performance ausgewählt wird. Kommt es eher auf die Kosten an, so spart man sinnvollerweise nicht am Cache, sondern verwendet einen ARM7. ⓘ

Intel stellte ab dem Jahr 2002 auf Basis der ARMv5TE die Prozessoren der XScale-Reihe (802xx, PXA25x, XA263, PXA26x, PXA27x, PXA3xx) vor, die mit einer Taktfrequenz bis zu 1250 MHz in viele mobile Geräte (Palm Tungsten, Sony Clié) Eingang fanden. 2006 wurde die XScale-Entwicklung an die Marvell Technology Group verkauft. Im Juni 2008 stellte Marvell den auf Basis der ARMv5TE entwickelten Sheeva-Mikroprozessor vor. Dieser ist als Hauptprozessor für die Integration in die hauseigenen Ein-Chip-Systeme vorgesehen. Ein von Marvell entwickeltes SoC mit Sheeva-CPU bildet die Basis für den ersten zur Marktreife gebrachten „Plug Computer“. Der sogenannte SheevaPlug wurde im Jahr 2009 vorgestellt. ⓘ

Armv9-A (2021)

Die neunte Version der Arm-Architektur wurde im März 2021 vorgestellt. Mit Armv9-A setzt Arm auf der Basis von Armv8.5-A auf, die Erweiterungen für Memory Tagging (MTE) und Transactional Memory (TME) werden Pflicht, ebenso Scalable Vector in der Version 2 (SVE2) bei Erhalt der Kompatibilität zu NEON. Neu ist auch das Sicherheitskonzept Realms. Die Kompatibilität zur vorhandenen AArch32-Software wurde auf Applikationsebene beschränkt (EL0) und ist nur noch optional. So wie Armv9-A eine volle Implementierung von Armv8.5-A voraussetzt, wird Armv9.1-A nach einer vollen Implementierung von Armv8.6-A und Armv9.2-A nach einer von Armv8.7-A verlangen. ⓘ

Erweiterungen für ARM-Kerne

ARM Ltd. verkauft neben den ARM-CPU-Kernen auch Erweiterungen als synthetisierbare Makrozellen für den SoC-Entwurf, unter anderem Memory Management Units, Floating-Point-Coprozessoren sowie Signalprozessor-Erweiterungen (Piccolo). ⓘ