Entwicklung und Optimierung von Android*-Anwendungen auf der Intel® Atom™ Plattform

Kurzfassung

Dieser Artikel präsentiert detaillierte Methoden für die Entwicklung und Portierung einer Android*-Anwendung auf die Intel® Atom™ Plattform und behandelt bewährte Verfahren zur Entwicklung von Anwendungen mit dem Android Native Development Kit (NDK) sowie zur Leistungsoptimierung. Android-Entwicklern dient dieses Dokument als Referenz für die Entwicklung hochwertiger Anwendungen, die auf die Intel® Architektur ausgelegt sind.

1. Klassifizierung von Android*-Anwendungen

Android-Anwendungen lassen sich nach zwei Typen klassifizieren (siehe Abb. 1).

• Dalvik-Anwendungen, die Java*-Code enthalten und ausschließlich die offizielle Android-SDK-API und die erforderlichen Ressourcendateien (wie xml und png) – kompiliert in einer APK-Datei – verwenden.
• Android-NDK-Anwendungen, die Java-Code und Ressourcendateien sowie C/C++-Quellcode und teilweise Assemblycode enthalten. Der gesamte native Code wird in eine Dynamic Link Library (.so-Datei) kompiliert und anschließend über einen JNI-Mechanismus von Java im Hauptprogramm aufgerufen.

Abb. 1: Zwei Typen von Android*-Anwendungen

2. Android Native Development Kit

2.1 Einleitung

Das Android Native Development Kit (NDK) ist ein ergänzendes Tool zum Android SDK. Mehrere Faktoren machen es zu einem äußerst nützlichen Tool für die Entwicklung von Android-Anwendungen:

• Es erstellt leistungskritische Teile Ihrer Anwendungen in nativem Code. Bei der Verwendung von Java-Code muss der Java-basierte Quellcode mithilfe einer virtuellen Maschine in eine Maschinensprache interpretiert werden. Der native Code wird hingegen direkt vor der Ausführung in eine Binärdatei kompiliert und optimiert. Wird nativer Code korrekt eingesetzt, so können Sie Ihre Anwendung mit leistungsstarkem Code ausstatten, etwa Hardware-Videocodierung und -decodierung, Grafikverarbeitung und arithmetische Operationen.
• Nativer Legacycode wird wiederverwendet. C/C++-Code kann in eine Dynamic Link Library kompiliert werden, die sich anschließend über einen JNI-Mechanismus von Java aufrufen lässt.

2.2 Tool-Übersicht

Während der Entwicklungsphase können Sie mit dem Intel® Hardware Accelerated Execution Manager (HAXM) die Leistung des Android-Simulators verbessern. Der HAXM ist eine hardwaregestützte Virtualisierungsengine (Hypervisor), die die Intel® Virtualisierungstechnik (Intel® VT) nutzt, um die Emulation von Android-Anwendungen auf einem Hostcomputer zu beschleunigen. In Kombination mit Android-x86-Emulator-Abbildern, die Intel bereitstellt, und dem offiziellen Android SDK Manager ermöglicht der HAXM eine schnellere Android-Emulation auf Systemen, die für die Intel VT geeignet sind. Weitere Informationen zum HAXM finden Sie unter http://software.intel.com/de-de/articles/intel-hardware-accelerated-execution-manager (EN).

2.3 Installation des HAXM

Der HAXM lässt sich über den Android SDK Manager (empfohlene Methode) oder manuell installieren. Intel stellt das Installationsprogramm auf seiner Website zum Download bereit. Wenn Sie automatische Updates wünschen, verwenden Sie zur Installation bitte den Android SDK Manager (siehe Abb. 2). ^[1]

Abb. 2: Installation des Intel® HAXM über den Android SDK Manager

Sie können das entsprechende Installationspaket auch von http://software.intel.com/de-de/android auf Ihre Host-Plattform herunterladen und für die Installation die schrittweise Anleitung befolgen.

2.3.1 Einrichten des HAXM

