RISC, CISC, MISC ...

Inhaltsverzeichnis

Bei der Vorplanung hatten die Acorn-Designer Wilson und Furber vier Design-Ziele im Auge:

• kleine Codegröße,
• hohe Performance,
• gute Echtzeittauglichkeit,
• niedriger Preis.

Vor allem mit der Echtzeittauglichkeit bestehender Designs waren die Entwickler nicht zufrieden, daher machten sie sich an die mühevolle Arbeit einer Eigenentwicklung. Die Mittel waren bescheiden und so geriet die ARM-Architektur sehr einfach. Das brachte aber auch den Vorteil eines kleinen Kerns mit sich, der Prozessoren mit geringem Energieverbrauch ermöglichte.

Als Vertreter der reinrassigen RISC-Lehre (Reduced Instruction Set Computer) weist der ARM-Prozessor die hierfür typischen Merkmale auf:

Load/Store-Architektur: Die Datenverarbeitung erfolgt nur über Register, die direkte Manipulation des Speichers oder Operationen wie ADD, OR et cetera direkt aus dem Speicher heraus ist nicht möglich.

Einfache Adressierungsmodi: Alle Load/Store-Adressen werden aus den Registerinhalten sowie aus den Befehls-Parametern ermittelt.

Einheitliche Instruktionslänge: Eine feste Länge vereinfacht die Dekodierung erheblich.

Hinzu kamen weitere nützliche Dinge, deren segensreiche Wirkung zum Teil erst viel später offenbar wurden. So kann ARM die Ausführung eines jeden Befehls von Flags abhängig machen, ein Feature, das Intel erst zehn Jahre später in Ansätzen (konditionierte Moves) oder in Form der Predications beim 64-bittigen Itanium-Prozessor realisierte.

Der Befehlssatz und die prinzipielle ARM-Architektur wurden zwischen 1983 und 1985 entwickelt und dann als ARM1 in Form eines Chipsatzes von VLSI gefertigt. Der Core hatte auch noch nicht alle Merkmale der V1-Architektur in Hardware implementiert. Vor allem fehlte der Multiplizierer, der per Software durch Additionen zu ersetzen war. Der Prozessor war vom Kern her 32-bittig, konnte aber nur 26-bittig adressieren, sodass man allgemein von einem 26-Bit-Prozessor sprach.

Sein Nachfolger, der ARM2, hatte vor allem einen deutlich höheren Takt von 8 MHz. Er legte 1987 die Grundlage für den Erfolg der neuen Desktop-Rechnergeneration Archimedes. Richtig rund wurde es aber erst 1989 mit dem ARM3, der sowohl Multiplizierer wie integrierten Cache aufwies. Diese Version bot auch Unterstützung für Co-Prozessoren, der Adressbus blieb jedoch weiterhin auf 26 Bit beschränkt. Der ARM3 arbeitete mit den gleichen `Support-Chips´ wie ARM2 zusammen (MEMC, VIDC, IOC), lief nun aber mit 25 MHz. Daneben wurde der ARM2 in einer statischen Ausführung (ARM2aS) gefertigt. Das ermöglichte, den Takt in Power-Down-Modi zu verringern oder auch - ohne Datenverlust - zwischendurch komplett abzuschalten - ein wichtiges Feature für den Embedded-Markt.

Die Architekturversion 3 brachte endlich eine 32-Bit-Adressierung sowie wichtige neue Register: das CPSR (Current Program Status Register) sowie je Modus ein SPSR (Saved Program Status Register). Für den effektiven Einsatz der Exceptions Data Abort, Prefetch Abort und Undefined Instruction waren jetzt auch zwei neue Prozessor-Modi zuständig.

Version 3 wurde zunächst in den Cores der ARM6-Familie implementiert, wie sie etwa in Apples Newton zu finden waren. Später kam dann ARM7 mit höherer Geschwindigkeit sowie 3-V-Versorgungsspannung. ARM7D und ARM7DI brachten neue Abort-Modi, separate PC und PSR, On-Chip-Debug sowie die Debug-Schnittstelle EmbeddedIce.

Däumling

Zum Durchbruch aber verhalf der ARM-Linie ein zusätzlicher verkleinerter Befehlssatz mit Konzessionen an CISC-Designs, und zwar mit unterschiedlich langen Instruktionen. Die Architekturversion 4T brachte nämlich den so genannten Thumb Instruction Set, der sich auf 16 Bit beschränkt und besonders kompakten Code ermöglicht, was den Prozessor für den Einsatz in kleinen Handheld-Geräten prädestiniert.

Prozessor-Varianten
Suffix	Bedeutung
T	Thumb Instruction Set (wird zusätzlich zum ARM Instruction Set unterstützt)
D	On Chip Debug Option
M (V3)	verbesserter Multiplizierer (long multiply) enthalten
M (ab V4)	verbesserter Multiplizierer nicht (!) enthalten
I	Embedded Ice (Debug-Option)
E	Enhanced DSP Instructions (siehe v5TE)
P	Prozessor unterstützt die DSP-Instruktionen LDRD, STRD, MCRR, MRRC und PLD nicht (nur v5TE-Architektur)
J	Java Extension
S	synthetisierbar

Außerdem brachte Version 4 einen neuen privilegierten Prozessor-Modus zur Verwendung der User-Mode-Register sowie Instruktionen zum Laden von vorzeichenbehafteten Bytes und Halfwords. Implementiert wurde Version 4 in den heute sehr verbreiteten ARM7TDMI und ARM720T. Später kamen dann ARM9TDMI und ARM940T hinzu, die keine gemeinsamen Caches mehr à la Von-Neumann-Architektur, sondern getrennte Caches (Harvard-Architektur) aufwiesen. ARM-Cores der Architektur 4T sind heute überall in zahlreichen Mikrocontrollern zu finden. Besonderen Erfolg hatte V4 auch in dem zusammen mit Digital entwickelten StrongARM, der einen riesigen Sprung im Takt und der Performance bis hin zu derzeit 300 MHz ermöglichte. Dafür `opfert´ StrongARM solche Dinge wie Low-Power oder den Thumb Instruction Set sowie die Debug-Schnittstelle Multi-Ice. Der Multiplizierer wurde stark beschleunigt und neue Zugriffsarten hinzugefügt: Halfword, Signed Halfword und Byte.

