Dieser Artikel wurde maschinell übersetzt.

CLR

.NET-Entwicklung für ARM-Prozessoren

Andrew Pardoe

 

Die Verbraucher sind heute eine große Triebkraft für den Technologiemarkt. Wie der Trend, bekannt als "der Verbraucherorientierung davon" belegt, sind lange Akkulaufzeit und immer verbunden und Rich Media-Erlebnisse für alle Technologie-Kunden wichtig. Microsoft bringt um die beste Erfahrung für Geräte mit langer Akkulaufzeit zu aktivieren, die Windows-8-OS in Systeme, die auf dem Niedrigstrom-ARM-Prozessor, der heute die meisten Mobilgeräte Befugnisse. In diesem Artikel werde ich erläutern, Informationen über das Microsoft .net Framework und der ARM-Prozessor, was Sie als Entwickler .net im Hinterkopf behalten sollte und was wir bei Microsoft (wo bin ich ein Programm-Manager im CLR-Team) zu tun hatte um .net ARM zu bringen über.

Als Entwickler .net können Sie sich vorstellen, dass apps laufen auf einer Vielzahl von verschiedenen Prozessoren schreiben ein bisschen wie eine Zwickmühle darstellen würde. Der ARM-Prozessor Befehlssatzarchitektur (ISA) ist nicht kompatibel mit X 86-Prozessor der ISA Apps gebaut, um nativ auf X 86 laufen auch auf X 64 ausgeführt werden, da die X 64-Prozessor ISA eine Obermenge der X 86 ist ISA Aber ist nicht das gleiche gilt für systemeigene X 86 apps laufen auf ARM — sie müssen neu kompiliert werden, um auf die nicht kompatible Architektur ausgeführt werden. Können wählen aus einer Palette verschiedener Geräte ist ideal für Verbraucher, aber es bringt gewisse Komplexität zu der Entwicklergeschichte.

Schreiben Ihre app in einer .net-Sprache nicht nur können Sie Ihre vorhandenen Fähigkeiten und Code wiederverwenden, es ermöglicht auch Ihre app auf alle Windows 8 Prozessoren ohne Neukompilierung. Durch die Portierung der .net Framework zum ARM, haben wir dazu beigetragen, um die Besonderheiten der Architektur zu abstrahieren, die für die meisten Windows-Entwickler nicht vertraut sind. Dennoch gibt es einige Dinge, die, denen Sie benötigen konnten, aufpassen, beim Schreiben von Code zur Ausführung auf ARM.

Der Weg zum ARM: .Net Vergangenheit und Gegenwart

Das .net Framework läuft bereits auf ARM-Prozessoren, aber es ist nicht die exakt gleichen .net Framework als die Version, die auf dem Desktop ausgeführt wird. Zurück, als wir auf die erste Version von .net anfing, erkannten wir, dass die Möglichkeit über Prozessoren leicht portablen Code schreiben Schlüssel für unser Wertversprechen von höhere Entwicklerproduktivität war. X 86-Prozessor beherrscht den Desktop computing Raum, sondern eine Vielzahl von Prozessoren gab es in der embedded und mobilen Raum. Um Entwicklern die Prozessoren als Ziel zu ermöglichen, haben wir eine Version von .net Framework genannt .net Compact Framework, die auf Maschinen läuft, die Speicher- und Prozessorressourcen Einschränkungen haben.

Die ersten Geräte, die das .net Compact Framework unterstützt hatten weniger als 4 MB RAM und ein 33-MHz-CPU. Das Design von .net Compact Framework betont eine effiziente Implementierung (ermöglichte es auf solchen eingeschränkten Geräten ausgeführt) und Mobilität (so dass es über eine große Auswahl an Prozessoren, die in die mobilen und eingebetteten Leerzeichen betrafen laufen konnte). Aber die beliebtesten mobilen Geräte — Smartphones — jetzt auf Konfigurationen, die vergleichbar sind mit den Computern von vor 10 Jahren ausgeführt. Die desktop .net Framework wurde entwickelt für Windows XP-Rechner mit mindestens 300 MHz Prozessor und 128 MB RAM. Windows Phone-Geräte erfordern heute mindestens 256 MB RAM und einer modernen ARM-Cortex-Prozessor.