Das von Intel bereitgestellte Android-x86-Systemabbild ist zur Ausführung des HAXM erforderlich. Sie können das Systemabbild über den Android SDK Manager oder manuell von der Intel® Developer Zone Website herunterladen.

Nach der erfolgreichen Abbildinstallation werden Intel® x86-Android-Emulator-Abbilder automatisch über die im Lieferumfang des Android SDK enthaltene Binary„emulator-x86“ ausgeführt. Der Android-Emulator wird durch die Intel VT beschleunigt, wodurch Sie beim Entwicklungsprozess Zeit sparen.

3. Entwicklung und Portierung von NDK-Anwendungen für die Intel® Atom™ Architektur

3.1 Entwicklung von NDK-Anwendungen für Geräte mit Intel® Atom™ Prozessoren

Nehmen Sie sich nach der Installation des NDK einige Minuten Zeit und lesen Sie die Dokumente im Verzeichnis <ndk>/docs/ (insbesondere OVERVIEW.html und CPU-X86.html), damit Sie den NDK-Mechanismus und seinen Gebrauch verstehen.

Die Entwicklung von Anwendungen mit dem NDK lässt sich in fünf Schritte aufschlüsseln (siehe Abb. 3):

Abb. 3: Entwicklung von Anwendungen mit dem NDK

Die Demo hello-jni veranschaulicht diese fünf Schritte. Sie finden diese Demo im NDK-Ordner Stammverzeichnis\samples\hello-jni [5]. Die Demo hello-jni ist eine einfache Anwendung, die im NDK enthalten ist. Sie holt einen String aus einer nativen Methode in einer freigegebenen Bibliothek und verwendet ihn in der Anwendungs-UI.

3.1.1. Erstellen von nativem Code

Erstellen Sie ein neues Android-Projekt und legen Sie Ihren nativen Quellcode unter <projekt>/jni/ ab. Der Projektinhalt ist in Abb. 4 zu sehen. Diese Demo enthält eine einfache Funktion in nativem Code mit der Bezeichnung Java_com_example_hellojni_HelloJni_stringFromJNI(). Wie im Quellcode gezeigt, wird ein einfacher String aus JNI zurückgegeben.

Abb. 4: Erstellen von nativem Code

3.1.2 Erstellen des MakeFile „Android.mk“

NDK-Anwendungen werden standardmäßig für die ARM-Plattform erstellt. Um NDK-Anwendungen für die Intel® Atom™ Plattform zu erstellen, müssen Sie APP_ABI := x86 zum MakeFile hinzufügen.

Abb. 5: Erstellen des MakeFile

3.1.3. Kompilieren von nativem Code

Führen Sie zum Erstellen von nativem Code das Skript „ndk-build“ im Projektverzeichnis aus. Es befindet sich auf der obersten Ebene im NDK-Verzeichnis. Das Ergebnis sehen Sie in Abb. 6.

Abb. 6: Kompilierter nativer Code

Die Build-Tools kopieren die entfernten freigegebenen Bibliotheken automatisch an die richtige Stelle im Projektverzeichnis der Anwendung.

3.1.4 Aufrufen von nativem Code aus Java

Wenn die freigegebene Bibliothek erfolgreich bereitgestellt wurde, können Sie die Funktion von Java aus aufrufen. Den Code sehen Sie in Abb. 7. Ein öffentlicher nativer Funktionsaufruf stringFromJNI() wird in Java-Code erstellt, und diese Funktion lädt die freigegebene Bibliothek mit System.loadlibrary().

Abb. 7: Aufrufen von nativem Code aus Java*

3.1.5 Debugging mittels GDB

Wenn Sie den GDB für das Debugging der NDK-Anwendung verwenden möchten, müssen die folgenden Bedingungen erfüllt sein:

• Die NDK-Anwendung wird mit „ndk-build“ erstellt.
• Die NDK-Anwendung ist in Android.manifest auf „debuggable“ festgelegt.
• Die NDK-Anwendung wird unter Android 2.2 (oder höher) ausgeführt.
• Es wird nur ein Ziel ausgeführt.
• Das Verzeichnis der ADB wird zu PATH hinzugefügt.

