Android* 開発者向けラーニングシリーズ 2: インテルのモバイル・プロセッサー

この記事は、インテル® デベロッパー・ゾーンに掲載されている「Intel for Android* Developers Learning Series #2:The Intel Mobile Processors」の日本語参考訳です。

---

1. Medfield プラットフォーム

インテル® Atom™ プロセッサー Z2610 (開発コード名: Medfield) は、Android* オペレーティング・システムで動作するスマートフォンをターゲットにしたプラットフォームです。Medfield は、ノース・コンプレックスとサウス・コンプレックスの 2 つのコンプレックスに分かれています。ノース・コンプレックスは、Saltwell (シングルコア・プロセッサー)、32 ビット・デュアルチャネル LPDDR2 メモリー・コントローラー、3D グラフィックス・コア、ビデオデコード/エンコードエンジン、最大 3 つのディスプレイをサポートする 2D ディスプレイ・コントローラー、カメラ入力用のイメージ・プロセッサーから構成されています。インテル® Atom™ プロセッサー Z2610 のサウス・コンプレックスは、セキュリティー・エンジン、SD/eMMC ストレージカードをサポートするストレージ・コントローラー、USB OTG コントローラー、3G モデム、CWS (Complimentary Wireless Solution) インターフェイス、SPI、UART など、スマートフォンの設計に必要なすべての I/O インターフェイスから構成されています。

図 1: Medfield のブロック図

1.1. Saltwell の概要

Saltwell のアーキテクチャーは非常に単純です。設計の目的は、最適なパフォーマンスと効率良い電力消費のバランスが取れたプロセッサーを作成することでした。このプロセッサーは、市場の多くのプロセッサーとは異なり、インオーダー・アーキテクチャーを使用しています。L1 キャッシュは 64KB、L2 キャッシュは 512KB です。また、このプロセッサーは、CPU の動作速度をプロセッサーが動的に制御するインテル® Burst Performance Technology をサポートしています。Saltwell は、600MHz の低周波数モード (LFM)、900MHz の高周波数モード (HFM)、1.6GHz のバースト周波数モードの 3 つの周波数モードで動作します。数々の消費電力最適化機能の中でも特徴的なものは、C ステートからの復帰レイテンシーを低くするため、CPU が C6 ステートの間はデータを保持する、超低消費電力スマート L2 キャッシュです。また、Saltwell ではコアと SoC の残りの部分で電圧とクロック入力を個別に制御できるため、インテル® Smart Idle Technology (インテル® SIT) を使用して電圧とクロック・ゲーティングを簡単に設定できます。このテクノロジーを利用することで、SoC がまだオン (S0 ステート) であっても CPU を完全にオフにすることができます。

2. Saltwell と ARM (Cortex A15) のアーキテクチャーの違い

『Break Away with Intel® Atom™ Processors: A guide to Architecture Migration』 で紹介されているように、インテル® Atom™ のアーキテクチャーと ARM のアーキテクチャーはあらゆる点で非常に異なります。表 1 は、Saltwell と ARM Cortex のアーキテクチャーを比較したリストです。

	Saltwell	ARM Cortex
プロセス	32nm	28nm
アーキテクチャー	インオーダー	アウトオブオーダー
整数パイプライン	16	15
L1 キャッシュ	64KB	64KB まで設定可能
L2 キャッシュ	512KB	最大 4MB
命令セット	IA32、インテル® ストリーミング SIMD 拡張命令、インテル® ストリーミング SIMD 拡張命令 3 補足命令	ARM Thumb
マルチコア/スレッドのサポート	シングルコア、インテル® ハイパースレッディング・テクノロジー対応	マルチコア
セキュリティー・テクノロジー	インテル® Smart & Secure Technology (インテル® S&ST)	TrustZone* テクノロジー

表 1: Saltwell と ARM (Cortex A15) の比較

2.1.1.  アーキテクチャー