.NET Compact Framework ist noch ein großer Teil der Windows Embedded Compact Entwickler-Geschichte. Geräte in eingebetteten Szenarien werden in eingeschränkten Konfigurationen, oft mit weniger als 32 MB RAM. Wir haben auch eine Version von .net Framework aufgerufen die .net Micro Framework, die auf Prozessoren ausgeführt wird, die weniger als 64 KB RAM haben erstellt. So haben wir tatsächlich drei .net Framework-Versionen, läuft von denen jeder auf eine andere Klasse von Prozessor. Aber dies ist das erste Mal, das unser Flaggschiff-Produkt, das desktop .net Framework, das kompakt und Micro-Frameworks beigetreten ist, in auf ARM-Prozessoren ausgeführt.

Auf ARM laufen

Obwohl das .net Framework entwickelt wurde, um die Plattform-Neutral sein, es ist meistens wurde laufen auf X 86-basierte Hardware während seiner Existenz. Dies bedeutet, dass einige X 86-spezifischen Muster in das kollektiven Bewusstsein der .net Programmierer gerutscht sein. Sollte man sich konzentrieren auf das Schreiben großer apps statt zu schreiben für die Prozessorarchitektur, aber Sie sollten ein paar Dinge im Auge halten, beim Schreiben von .net Code auf ARM laufen. Dazu gehören ein schwächeres Speichermodell und strengere Datenanforderungen Ausrichtung sowie einige Orte, wo die Funktionsparameter unterschiedlich behandelt werden. Schließlich gibt es einige Projekt-Konfigurationsschritte in Visual Studio, die sich unterscheiden, wenn Sie Geräte ausrichten. Ich werde jede dieser diskutieren.

Ein schwächerer Speichermodell ein "Speichermodell" bezieht sich auf die Sichtbarkeit von Änderungen an globalen Zustand in einem Multithread-Programm. Ein Programm, das Daten zwischen zwei (oder mehr) Threads teilt nehmen normalerweise eine Sperre auf die freigegebenen Daten. Abhängig von der bestimmten Sperre verwendet, wenn ein Thread auf die Daten zugreift, blockieren andere Threads, die versuchen, Zugriff auf die Daten, bis der erste Thread mit den freigegebenen Daten beendet ist. Aber Sperren sind nicht erforderlich, wenn Sie wissen, dass jeder Thread den Zugriff auf die freigegebenen Daten dies tun wird, ohne zu stören andere Threads Ansicht der Daten. Programmierung so wird mithilfe eines Algorithmus "Sperre-frei" genannt.

Das Problem mit Sperre-freie Algorithmen kommt, wenn Sie nicht die genaue Reihenfolge kennen, in der der Code ausgeführt wird. Moderne Prozessoren neu anordnen, Anweisungen, damit der Prozessor kann Fortschritte bei jedem Taktzyklus und schreibt in den Speicher zu kombinieren, um Wartezeiten zu verringern. Obwohl fast jeder Prozessor diese Optimierungen durchführt, gibt es ein Unterschied, wie die Reihenfolge der Lese- und Schreibvorgänge auf das Programm vorgelegt wird. x 86-basierte Prozessoren-Garantie, die der Prozessor aussehen wird, wie es die meisten Lesevorgänge ausführt und in der gleichen Reihenfolge schreibt, das Programm ihnen gibt. Diese Garantie wird eine starke Speicher Modell oder starke Schreibreihenfolge genannt. ARM-Prozessoren machen nicht so viele Garantien — sie sind in der Regel frei Operationen bewegen, solange dabei nicht also ändert die Art und Weise der Code würde in einem Singlethread-Programm ausgeführt. Der ARM-Prozessor macht einige Garantien, die sorgfältig aufgebaute Sperre-freien Code erlauben, aber es hat, was ein schwacher Speichermodell genannt hat.

Interessanterweise hat das .net Framework CLR selbst ein schwacher Speichermodell. Alle Verweise auf Bestellung in der Spezifikation ECMA Common Language Infrastructure (CLI) zu schreiben (verfügbar als PDF auf bit.ly/1Hv1xw), der Standard, die die CLR ist konzipiert gerecht zu werden, beziehen sich auf flüchtige Zugriffe. In c# bedeutet dies Zugriffe auf Variablen mit dem volatile-Schlüsselwort (siehe Abschnitt 12.6 die CLI-Spezifikation als Referenz) gekennzeichnet. Aber in den letzten zehn Jahren die meisten verwalteter Code ausgeführt wurde auf X 86 Systeme und der CLR just-in-Time (JIT) Compiler hat nicht viel zu der Reorderings erlaubt durch die Hardware, so gab es relativ wenige Fälle wo das Speichermodell latent Parallelitätsfehler offenbaren würde hinzugefügt. Dies könnte ein Problem darstellen, wenn von verwaltetem Code für geschrieben und getestete nur auf x 86-basierten Computern wird erwartet, dass die gleiche Weise auf ARM-Systemen arbeiten.