Verwenden Sie den Befehl „ndk-gdb“ für das Debugging der Anwendung. Sie können entweder einen Breakpoint setzen oder den Code schrittweise debuggen, um den Änderungsverlauf eines Variablenwerts zu verfolgen (siehe Abb. 8).

Abb. 8: Debugging einer NDK-Anwendung mittels GDB

3.2 Portierung bestehender NDK-Anwendungen auf Geräte mit Intel® Atom™ Prozessoren

Dieser Abschnitt basiert auf der Annahme, dass Sie eine Android-Anwendung für die ARM-Plattform haben und diese portieren müssen, um sie anschließend auf der Intel® Atom™ Plattform bereitzustellen.

Die Portierung von Android-Anwendungen auf die Intel Atom Plattform gleicht dem Entwicklungsprozess. Die Schritte sehen Sie in Abb. 9.

Abb. 9: Portierung von Android*-Anwendungen auf die Intel® Atom™ Plattform

3.2.1 Portierung von Dalvik-Anwendungen

Dalvik-Anwendungen können direkt auf Geräten mit Intel® Atom™ Prozessoren ausgeführt werden. Die Benutzeroberfläche muss für das Zielgerät angepasst werden. Bei hochauflösenden Geräten – beispielsweise Tablets mit mindestens 1280x800 – erfüllt die Standardspeicherzuweisung möglicherweise nicht die Anforderungen der Anwendung, was den Start der Anwendung verhindert. Daher sollte für hochauflösende Geräten die Standardspeicherzuweisung erhöht werden.

3.2.2 Portierung von Android*-NDK-Anwendungen

Die Portierung von NDK-Anwendungen ist etwas komplizierter als die Portierung von Dalvik-Anwendungen. Alle NDK-Anwendungen lassen sich basierend auf den folgenden Eigenschaften des nativen Codes in drei Typen unterteilen:

• Besteht ausschließlich aus C/C++-Code ohne Hardware-Bezug
• Verwendet eine Dynamic Link Library eines Drittanbieters
• Enthält Assembly-Code mit starkem Bezug zu einer Plattformen ohne IA

Nativer Code, der aus C/C++-Code ohne Hardware-Bezug besteht

1. Kompilieren Sie den nativen Code neu, um die Anwendung erfolgreich auf der Intel Atom Plattform auszuführen.
2. Öffnen Sie das NDK-Projekt und suchen Sie nach der Datei Android.mk. Fügen Sie APP_ABI := armeabi armeabi-v7a x86 zu Android.mk hinzu und erstellen Sie den nativen Code mit ndk-build neu.
3. Wenn Sie die Datei Android.mk nicht finden, verwenden Sie den Befehl ndk-build APP_ABI="armeabi armeabi-v7a x86" zum Erstellen des Projekts.
4. Paketieren Sie die Anwendung erneut mit unterstützten x86-Plattformen.

Falls nativer Code eine Dynamic Link Library eines Drittanbieters verwendet, muss die freigegebene Bibliothek in die x86-Version für die Intel Atom Plattform neu kompiliert werden.

Falls nativer Code Assembly-Code mit starkem Bezug zu Plattformen ohne IA enthält, muss der Code mit IA Assembly oder C/C++ neu geschrieben werden.

4. Bewährte Verfahren zur Entwicklung von nativem Code

4.1 Erzwungene Speicherausrichtung

Aufgrund von Unterschieden zwischen Architekturen, Plattformen und Compilern kann ein und dieselbe Datenstruktur auf verschiedenen Plattformen unterschiedlich groß sein. Ohne erzwungene Speicherausrichtung kann es aufgrund uneinheitlicher Datengrößen zu Ladefehlern kommen. ^[2]

Das folgende Beispiel veranschaulicht Datengrößen der gleichen Datenstruktur auf unterschiedlichen Plattformen:

struct TestStruct {
int mVar1;
long long mVar2;
int mVar3;
};

Dies ist eine einfache Struktur mit den drei Variablen mVar1, mVar2 und mVar3.