Saltwell ではインテル® Atom™ シリーズのほかのプロセッサーと同じアーキテクチャーが採用されており、インオーダー実行デザインを使用しています。インオーダー・プロセッサーでは、すべての命令がフェッチした順に実行されます。一方、アウトオブオーダー・プロセッサーは、複数の命令を同時に実行してから、パイプラインで命令をリオーダーする (順番を並べ替える) ことができます。ARM プロセッサーはアウトオブオーダー・アーキテクチャーを使用しているため、最小のレイテンシーで命令を実行できるという長所があります。しかし、コアデザインはより複雑になり、消費電力が増加します。リオーダーロジックの排除は、インテル® Atom™ プロセッサーの消費電力における優位点の 1 つです。

2.1.2.  整数パイプライン

インテル® Atom™ プロセッサーのパイプラインには 6 つのフェーズがあります。詳細を表 2 に示します。

フェーズ	パイプラインのステージ
命令フェッチ	3
命令デコード	3
命令発行	3
データアクセス	3
実行	1
ライトバック	3

表 2: インテル® Atom™ プロセッサーの命令フェーズとパイプラインのステージ数

インテル® Atom™ プロセッサーには合計で 16 ステージの整数パイプラインがあり、浮動小数点命令を実行するには 3 つの追加ステージが必要です。最新の ARM プロセッサーには 15 ステージの整数パイプラインがあります。ARM プロセッサーの長いパイプラインは、消費電力よりもパフォーマンスを優先したものです。Saltwell はクロックサイクルあたり 2 つまでの命令をデコードできます。一方、最新の ARM プロセッサーは 3 つの命令を実行できるスーパースカラー・アーキテクチャーを採用しています。

2.1.3.  命令セット

ARM の命令セットは常に 32 ビットで 4 バイト境界でアライメントする必要があります。IA32 の命令セットはサイズが異なり、アライメントは必要ありません。ARM の命令と IA32 の命令のもう 1 つの違いは、命令の実行形式です。ARM では、分岐のオーバーヘッドと分岐中の予測ミスを減らすために、すべての命令は条件付きで実行されます。各命令を有効にするには条件フラグが必要です。条件フラグのない命令は NOP として扱われ廃棄されます。インテル® アーキテクチャーにも条件付き命令はありますが (条件 MOV 命令)、IA32 のほかの命令は条件付きで実行されません。

2.1.4.  マルチコア/スレッドのサポート

Saltwell は、共有リソースを使用してタスクを完了する、インテル® ハイパースレッディング・テクノロジー (インテル® HT テクノロジー) をサポートしています。このテクノロジーの詳細は、次のセクションで説明します。ARM マルチコア・アーキテクチャーには、各コアでタスクを実行する固有のリソースがあります。コアのコヒーレンシーは AMBA 4 AXI* (直接コアに接続される互換スレーブ・インターフェイス) によって制御されます。

2.1.5.  セキュリティー・テクノロジー

Medfield には、完全なハードウェアおよびソフトウェアのセキュリティー・アーキテクチャーである、インテル® Smart & Secure Technology (インテル® S&ST) と呼ばれるセキュリティー・サブシステムがあります。このサブシステムは、業界標準規格に準拠しており、AES、DES、3DES、RSA、ECC、SHA-1/2、および DRM をサポートしています。1000 ビットの OTP もサポートしており、セキュアブートも可能です。ARM プロセッサーのセキュリティー・システムの実装は異なり、インテルのようなセキュリティー・サブシステム用の個別のコントローラーはありません。ARM プロセッサーは TrustZone テクノロジーを使用しており、プロセッサーやメモリーのようなシステムのリソースはノーマルゾーンとセキュアゾーンの 2 つに分けられます。このアーキテクチャーを採用した理由は 3 つあります。(1) 設計者が利用状況に応じて必要な機能をカスタマイズできるセキュリティー・フレームワークを提供するため。(2) セキュアなタスク用に専用のプロセッサーを用意することなくシリコンのサイズと消費電力を減らすため。(3) 単一のデバッグ・コンポーネントを提供することで、セキュアゾーンのセキュリティーが重要なタスクや、ノーマルゾーンのセキュリティーが重要でないタスクのデバッグ中の侵入を防ぐため。

3. インテル® ハイパースレッディング・テクノロジー