Die meisten der Muster, die erfordern zusätzliche Vorsicht hinsichtlich der Neuordnung sind selten in verwaltetem Code. Aber einige dieser Muster, die existieren, sind trügerisch einfach. Hier ist ein Beispiel für Code, die nicht aussehen wie einen Bug hat, aber wenn diese Statik in einem anderen Thread geändert werden, kann dieser Code auf einem Computer mit einer schwachen Speichermodell brechen:

static bool isInitialized = false;
static SomeValueType myValue;
if (!isInitialized)
{
  myValue = new SomeValueType();
  isInitialized = true;
}
myValue.DoSomething();

Damit dieser Code korrekt einfach geben Sie an, dass die Flagge IsInitialized flüchtig ist:

static volatile bool isInitialized = false; // Properly marked as volatile

Ausführung dieses Codes ohne Neuordnung zeigt sich an der linken Block in Abbildung 1. Thread 0 ist das erste SomeValueType auf ihrer lokalen Stapel initialisiert werden und die lokal erstellte SomeValueType an einer AppDomain globalen Speicherort kopiert. Thread 1 bestimmt durch Überprüfen der IsInitialized, die es auch braucht, um SomeValueType zu erstellen. Aber es gibt kein Problem, da die Daten zurück an den gleichen AppDomain globalen Speicherort geschrieben werden. (In den meisten Fällen sind wie in diesem Beispiel alle Mutationen, die von der Methode DoSomething Idempotent.)

Abbildung 1 schreiben Neuordnung

Der rechten Block zeigt Ausführung desselben Codes mit einem System, die Neuordnen schreiben (und ein bequem platzierte Stall in der Ausführung) unterstützt. Dieser Code nicht ordnungsgemäß ausgeführt, da Thread 1 bestimmt durch das Lesen der IsInitialized-Wert, die SomeValueType nicht initialisiert werden. Der Aufruf von DoSomething verweist auf Speicher, die noch nicht initialisiert wurde. Lesen von ValueType-einige Daten werden von der CLR auf 0 festgelegt wurden.

Der Code wird nicht durch diese Art der Neuordnung oft falsch ausgeführt, aber es passiert. Diese Reorderings sind völlig legal — die Reihenfolge der Writes spielt keine Rolle, wenn in einem einzigen Thread ausgeführt. Es empfiehlt sich, beim Schreiben von gleichzeitigen Code um flüchtige Variablen korrekt mit dem volatile-Schlüsselwort zu markieren.

Die CLR ist erlaubt, verfügbar zu machen als die ECMA CLI-Spezifikation erfordert eine stärkere Speichermodell. Auf X 86 ist beispielsweise das Speichermodell der CLR stark weil der Prozessor-Speichermodell stark. Das .net-Team konnte das Speichermodell am ARM so stark wie das Modell auf X 86 habe, aber gewährleisten die perfekte Bestellung möglichst bemerkenswerte Auswirkungen auf Leistung für die Ausführung von Code haben kann. Wir haben getan, zielgerichtete Arbeit um das Speichermodell am ARM zu stärken — insbesondere wir eingefügt haben Speicher Barrieren an wesentlichen Punkten beim Schreiben auf dem verwalteten Heap Typsicherheit gewährleisten — aber wir haben Sie sicher, dass dies nur mit einem minimalen Auswirkungen auf die Leistung zu tun. Das Team ging durch mehrere Konstruktionsprüfungen mit Experten, um sicherzustellen, dass die Techniken angewendet in der ARM-CLR korrekt waren. Außerdem zeigen Performance-Benchmarks, dass .net Code Ausführung Leistung Skalen identisch mit systemeigenen C++-Code auf X 86, X 64 und ARM im Vergleich.

Wenn Ihr Code Sperre-freie Algorithmen benötigt, die abhängig von der Implementierung der X 86 CLR (statt der CLR ECMA-Spezifikation), Sie werde das volatile-Schlüsselwort relevanten Variablen nach Bedarf hinzufügen möchten. Sobald Sie gemeinsam genutzten Zustand als flüchtig markiert haben, wird die CLR alles für Sie kümmern. Wenn Sie wie die meisten Entwickler sind, können Sie am ARM ausgeführt werden, da Sie bereits Sperren zum Schutz Ihrer freigegebenen Daten verwendet, richtig flüchtige Variablen gekennzeichnet und Ihre Anwendung auf ARM getestet.