mVar1 ist vom Typ „int“ und beansprucht 4 Byte.
mVar2 ist vom Typ „long long int“ und beansprucht 8 Byte.
mVar3 ist ebenfalls vom Typ „int“ und beansprucht 4 Byte.

Wie viel Platz wird auf den ARM- und Intel Atom Plattformen benötigt?

Die Größe der für ARM- und Intel Atom Plattformen mit einem standardmäßigen Compiler-Switch kompilierten Daten sehen Sie in Abb. 10. ARM wendet automatisch „double malign“ an und beansprucht 24 Byte, während x86 16 Byte beansprucht.

Abb. 10: Speicherzuweisung mit standardmäßigen Compiler-Flags

Die 8 Byte große mVar2 (64 Bit) führt zu einem anderen Layout für TestStruct, da ARM für 64-Bit-Variablen wie mVar2 eine 8-Byte-Ausrichtung erfordert. In den meisten Fällen verursacht dies keine Probleme, da die Erstellung für x86 im Unterschied zu ARM einen kompletten Rebuild erfordert.

Allerdings kann eine Größendiskrepanz auftreten, falls eine Anwendung Klassen oder Strukturen serialisiert. Beispiel: Sie erstellen eine Datei in einer ARM-Anwendung, und diese schreibt TestStruct in eine Datei. Wenn Sie die Daten aus dieser Datei später auf einer x86-Plattform laden, stimmen die Klassengrößen in der Anwendung und in der Datei nicht überein. Ähnliche Probleme mit der Speicherausrichtung können auftreten, wenn der Datenverkehr im Netzwerk ein bestimmtes Speicherlayout erwartet.

Die GCC-Compiler-Option „-malign-double“ erzeugt die gleiche Speicherausrichtung auf x86 und auf ARM.

Abb. 11: Speicherzuweisung nach Hinzufügen von -malign-double-Flags

4.2 Portierung von NEON*-Befehlen auf SSE ^[3]

4.2.1 NEON

Die ARM-NEON*-Technik kommt hauptsächlich im Multimediabereich zum Einsatz, beispielsweise bei Smartphones und HDTV-Anwendungen. Laut ARM-Dokumentation bietet diese Technik, die auf einer 128-Bit-SIMD-Engine – einer Erweiterung der ARM Cortex*–A-Serie – basiert, mindestens die dreifache Leistung gegenüber der ARM-v5-Architektur und mindestens die doppelte Leistung gegenüber dem Nachfolger ARM v6. Weitere Informationen zur NEON-Technik finden Sie unter: http://www.arm.com/products/processors/technologies/neon.php.

4.2.2 SSE: Die äquivalente Technik von Intel

SSE ist die Streaming SIMD Extension für die Intel® Architektur (IA). Der Intel® Atom™ Prozessor unterstützt derzeit SSSE3 (Supplemental Streaming SIMD Extensions 3) und frühere Versionen, jedoch noch nicht SSE4.x. SSE ist eine 128-Bit-Engine für die Paketierung von Fließkommadaten. Das Ausführungsmodell baute ursprünglich auf der MMX-Technik auf, und SSx ist im Wesentlichen die neuere Generation, die MMX überflüssig macht. Weitere Informationen finden Sie in „Volume 1: Basic Architecture“ der Handbücher für Software-Entwickler für die Intel 64- und IA-32-Architektur. Die SSE-Übersicht in Abschnitt 5.5 enthält die Befehle für SSE, SSE2, SSE3 und SSSE3. Diese Datenoperationen verschieben paketierte, präzisionsbasierte Fließkommawerte zwischen XMM-Registern oder zwischen XMM-Registern und dem Arbeitsspeicher. XMM-Register sollen als Ersatz für MMX-Register eingesetzt werden.

4.2.3 NEON zu SSE auf Assembly-Stufe

Verwenden Sie das IA-Handbuch für Software-Entwickler als Nachschlagewerk für alle mnemonischen SSE(x)-Einzelcodes. Schauen Sie sich aber auch die verschiedenen SSE-Befehle auf Assembly-Ebene an unter: http://neilkemp.us/src/sse_tutorial/sse_tutorial.html. Über das Inhaltsverzeichnis finden Sie Code-Beispiele und Hintergrundinformationen.