Die Version 5T brachte 1998 ein paar kleinere Verbesserungen, etwa eine Count-Leading-Zeros-Instruktion (für effizientere Integer-Division und Interrupt-Priorisierungsroutinen), eine Software-Breakpoint-Instruktion und neue Instruktions-Optionen für Co-Prozessoren. Hinzu kamen ein verbessertes ARM/Thumb-Interworking sowie 64-Bit-Busse. Diese Version wurde im noch recht jungen ARM1020T implementiert - übrigens der erste ARM-Prozessor, der komplett in den USA entwickelt wurde.

Die Version 5TE (1999) bietet zusätzlich das Rechnen mit Saturierung. Bei dieser für DSP-Anwendungen typischen Erweiterung - vornehmlich für den Audio- und Videobereich - führen Überläufe nicht zu einem Wrap Around (Umlauf bei Null), sondern bleiben an dem maximalen oder minimalen Wert `kleben´ - so wie eine Über- oder Untersteuerung in der entsprechenden analogen Welt. Der wohl prominenteste Vertreter der 5TE-Architektur ist noch gar nicht auf dem Markt: Intels XScale-Prozessor. Seine erste Version i80200 soll mit bis zu 733 MHz rennen und dabei nur etwa 0,5 W verbrauchen. XScale führt auch eine neue Cacheversion ein, den Streaming Cache, der für `strömende Daten´ - laden, verarbeiten und zurückschreiben und vorerst nicht wieder anfassen - optimiert ist.

Jazelle

Als Erweiterung zu 5TE hat ARM im Jahr 2000 auf dem Microprocessor-Forum eine Java Virtual Machine vorgestellt: Jazelle (5TEJ). Diese soll Java-Programme gegenüber einer Software-Lösung bis zu achtmal beschleunigen und den Energiebedarf um bis zu 80 Prozent senken.

Und im letzten Herbst hat ARM auf diesem Forum dann Version 6 vorgestellt, welche als wichtigste Neuerung die SIMD-Technik ähnlich wie Intels MMX einführt. Hiermit lassen sich dann mit einem Befehl mehrere Daten gleichzeitig bearbeiten.