Daten Ausrichtung Anforderungen ein weiterer Unterschied, der einige Programme beeinflussen könnte ist, dass die ARM-Prozessoren benötigen einige Daten ausgerichtet werden. Das spezifische Muster in dem Ausrichtung Anforderungen anwenden ist, wenn Sie einen 64-Bit-Wert (das heißt, int64, uint64 oder Double) haben, der an einer 64-Bit-Grenze ausgerichtet ist nicht. Die CLR übernimmt die Ausrichtung für Sie, aber es gibt zwei Möglichkeiten, einen nichtlinearen Datentyp erzwingen. Die erste Möglichkeit ist explizit angeben, das Layout einer Struktur mit dem benutzerdefinierten Attribut [ExplicitLayout]. Die zweite Möglichkeit ist das Layout einer Struktur zwischen verwaltetem und systemeigenem Code falsch angeben.

Bemerken Sie einen P/Invoke-Aufruf mit Müll zurückkommen, sollten Sie einen Blick auf alle Strukturen gemarshallt. Als Beispiel haben wir Bug behoben, beim Portieren von einigen .net-Bibliotheken in denen COM-Schnittstelle übergeben eine POINTL Struktur mit zwei 32-Bit-Feldern auf eine Funktion in verwaltetem Code, der eine 64-Bit als Parameter doppelte nahm. Die Funktion verwendet Bit-Operationen, um die zwei 32-Bit-Felder zu erhalten. Hier ist eine vereinfachte Version der fehlerhaften Funktion:

void CalledFromNative(int parameter, long point)
{
  // Unpack native POINTL from long point
  int x = (int)(point & 0xFFFFFFFF);
  int y = (int)((point >> 32) & 0xFFFFFFFF);
  ...  // Do something with POINTL here
}

Der systemeigene Code haben nicht die POINTL-Struktur auf einer 64-Bit-Grenze ausgerichtet, da es zwei 32-Bit-Felder enthalten. Aber ARM erfordert die 64-Bit-Double ausgerichtet werden, wenn es in die verwaltete Funktion übergeben wird. Machen sicher, dass die Typen angegeben werden ist dieselben auf beiden Seiten des Aufrufs verwaltete, systemeigene wichtig, wenn Ihre Ausrichtung erfordern.

In Visual Studio die meisten bemerken Entwickler jemals die Unterschiede nicht, die ich da .net Code von Design ist nicht spezifisch für jede Prozessorarchitektur besprochen habe. Aber es gibt einige Unterschiede in Visual Studio beim profiling oder Debuggen von Windows 8 apps auf einem ARM-Gerät, da Visual Studio nicht auf ARM-Geräten ausgeführt wird.

Sie sind bereits vertraut mit dem Cross-Plattform-Entwicklung, wenn Sie apps für Windows Phone schreiben. Visual Studio auf Ihrem X 86 Dev Box und Sie Ihre app Remote auf das Gerät oder einen Emulator starten. Die app nutzt einen Proxy installiert auf Ihrem Gerät mit Ihrem Entwicklungscomputer über eine IP-Verbindung kommunizieren. Verhalten als die Ersteinrichtung sich Schritte, das Debuggen und Profilerstellung von Erfahrungen auf allen Prozessoren.

Ein weiterer Punkt zu beachten ist, dass die Visual Studio-Projekteinstellungen ARM X 86 und X 64 als Zielprozessor Wahl hinzufügen. Sie werden normalerweise AnyCPU Wenn Sie eine .net-app für Windows am ARM schreiben, und Ihre app nur auf allen Windows-8-Architekturen läuft als Ziel wählen.

Geht tief in die Unterstützung von ARM

Gemacht es dies bis weit in den Artikel, wissen Sie bereits einiges über ARM. Nun möchte ich einige interessante, tiefgehende technische Details über die .net Arbeit des Teams zur Unterstützung von ARM zu teilen. Sie müssen nicht um diese Art von Arbeit im .net Code — Dies ist nur einen schnellen Blick hinter die Kulissen Blick auf die Art der Arbeit, die wir haben.