In gleicher Weise finden Sie im folgenden Handbuch von ARM Informationen zu NEON und kleine Assembly-Codeausschnitte unter 1.4, „Developing for NEON“: http://infocenter.arm.com/help/topic/com.arm.doc.dht0002a/DHT0002A_introducing_neon.pdf.

Wichtigste Unterschiede zwischen NEON und SSE-Assembly-Code:

• Endian-Verhalten. Intel unterstützt ausschließlich Little-Endian-Assembly, wogegen ARM sowohl die Big- wie auch die Litte-Endian-Reihenfolge unterstützt. In dem gezeigten Code-Beispiel weist der ARM-Code das Little-Endian-Format auf, ähnlich wie bei Intel. Hinweis: Möglicherweise bestehen Auswirkungen auf ARM-Compiler. Bei der Kompilierung für ARM mit GCC werden beispielsweise die Flags –mlittle-endian und –mbig-endian verwendet. Weitere Informationen finden Sie unter http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html.
• Granularität. Vergleichen Sie im Fall der gezeigten einfachen Assembly-Code-Beispiele die ADDPS-Befehle für SSE (Intel) mit VADD.ix für NEON, wie x = 8 oder 16. Sie sehen, dass Letzteres eine bestimmte Granularität der als Teil der referenzierten Mnemonik zu verarbeitenden Daten mit sich bringt.

Hinweis: Die Liste der Unterschiede ist nicht vollständig. Weitere Unterschiede zwischen NEON und SSE können vorhanden sein.

4.2.4 NEON zu SSE auf C/C++-Ebene

Bei der Portierung von C/C++- und NEON-Code zu SSE können zahlreiche störende API-Faktoren auftreten. Bedenken Sie, dass wir davon ausgehen, dass echter C/C++-Code verwendet wird und kein Inline-Assembly. NEON-Befehle bieten auch einige native C-Bibliotheken. Diese Befehle sind zwar C-Code, lassen sich aber auf der Intel Atom Plattform nicht ausführen und müssen neu geschrieben werden.

5. Leistungsoptimierung der Anwendung

5.1 Leistungstuning

Während der Code-Entwicklung können Sie die folgenden Methoden einsetzen, um die Leistung Ihrer Anwendung auf der Intel Atom Plattform zu verbessern.

5.1.1 Inline- anstatt häufig verwendeter Kurzfunktionen einsetzen

Inline-Funktionen eignen sich am besten für kleine Funktionen, wie den Zugriff auf private Datenelemente. Kurze Funktionen reagieren empfindlich auf den Overhead bei Funktionsaufrufen. Längere Funktionen verweilen proportional kürzer in der Aufruf-/Rückgabesequenz und profitieren weniger von der Inline-Methode. ^[4]

Die Inline-Funktion spart Overhead bei:

• Funktionsaufrufen (einschließlich Parameterübergabe und Platzierung der Objektadresse im Stack)
• Beibehaltung des Stack-Frames der aufrufenden Funktion
• Neuem Stack-Frame-Setup
• Kommunikation von Rückgabewerten
• Wiederherstellung des alten Stack-Frames
• Rückgabe

5.1.2 Float anstatt Double verwenden

FPU steht für eine Fließkommaeinheit, die Teil eines Computersystems und speziell auf Operationen an Fließkommazahlen ausgelegt ist, beispielsweise Addition, Subtraktion, Multiplikation, Division und Quadratwurzel. Einige Systeme (insbesondere ältere, Mikrocode-basierte Architekturen) können zudem verschiedene transzendente Funktionen wie exponentielle oder trigonometrische Berechnungen durchführen. Aktuelle Prozessoren verwenden für diese Berechnungen Softwarebibliothekroutinen. Bei den meisten modernen, auf allgemeine Zwecke ausgelegten Computerarchitekturen sind eine oder mehrere FPUs in der CPU integriert ^[6].