Eine wichtige Variante nennt sich SecurCore. Es handelt sich um in Frankreich aus dem ARM7 entwickelte Versionen für den Security-Bereich (Banking, Pay TV, Network Security etc.). Bei Implementierungen für den Security-Bereich gelten eigene Prioritäten, zum Beispiel sind befehlsabhängige sprunghafte Änderungen in der Stromaufnahme (Power Peaks) zu vermeiden, um Rückschlüsse auf den internen Aufbau zu verhindern. SecurCore-Cores erkennt man an Bezeichnungen wie SC100, SC110, SC200 oder SC210.

Steve Furber hat in den neunziger Jahren als Professor an der Universität Manchester eine weitere Idee zum Prozessordesign eingebracht. Beruhend auf dem ARM-Instruktionssatz entwickelte er einen rein asynchronen Prozessor, also ohne jeglichen globalen Systemtakt. Asynchrone Systeme bieten Vorteile auf vielen Gebieten, vor allem auch beim Stromverbrauch und bei der elektromagnetischen Emission (EMC). AMULET1 und AMULET2 implementierten die ARM6-Architektur, der AMULET3 unterstützt die Architektur-Version 4T und damit auch den Thumb Instruction Set. Auf der Basis des AMULET3 wurde der DRACO (DECT Radio Communications Controller) von Hagenuk GmbH in Zusammenarbeit mit der University of Manchester als erstes kommerzielles Produkt entwickelt. Die taktlose AMULET-Technologie hat hier Vorteile, da bei synchronen Systemen Oberwellen des Systemtaktes Störungen in DECT-Frequenzbändern verursachen.

Von Thumb zu ARM

Alle ARM-Prozessoren mit der Erweiterung `T´ unterstützen zusätzlich zum 32-bittigen ARM-Befehlssatz auch den 16-bittigen Thumb Instruction Set. Der Thumb Instruction Set wurde speziell für den Embedded Markt entwickelt mit dem Ziel, die Code-Größe und damit Speicherkosten zu reduzieren. Die Thumb-Option ist daher für Lowcost-Systeme sehr interessant und hat wesentlich zum Erfolg der ARM-Prozessoren beigetragen.

In der Thumb-Betriebsart wandelt der Prozessor die 16-Bit-Thumb-Instruktionen vor der Ausführung in 32-bittige ARM-Instruktionen um, daher besteht eine direkte Abbildung von Thumb auf ARM. ARM- und Thumb-Instruktionen können jedoch nicht beliebig gemischt eingesetzt werden, der Prozessor ist zwischen der ARM- und der Thumb-Betriebsart mit einem speziellen Branch-Befehl umzuschalten. Der Entwickler kann aber für jede Routine einzeln festlegen, ob sie im ARM- oder Thumb-Modus zu verwenden ist.

Der Thumb-Betrieb ist also nur eine Art Code-Kompression mit einer Instruktionslänge von 16-Bit, ansonsten liegt weiterhin die 32-Bit-Architektur vor. Der volle 32-Bit-Adressraum sowie die 32-bittigen Register stehen daher weiterhin auch dem `Däumling´ zur Verfügung. Thumb-Code kennt nur halb so viele Instruktionen wie ARM und benötigt daher aufgrund seiner Einschränkungen für gleiche Aufgaben mehr Instruktionen. Doch alles in allem ist Thumb-Code typischerweise etwa 30 Prozent kleiner als ARM-Code. Ein wenig leidet allerdings die Performance, da der Prozessor für das gleiche Ziel eben mehr Instruktionen auszuführen hat. Bei Sparsystemen mit 16-bittigem Speicher ist Thumb aber dennoch performancemäßig oft leicht im Vorteil, da er hier pro Zugriff einen Befehl holen kann, wohingegen ARM zwei Speicherzugriffe benötigt.

Da es aber nicht nur Instruktionen gibt und die 32-Bit-Register auch im Thumb-Betrieb häufig auf den Stack ausgelagert werden müssen, ist es sinnvoll, für optimale Performance auch bei 16-Bit-Systemen einen kleinen internen 32-Bit-Speicher für den Stack vorzusehen.

Thumb kennt keine Instruktionen für die Behandlung von Exceptions, die Exception Handler sind daher grundsätzlich für ARM zu kodieren. Das gilt auch für zeitkritische Routinen.

Bäumchen, wechsle dich

Im Laufe der Zeit ist die ARM-Architektur auf sieben Betriebsmodi ausgeweitet worden. Wie bei modernen Allzweckprozessoren auch, unterscheidet man zwischen privilegiertem und nicht privilegiertem Modus.