Die meisten Änderungen innerhalb der CLR selbst waren einfach, weil die CLR entwickelt wurde, um Architekturen portabel sein. Wir haben ein paar Änderungen auf die ARM Application Binary Interface (ABI) entsprechen. Wir hatten auch Assembler-Code in der CLR zum Ziel ARM umschreiben und ändern unsere JIT-Compiler um 2-ARM-Thumb-Anweisungen auszugeben.

ABI gibt an, das wie ein Prozessor programmierbare Schnittstelle. Es ist vergleichbar mit der API, die die was ein OS programmgesteuert verfügbaren Funktionen gibt. Die drei Bereiche des ABI, die unsere Arbeit betroffen sind die Funktion Aufrufkonvention, die Register-Konventionen und Aufrufliste Entladeinformationen. Ich werde jeden Abschnitt erläutern.

Aufrufkonvention A-Aufrufkonvention Funktion ist eine Vereinbarung zwischen Code, der eine Funktion aufruft und die aufgerufene Funktion. Das Übereinkommen gibt an, wie Parameter und Rückgabewerte im Speicher angeordnet sind sowie was Register ihre Werte über den Anruf erhalten haben müssen. In Reihenfolge für die Funktion benötigen Aufrufe, um über die Grenzen hinweg (z. B. einen Anruf von einem Programm in das OS), Codegeneratoren arbeiten Funktionsaufrufe zu generieren, die die Konvention, die der Prozessor definiert entsprechen, einschließlich Ausrichtung der 64-Bit-Werte.

ARM musste der erste 32-Bit-Prozessor die CLR ausrichten Parameter und Objekte auf dem verwalteten Heap an einer 64-Bit-Grenze zu behandeln. Die einfachste Lösung wäre, alle Parameter ausrichten, aber die ABI erfordert, dass ein Code-Generator nicht verlassen Blasen im Stapel, wenn keine Ausrichtung erforderlich ist, so gibt es keine Performance-Einbußen. Die einfache Bedienung des Drucks einer Reihe von Parametern auf dem Stapel wird somit empfindlicher auf dem ARM-Prozessor. Da eine Benutzer Struktur int64 enthalten kann, war der CLR Lösung mit etwas für jeden Typ angegeben wenn Ausrichtung erforderlich ist. Dies gibt der CLR genügend Informationen, um sicherzustellen, dass die Funktionsaufrufe, die 64-Bit-Werte nicht versehentlich beschädigt die Aufrufliste.

Register Convention Daten-Pack() überträgt sich wann Strukturen ganz oder teilweise auf ARM registriert sind. Also, die mussten wir ändern den Code innerhalb der CLR, die häufig, verwendet Daten aus dem Speicher in Registern um sicherzustellen, dass die Daten ordnungsgemäß in den Registern ausgerichtet werden. Diese Arbeit hatte bei zwei Situationen durchgeführt werden: Erstens machen sicher, dass 64-Bit-Werte in den Registern selbst starten, und zweiter, homogene Gleitkomma-Aggregate (HFAs) in den entsprechenden Registern platzieren.

Wenn ein Code-Generator int64 auf ARM registriert, muss es in eine gerade-ungerade-paar gespeichert werden – d. h. R0-R1- oder R2-R3. Das Protokoll für HFAs können bis zu vier Doppel- oder Gleitkommawerte in einer homogenen Struktur. Wenn diese registriert sind, müssen sie im (einzigen) S gespeichert werden oder D (Doppel-) registrieren legt, aber nicht in die universelle r registriert.

Informationen zu entspannen Entladeinformationen zeichnet die Effekte, die ein Funktionsaufruf hat auf dem Stapel und Datensätze wo nicht flüchtig registriert über Funktionsaufrufe gespeichert werden. FS: 0 eine verknüpfte Liste von jeder Funktion Registrierung Ausnahmeinformationen im Falle einer nicht behandelten Ausnahme anzeigen auf X 86 betrachtet Windows. 64-Bit-Windows wurde das Konzept der Entladeinformationen, das Windows den Stapel im Falle einer nicht behandelten Ausnahme Crawlen ermöglicht. Das ARM-Design erweitert dies Entladeinformationen aus 64-Bit-Designs. Die CLR-Code-Generatoren, wiederum hatte zu ändern, um Platz für das neue Design.