FPU ist auf der Intel Atom Plattform aktiviert. In den meisten Fällen kann durch Verwendung von Float anstatt Double der Rechenprozess beschleunigt und Speicherbandbreite bei Geräten mit Intel Atom Prozessoren gespart werden.

5.1.3 Multithread-Codierung

Mithilfe der Multithread-Codierung können Sie die Hyperthreading-Funktion des Intel Atom Prozessors nutzen und so den Durchsatz und die Gesamtleistung verbessern. Weitere Informationen zum Thema Multithreading finden Sie unter: http://www.intel.de/content/www/de/de/architecture-and-technology/hyper-threading/hyper-threading-technology.html.

5.2 Erstellen leistungsstarker Anwendungen mit Compiler-Flags

Wie Sie wissen, wird nativer Code von GCC in Android-Anwendungen erstellt. Aber kennen Sie auch das Standardziel von GCC? Es ist der Pentium® Pro Prozessor. Binärcode läuft auf der Pentium Pro Zielplattform am besten, wenn Sie bei der Kompilierung Ihres nativen Codes keine Flags hinzufügen. Die meisten Android-Anwendungen laufen auf der Intel Atom Plattform und nicht auf Pentium Pro. Je nach Zielplattform sollten unbedingt spezielle Flags hinzugefügt werden. Während der Kompilierung auf der Intel Atom Plattform können Sie die folgenden empfohlenen Flags hinzufügen:

-march=atom
-msse4
-mavx
-maes

Weitere Informationen zu Compiler-Parametern finden Sie unter: http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html

6. Fazit

Dieser Artikel behandelt die Entwicklung und Optimierung von Android*-Anwendungen auf Intel® Atom™ Plattformen sowie die Entwicklung und Portierung von NDK-Anwendungen.

Zusammenfassung der wichtigsten Punkte:

• Die meisten Android-Anwendungen können direkt auf der Intel Atom Plattform ausgeführt werden. NDK-Anwendungen müssen nativen Code neu kompilieren. Falls die Anwendung Assembly-Code enthält, muss dieser Teil des Codes neu geschrieben werden.
• Verwenden Sie ausgiebig die Funktionen der IA (Intel® Architektur), um die Leistung Ihrer Android-Anwendungen zu optimieren.
• Fügen Sie plattformspezifische Compiler-Switches hinzu, um die Effizienz des GCC-Build-Codes zu verbessern.

Referenz

1. http://software.intel.com/de-de/articles/installation-instructions-for-intel-hardware-accelerated-execution-manager-windows/
2. http://software.intel.com/de-de/blogs/2011/08/18/understanding-x86-vs-arm-memory-alignment-on-android/
3. http://software.intel.com/de-de/articles/ndk-android-application-porting-methodologies/
4. http://msdn.microsoft.com/de-de/library/1w2887zk.aspx
5. http://developer.android.com/sdk/ndk/index.html
6. http://de.wikipedia.org/wiki/Gleitkommaeinheit

Zur Autorin

Dawei arbeitet als Application Engineer mit Schwerpunkt auf Anwendungen für Mobilgeräte. Sie beschäftigt sich zum Beispiel mit der Entwicklung und Optimierung von Android-Anwendungen für x86-Geräte sowie der Entwicklung von Web-HTML5-Anwendungen. Dawei verfügt darüber hinaus über einen reichen Erfahrungsschatz beim UI- und UX-Design für Mobilanwendungen.

Hinweise