ARM-Betriebsarten
User	der einzige nicht privilegierte Modus, ihn ihm laufen die meisten Anwendungen
FIQ	Behandlung eines hoch priorisierten Interrupt
IRQ	Behandlung eines normalen Interrupt
Supervisor	nach einem Reset und nach einem Software Interrupt
Abort	bei Speicher-Schutzverletzungen
Undef	zur Behandlung undefinierter Instruktionen
System	privilegierter Modus, der auf die gleichen Register wie der User-Modus zugreift (nicht in V1, 2, 3)

Aus Sicht des Prozessors ist der Unterschied aber sehr gering, ein Signal zeigt den Modus nach außen an und der Memory Controller kann das nutzen, um den Zugriff auf bestimmte Adressen bei privilegierten Modi einzuschränken. Weiterhin sind einige Operationen nur in den privilegierten Modi möglich, wie der direkte Wechsel in einen anderen Prozessor-Modus oder das Sperren von Interrupts.

Insgesamt bietet die aktuelle ARM-Architektur 37 Register, alle mit 32 Bit Breite. Allerdings stehen nicht alle Register gleichzeitig zur Verfügung, ein Teil wird je nach Prozessor-Modus eingeblendet. In jedem Modus lassen sich dann 17 Register adressieren:

• r0 bis r7: allgemeine Register, in allen Betriebsarten verfügbar;
• r8 bis r12 bei Fast Interrupt Modus umgeschaltet, sonst allgemeine Register;
• r13 wird üblicherweise als Stackpointer (SP) verwendet. Für jeden Prozessor-Modus steht ein eigenes r13-Register zur Verfügung, sodass jede Exception einen eigenen Stack verwalten kann;
• r14 ist das Link Register (LR) und enthält die Adresse der nächsten Instruktion nach einer Branch-And-Link Instruktion (BL), das heißt nach einem Aufruf einer Unterroutine. Zu allen anderen Zeiten kann R14 als Allzweckregister (General Purpose) verwendet werden. Es steht ebenfalls für jeden Modus ein eigenes r14 zur Verfügung.
• r15 wird als Programm Counter (PC) verwendet;
• CPSR: das Current Program Status Register speichert weitere Informationen über den Status des Prozessors, in ihm finden sich die Interrupt-Maske, Condition Code Flags sowie der aktuelle Betriebs-Modus.

Alle ARM-Instruktionen können jedes dieser Register adressieren. Privilegierte Modi (alle Modi außer dem User-Modus) bieten zusätzlich Zugang zum Saved Program Status Register (SPSR), welches für jeden der fünf Exception-Modi getrennt existiert. Hier merkt sich der Prozessor den aktuellen Zustand CPSR während einer Exception.

Exceptions
0x1C	FIQ
0x18	IRQ
0x14	reserved
0x10	Data Abort
0x0C	Prefetch Abort
0x08	Software Interrupt
0x04	Undefined Instruction
0x00	Reset

Thumb beschränkt sich je nach Befehl auf eine Untermenge der Register

• r0 bis r7: voller Zugriff möglich;
• r8 bis r15: nur erreichbar mit den Instruktionen MOV, ADD, CMP;
• SP, LR, PC: eingeschränkter Zugriff, einige Instruktionen greifen auf diese Register implizit zu;
• CPSR: es können nur die Condition Code Flags mit der CMP-Instruktion gesetzt werden;
• SPSR: kein Zugriff.

Ausnahmen

Exceptions werden beim ARM durch eine Vektor-Tabelle geregelt, die typischerweise bei der Adresse 0 beginnt (für Windows CE wurde beim ARM720T und ARM9/10 auch die Möglichkeit eingebaut, diese Tabelle zu höheren Adressen zu verschieben). Die Tabelleneinträge enthalten pro Exception-Typ einen 32-Bit-Wert mit einer Sprunganweisung, also keine Adressen!