インテル® ハイパースレッディング・テクノロジー (インテル® HT テクノロジー) を有効にすると、ソフトウェアは 1 つの物理プロセッサー・パッケージ (コア) で複数の論理プロセッサー (スレッド) を処理することができます。Saltwell は、インテル® HT テクノロジーによりインオーダー・アーキテクチャーの単一プロセッサーで 2 つのスレッドを処理することで、パフォーマンスを向上させています。2 つのスレッド間で実行リソースを共有して 1 クロックサイクルに複数の命令を実行できるため、図 2 に示すように、単一スレッドしか実行できないプロセッサーと比較してパフォーマンスがおよそ 50% 向上しています。

図 2: インテル® ハイパースレッディング・テクノロジーの利点

インテル® HT テクノロジーでは、プロセッサーは、汎用レジスター、制御レジスター、APIC (Advanced Programmable Interrupt Controller) レジスター、複数のマシン・ステート・レジスターからなるアーキテクチャー・ステートを 2 つ維持します¹。これは、ソフトウェアから 1 つの物理コア・プロセッサーを 2 つの論理プロセッサーとして見えるようにするためです。キャッシュ、実行ユニット、分岐予測、制御ロジック、およびバスは 2 つのスレッド間で共有されます。インテル® HT テクノロジーを活用するにはリソースの競合やスレッド間のロード・インバランスに注意する必要がありますが、Dalvik や JavaScript のような現在の開発キットの多くはすでにマルチスレッド環境をサポートしているため、開発者はインテル® HT テクノロジーの長所を活用したアプリケーションを容易に作成することができます。Android* アプリケーションの開発者も、インテル® VTune™ Amplifier を使用してワークロードを分析し、アプリケーションのリソースをチューニングできます。

4. アプリケーションの互換性: ネイティブ開発キット

Android* は x86 にも移植されており、今後のリリースはすべて x86 と ARM の両方で利用できる予定です。このため、インテル® Atom™ プラットフォームで OS を動作させることは難しくありません。ただし、既存の Android* アプリケーションの中には再コンパイルが必要なものがあります。

図 3: Android* フレームワーク

Google Play Store の Android* アプリケーションの 75 ～ 80 パーセント (一般に紹介される数値) は Dalvik VM 上で動作し、Android* フレームワーク (図 3 を参照) を使用していると考えられます。Android* ソフトウェア開発キット (SDK) を使用して Java* 言語で記述された Dalvik VM アプリケーションの大部分は、プロセッサーに依存せず、インテル® Atom™ プラットフォームでもそのまま動作します。しかし、C や C++ コードを含むアプリケーションのサブセットは、最新の Android* ネイティブコード開発キット (NDK) を使用してコードを再コンパイルする必要があります。[1]

ほとんどの場合、NDK アプリケーションの開発者は x86 (x86)、ARMv5 (armeabi)、および ARMv7 (armeabi-v7a) をサポートするようにプロジェクトを再コンパイルするだけで対応できます。x86 向けに (GCC でコンパイラー・オプション -march=i686 –msse3 –mstackrealign –mfpmath=sse を使用して) コンパイルすると[2] 、インテル® Atom™ プロセッサーの機能向けにカスタマイズされたコードが生成されます。ARM ベンダーの固有の機能を使用しているアプリケーションのみ、ソースコードを変更して再コンパイルする必要があります。

生成される APK アプリケーション・パッケージには、x86、ARMv5、ARMv7 用の 3 種類のマシンコードが含まれます。インストール時に適切なバージョンのコードが展開され、ターゲット・プラットフォームにインストールされます。

残りのアプリケーションは、ARM 用の JNI (Java* Native Interface) ライブラリーを使用している Dalvik VM アプリケーションか、x86 用にコンパイルされていないネイティブコード開発キット (NDK) アプリケーションのいずれかです。

[1] インテル® Atom™ プラットフォームへのアプリケーションの移植に関する詳細は、http://intel.com/software/android (英語) を参照してください。

[2] コンパイラー・オプションの概要は、NDK ドキュメントの ndk/docs/CPU-ARCH-ABIS.html ページを参照してください。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。