DIE INFORMATIONEN IN DIESEM DOKUMENT WERDEN IN ZUSAMMENHANG MIT INTEL® PRODUKTEN BEREITGESTELLT. DURCH DIESES DOKUMENT WERDEN WEDER AUSDRÜCKLICH NOCH KONKLUDENT ODER AUF ANDERE WEISE IRGENDWELCHE RECHTE AN GEISTIGEM EIGENTUM GEWÄHRT. MIT AUSNAHME DER FÜR DEN VERKAUF DIESER PRODUKTE IN DEN GESCHÄFTSBEDINGUNGEN VON INTEL DARGELEGTEN ANGABEN ÜBERNIMMT INTEL KEINE HAFTUNG. INTEL SCHLIESST IM ZUSAMMENHANG MIT DEM VERKAUF UND/ODER DER VERWENDUNG VON INTEL® PRODUKTEN JEDE AUSDRÜCKLICHE ODER STILLSCHWEIGENDE HAFTUNG ODER GARANTIE AUS, EINSCHLIESSLICH DER HAFTUNG BZW. GARANTIE IN BEZUG AUF DIE EIGNUNG FÜR EINEN BESTIMMTEN ZWECK, DIE HANDELSÜBLICHKEIT ODER DIE VERLETZUNG VON PATENTEN, URHEBERRECHTEN ODER ANDEREN RECHTEN AUF GEISTIGES EIGENTUM.

SOFERN NICHT ANDERWEITIG VON INTEL SCHRIFTLICH BESTÄTIGT, SIND DIE INTEL PRODUKTE NICHT FÜR ANWENDUNGEN KONZIPIERT ODER VORGESEHEN, BEI DENEN SITUATIONEN MIT MÖGLICHEN KÖRPERVERLETZUNGEN ODER VERLETZUNGEN MIT TODESFOLGE AUFTRETEN KÖNNTEN.

Intel behält sich das Recht vor, Spezifikationen und Produktbeschreibungen jederzeit ohne vorherige Ankündigung zu ändern. Entwickler dürfen nicht vom Vorhandensein oder Nichtvorhandensein bestimmter Funktionsmerkmale oder Produkteigenschaften, die als „reserved“ oder als „undefined“ gekennzeichnet sind, ausgehen. Intel behält sich eine künftige Definition derselben vor und lehnt jegliche Haftung hinsichtlich Inkompatibilität bzw. anderer Konflikte, die sich aus künftigen Änderungen dieser Merkmale ergeben, ab. Die hier angegebene Information kann sich jederzeit ohne besondere Mitteilung ändern. Nutzen Sie diese Angaben nicht für die Fertigstellung von Designs.

Die in diesem Dokument beschriebenen Produkte können konstruktionsbedingte Defekte oder Fehler (Errata) enthalten, die zu Abweichungen der Produkteigenschaften von den angegebenen Spezifikationen führen. Eine Liste derzeit bekannter Errata ist auf Anfrage verfügbar.

Wenden Sie sich an Ihr zuständiges Vertriebsbüro von Intel oder an Ihren Distributor, um die neuesten Spezifikationen zu erhalten, bevor Sie Produkte bestellen.

Dokumente, die eine Bestellnummer haben und auf die in diesem Dokument Bezug genommen wird bzw. weitere Literatur von Intel erhalten Sie im Internet unter http://www.intel.com/design/literature.htm. In Leistungstests verwendete Software und Workloads können speziell für die Leistungseigenschaften von Intel® Mikroprozessoren optimiert worden sein. Leistungstests, wie SYSmark und MobileMark, werden mit spezifischen Computersystemen, Komponenten, Softwareprogrammen, Operationen und Funktionen durchgeführt. Jede Veränderung bei einem dieser Faktoren kann andere Ergebnisse zur Folge haben. Als Unterstützung für eine umfassende Bewertung Ihrer vorgesehenen Anschaffung, auch im Hinblick auf die Leistung des betreffenden Produkts in Verbindung mit anderen Produkten, sollten Sie noch andere Informationen und Leistungstests heranziehen.

Jeder in diesem Dokument nachgedruckte Quellcode wird unter einer Softwarelizenz bereitgestellt und darf nur unter Beachtung der Bestimmungen dieser Lizenz genutzt oder kopiert werden.

Intel, Atom, Pentium und das Intel Logo sind Marken der Intel Corporation in den USA und anderen Ländern.

Copyright © 2012 Intel Corporation. Alle Rechte vorbehalten.

*Andere Marken oder Produktnamen sind Eigentum der jeweiligen Inhaber.

**Diese Quellcode-Beispiele werden unter dem Intel Lizenzvertrag für Quellcode-Beispiele veröffentlicht.