Interessant für Echtzeitanwendungen ist der Fast Interrupt FIQ, der sich in mehreren Aspekten von normalen IRQ-Interrupts unterscheidet. Insbesondere bietet er einen eigenen FIQ-Modus mit den privaten Registern r8 bis r12. Das spart viel Zeit, da so der Handler nicht auf den Stack zugreifen muss, um die User-Mode-Register zu sichern. Außerdem lässt sich in Systemen mit vielen Interrupt-Quellen der zeitkritischste direkt dem FIQ zuordnen, sodass für ihn auch die mitunter zeitaufwendige Suche nach der Interrupt-Quelle entfällt. Und schließlich befindet sich ein Eintrag am Ende in der Vektortabelle - in weiser Voraussicht, denn hier kann man dann direkt ab Adresse 0x1C die FIQ-Behandlungsroutine beginnen. Das spart einen Sprung und jeder eingesparte Takt ist bei `Fast Interrupt´-Behandlung wichtig.

Befehle mit Wenn und Aber

Wie eingangs schon angedeutet, lassen sich bei ARM alle Befehle konditionell ausführen. Dazu kann man die Flags Carry, Zero und das Vorzeichen miteinander kombinieren. Dem ARM-Assembler teilt man die gewünschte Bedingung einfach durch Anhängen des entsprechenden Suffix mit, zum Beispiel

ADDEQ r5, r5, r6 ; wenn EQ, r5 = r5 + r6 

Multiplikationen
Modell	MUL	MLA	MULL	MLAL
ARM7TDMI	2-5	3-6	3-6	4-7
ARM9TDMI	3-6	3-6	4-7	4-7
ARM9E	2	2	3	3
StrongARM	1-3	1-3	2-4	2-4
XScale	1-3	1-3	1-4	2-4
in Prozessortakten

Damit man solche Konditionen über mehrere Befehle ausweiten kann, ohne dass die Operationen die ursprünglichen Flags überschreiben, muss der Softwareentwickler mit einer angehängten Endung `S´ (nur im ARM-Betrieb) festlegen, dass der Befehl die Flags neu setzen soll:

ANDS r4, r4, #0x20 ; r4 = r4 AND 0x20  mit Aktualisierung der CC-Flags 

Dieses Konzept erspart eine Unmenge von Sprüngen und ermöglicht so besonders effizienten Code. Ansonsten ist der Instruktionssatz typisch für RISC-Prozessoren in zwei Gruppen aufgeteilt, den Datenverarbeitungs-Instruktionen, die mit den internen Registern arbeiten, und den Load/Store-Instruktionen für den Transfer der Daten zwischen den Registern und der Außenwelt.

Arithmetische Instruktionen verwenden zwei Quell-Operanden sowie ein Zielregister. Der eine Quell-Operand ist immer ein Register, der andere ist entweder eine Konstante oder ein Register:

SUB r0, r1, #5 ; r0 = r1 - 5 

Logische Instruktionen verwenden ebenfalls zwei Quell-Operanden sowie ein Zielregister:

AND r4, r4, #0x20 ; r4 = r4 AND 0x20 

Der Barrel Shifter kann in eine Kalkulation direkt einbezogen werden. Der Wert für den Shifter kann sowohl eine Konstante sein, als auch einem weiteren Register entnommen werden:

ADD r2, r3, r3, LSL #2 ; r2 = r3 * 5 

Konditionen
Suffix	Bedeutung	CC-Flags
EQ	Eqal	Z=1
NE	Not equal	Z=0
CS/HS	Unsigned higher or same	C=1
CC/LO	Unsigned lower	C=0
MI	Minus	N=1
PL	Positive or Zero	N=0
VS	Overflow	V=1
VC	No Overflow	V=0
HI	Unsigned higher	C=1 & Z=0
LS	Unsigned lower or same	C=0 & Z=1
GE	Greater or equal	N=V
LT	Less than	N !=V
GT	Greater than	Z=0 & N=V
LE	Less than or equal	Z=1 or N=!V

Vergleichende Instruktionen modifizieren lediglich die Bedingungs-Flags im CPSR. Der C-Code

if (a==4 || a==10) x=0; 

entspricht den Assembler-Anweisungen:

CMP    r0, #4
CMPNE    r0, #10
MOVEQ    r1, #0 

Multiplikationen gibt es in zwei Varianten: 32 Bit und 64 Bit (hier wird das Ergebnis in zwei Registern übergeben). Die ersten ARM-Versionen benötigten 70 Takte für Multiplikationen, aktuelle Versionen sind inzwischen deutlich flinker.