Versammlung Code, obwohl die meisten von der CLR-Runtime-Engine ist in C++ geschrieben, wir haben Assembler-Code, die zu jedem neuen Prozessor portiert werden muss. Die meisten dieser Assembler-Code ist, nennen wir "Stub-Funktionen", oder "Stubs." Gestorben dienen als Schnittstelle Bindeglied, das uns ermöglicht, die C++ und JIT-Kompilierung Teile der Runtime zusammenbinden. Der Rest der Assembler-Code in der CLR ist in Assembly für Leistung geschrieben. Beispielsweise muss der Garbage Collector-Schreibbarriere extrem schnell sein, da sie häufig aufgerufen wird — jederzeit ein Objektverweis auf ein Objekt auf dem verwalteten Heap geschrieben ist.

Ein Beispiel für ein Stub ist nennen wir den "Shuffle Thunk." Wir nennen es einen Shuffle Thunk, weil es über Register Parameterwerte mischt. Manchmal hat die CLR zum Ändern der Position von Parametern in Registern, kurz bevor eine Funktion aufgerufen wird. Die CLR verwendet den Shuffle Thunk, um dies zu tun, wenn Sie Delegaten aufrufen.

Wenn Sie einen Delegaten aufrufen, stellen Sie im Prinzip nur einen Aufruf der Invoke-Methode. In Wirklichkeit macht die CLR einen indirekten Aufruf durch ein Feld von Delegaten, anstatt eine benannte Methode aufrufen (außer wenn Sie explizit Invoke durch Reflektion aufrufen). Diese Methode ist wesentlich schneller als das benannte Methode aufrufen weil die Laufzeit einfach die Instanz des Delegaten (gewonnen von der Ziel-Zeiger) für den Delegaten im Funktionsaufruf tauschen kann. Das heißt, wird der Aufruf der d.Member-Methode für eine Instanz Foo der Delegat d, die Foo zugeordnet.Membermethode.

Wenn Sie bilden eine geschlossene Instanz Aufruf, Delegieren der this-Zeiger wird innerhalb des ersten Registers verwendet für die Übergabe von Parametern, R0, und der erste Parameter ist im nächsten Register R1 gespeichert. Aber dies funktioniert nur, wenn Sie einen Delegaten mit einer Instanzmethode gebunden haben. Was passiert, wenn Sie eine offene statische Delegaten aufrufen? In diesem Fall Sie erwarten, dass der erste Parameter in R0 gespeichert ist (da es keine diese gibt Zeiger.) Der Shuffle Thunk zieht den ersten Parameter von R1 in R0, der zweite Parameter in R0 und so weiter, wie im Abbildung 2. Da diese Shuffle Thunk dient um Werte von Register, Register zu verschieben, muss er speziell für jeden Prozessor umgeschrieben werden.

Abbildung 2 "Shuffle Thunk" mischt Werteparameter über Register

Nur auf den Code konzentrieren

Um zu überprüfen, wurde die Portierung der .net Framework zum ARM ein interessantes Projekt und eine Menge Spaß für das .net-Team. Und Schreiben von .net apps auf dem .net Framework auf ARM laufen soll Spaß machen, für Sie als Entwickler .net. .NET Code möglicherweise anders auf ARM ausgeführt, als auf X 86-basierte Prozessoren in wenigen Situationen, aber die virtuelle Ausführungsumgebung .net Framework abstrahiert diese Unterschiede normalerweise für Sie. Das bedeutet, Sie nicht befürchten, was Prozessorarchitektur Ihrer .net-app müssen, läuft auf. Sie können nur auf große Code schreiben konzentrieren.

Ich glaube, dass mit Windows 8 verfügbar auf ARM für Entwickler und Endbenutzer groß sein wird. ARM-Prozessoren sind besonders geeignet für lange Lebensdauer der Batterie, so dass sie leichte, tragbare, immer verbundenen Geräten ermöglichen. Die wichtigsten Fragen, die Sie sehen werden, wenn Ihre app ARM portieren sind Leistungsunterschiede von desktop-Prozessoren. Aber achten Sie darauf, Ihren Code auf ARM ausführen, bevor tatsächlich sagen, es auf ARM funktioniert — Vertrauen Sie nicht auf X 86 Entwicklung reicht. Für die meisten Entwickler das ist alles, die was nötig ist. Und wenn Sie in Probleme laufen, finden Sie zurück zu diesem Artikel einen Einblick wo beginnen Untersuchung bekommen.

Andrew Pardoe ist Programmmanager für das CLR-Team, helfen, um das Microsoft .net Framework auf allen Arten von Prozessoren zu versenden. Sein persönliche Favorit bleibt der Itanium. Er kann erreicht werden unter Andrew.Pardoe@microsoft.com.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Brandon Bray, Layla Driscoll, Eric Eilebrecht und Rudi Martin