Eine der neuen Features des ARM Instruction Set sind `Count Leading Zeros´-Instruktionen. Diese zählen die Anzahl der führenden Nullen eines Registerwertes, das Ergebnis wird in das Zielregister geschrieben. Solche Instruktionen sind nützlich zur Beschleunigung von Divisionen, zur Gleitkomma-Normalisierung oder auch zur Ermittlung der Interrupt-Quelle.

Absolute Sprünge sind durch Überschreiben des Program Counter (PC) innerhalb des 4-GByte-Adressraumes möglich. Relative Sprünge werden im Bereich ±32MByte unterstützt. Die Branch-and-Link-Instruktion (BL) speichert zusätzlich im Link Register (LR) vor der Verzweigung die Adresse des nächsten Befehls - nach Abarbeitung einer Unterroutine kopiert man das LR einfach in den PC, um in das Hauptprogramm zurückzukehren. Eine weitere Branch-Instruktion ist in der Lage, gleichzeitig einen State-Wechsel vorzunehmen. So kann Thumb-Code eine ARM-Unterroutine aufrufen oder umgekehrt.

Status-Register-Transfer-Instruktionen kopieren den Inhalt des CPSR oder SPSR in ein Allzweckregister oder umgekehrt. Durch Beschreiben des CPSR können die Bedingungs-Flags geändert, Interrupts zugelassen oder gesperrt sowie der Prozessor-Modus gewechselt werden.

Load/Store-Register-Instruktionen ermöglichen Transfers mit 8, 16 oder 32 Bit zwischen Register und Speicher. Zum Basisregister kann optional ein Offset addiert und die berechnete Zieladresse bei Bedarf auch vor oder nach der Operation in das Basisregister zurückgeschrieben werden. Wird der Offset nicht als Konstante, sondern über ein Indexregister übergeben, sind auf ihn auch Shift-Operationen anwendbar. Für Load/Store-Instruktionen sind neun verschiedene Adressierungsmodi möglich. Zum Beispiel LDRSH r5, [r6,#8]! lädt r5 mit dem Inhalt der Adresse (r6+8), überträgt aber nur 16 Bit mit Vorzeichen (SH = SignedHalfword). Die Angabe des Ausrufzeichens bewirkt, dass r6 anschließend automatisch inkrementiert wird (r6 += 8)

Load/Store-Multiple-Register-Instruktionen kopieren gleich mehrere Register auf einmal in den Speicher oder umgekehrt. Sie unterstützen dabei auch Post- oder Pre-Inkrement/Dekrement. Da PC und LR als Allzweckregister ausgelegt sind, kann man mit diesen Instruktionen Unterroutinen effizient aufrufen und beenden. Wenn ausreichend freie Register zur Verfügung stehen, lassen sich diese Instruktionen ebenfalls einsetzen, um Speicherblöcke effizient zu kopieren. Zuweilen sind solche `Multi´-Befehle wegen ihrer langen Bearbeitungszeit aber unerwünscht, da sie sich durch einen Interrupt nicht abbrechen lassen und somit die Worst-Case-Latenzzeit bei Interrupts erhöhen.

Swap-Instruktionen tauschen den Inhalt eines Registers mit dem Inhalt einer Speicheradresse aus. Diese Instruktion arbeitet `atomic´, das heißt, sie kann nicht unterbrochen werden und eignet sich vor allem für die Aktualisierung von Semaphoren (8- und 32-bittig).

Coprozessor-Instruktionen können eine Coprozessor-spezifische interne Operation starten oder Daten zwischen dem Coprozessor und Speicher/ARM-Registern übertragen.

Software-Interrupt-Instruktionen dienen normalerweise als API für Betriebssystemaufrufe. Bei Aktivierung dieser Exception wechselt der Prozessor in den privilegierten Modus

Software-Breakpoint-Instruktionen sind für Debugger gedacht.

Der Coderaum, also die belegten Opcode-Möglichkeiten, ist noch nicht voll ausgeschöpft, hier gibt es noch reservierte Kombinationen. Intels XScale etwa bringt noch ein paar Erweiterungen ein. Und die Architektur-Version 6 klinkt sich mit den SIMD-Befehlen und anderen Erweiterungen ein. Doch noch gibt es dafür kein Silizium.

Dipl.-Ing. Mathias Lindner ist als Gruppenleiter bei der sci-worx GmbH in Hannover mit der Hard- und Software-Entwicklung für Embedded-Systeme befasst, darunter solche mit ARM-Prozessoren. (as)