低価格市場に侵攻する32ビットプロセッサ：8ビット/16ビット品は駆逐されるのか？（2/2 ページ）

[Robert Cravotta，EDN]

CoreMarkによる性能比較

　8ビットプロセッサと32ビットプロセッサの価格差は今後も小さくなり続けるだろう。だが、そこには、8ビットプロセッサはコストを極限まで低下させた旧式のプロセスで製造されるのに対し、32ビットプロセッサは高度な微細プロセスを使用してチップサイズを抑えることで価格を近づけていているという事実がある。そして、業界では、8ビットプロセッサが今後も旧式の製造プロセスを使用し続けるとは限らないとの予測がなされている。すなわち、8ビットプロセッサを微細プロセスで製造してチップサイズを抑えれば、32ビットプロセッサよりも安くできる可能性がある。従って、現時点において8ビットプロセッサと32ビットプロセッサの価格差が縮小しているからといって、32ビットプロセッサが8ビットプロセッサから市場を奪うとは言い切れない。やはり、32ビットプロセッサの市場を拡大させるには、性能面での優位性が求められるはずだ。

　このような背景から、Cortex-M0のコード密度の優位性に関するNXP社の主張が重要になってくる。しかし、コード密度や処理性能を測定/評価することは困難だ。特に、まったく異なるアーキテクチャを採用するプロセッサの性能を比較するのは、非常に難しい。

　NXP社の主張は、米EEMBC（Embedded Microprocessor Benchmark Consortium）が開発したベンチマークツール「CoreMark」で計測したコード密度と処理性能の比較に基づいている。2009年に開発されたCoreMarkは、8ビット、16ビット、32ビットの処理を、それぞれほぼ同量ずつ実行するいくつかのコア関数から構成されている。基本的には、プロセッサコアのみに着目したベンチマークツールであり、処理能力を向上するメモリーアーキテクチャなどの周辺機能については考慮されていない。

　まず、CoreMarkでは、基本的に8ビットで実装されるステートマシンの部分が、8ビット処理に相当する。このベンチマークプロセスは、8ビットプロセッサにとって有利である。

　双方向連結リストは、一般的には16ビットアーキテクチャが得意とする処理だ。しかし、CoreMarkでは、連結リストに14個しか要素がない。このため、8ビットアーキテクチャに適したものとなっている。ベンチマークを実行する際には、プロセッサのビット数に合わせて、コンパイラが適切な仮定に基づいてコードを生成できるようにしておく必要がある。ここで言う適切な仮定とは、双方向連結リストに対して、コンパイラが、32ビットプロセッサに対しては32ビットのポインタを、16ビットプロセッサに対しては16ビットのポインタを指定するというものである。

　8ビットプロセッサについては、8ビットデータと2つの8ビットポインタを使用するのが適切である。このデータ構造に対して8ビットポインタを使用するには、ベースまたはインデックスポインタを使用する必要があるかもしれない。また、データ構造全体が8ビットアドレス内に収まるようにするには、連結リストのサイズがかなり限定される。CoreMarkの連結リストの要素数は14個しかないので、このデータ構造に対して8ビットポインタを使用する場合の最大要素数である80個よりもかなり小さいサイズになっていると言えるだろう。

　もし、8ビットプロセッサ上で16ビットや32ビットのポインタを使用すると、このような小さなマシンでは決して使用するはずのないデータ構造を使用することになる。その結果、必要になるコードやデータメモリーの規模はとても過剰なものとなる。8ビットのポインタであれば、1データ要素当たり3バイトで済む。ところが、16ビットや32ビットのポインタを使用する場合には、1データ要素当たり5バイト〜7バイトを使用する。さらに、コードには、16ビットや32ビットのアドレスをロードするために余分な命令も必要になる。

　CoreMarkベンチマークのもう1つのプロセスは、行列操作である。この部分は、SIMD（Single Instruction/Multiple Data）拡張をはじめ、32ビットの算術ユニットなどの機能を持つアーキテクチャが得意とする16ビット/32ビットの処理から成る。

図2　「XC878」のブロックダイアグラム（提供：Infineon社）　紫の線で囲んだ16ビット/32ビットの半自律型周辺機能を備えることによって、小さなシステム構成でも、プロセッサコアに過度の負荷を与えることなく、拡張タスクを実行することができる。

　CoreMarkベンチマークの最後のプロセスは、16ビットCRC（巡回冗長検査）である。これは、検証の役割を果たすとともに、16ビット処理と、8ビット処理/32ビット処理の間でバランスをとるための部分となっている。しかし、16ビットや32ビットの処理が、8ビットプロセッサにまったく適していないというわけではない。ドイツInfineon Technologies社の8ビットマイコン「XC878」は、16ビットおよび32ビットに拡張された半自律型周辺機能を備えている。マイコンのシステム全体で見ると、プロセッサコアに過度の負荷をかけることなく、これらの拡張タスクを実行できるようになっている（図2）。このような拡張周辺機能は、タスク集合が明確に定まっており、コストと消費電力が厳しく制約される特定用途のプロセッサに適している。

　CoreMarkを用いて8ビットアーキテクチャと32ビットアーキテクチャを比較する場合、ベンチマークの各要素を完全に切り離して、評価の対象となる機能に関連する要素だけを実行することはできない。また、Infineon社のXC878のように、同一条件下におけるCoreMarkベンチマークの評価結果において、32ビットプロセッサとの比較が困難になるような特殊な製品を、それほどコストをかけることなく開発することも可能だ。

システムレベルで見た消費電力

　処理性能以外で、プロセッサを選定する際に重視されるのが消費電力である。一般的に、8ビットプロセッサと16ビットプロセッサは、32ビットプロセッサと比べて、プロセッサ単体の消費電力のみならず、システムレベルでの消費電力においても優れている。プロセッサの消費電力を比較する場合には、スリープ状態、スリープ状態からの起動、アクティブな状態、それぞれの状態について消費電力を測定する必要がある。これらのうち、プロセッサがスリープ状態から起動する際にシステムが損失する電力は、システムのセトリング時間に依存する。そして、システムがスリープ状態から起動する頻度も、システム全体の消費電力に影響を与える。

　8ビットプロセッサと16ビットプロセッサが旧来のプロセスで製造されることには、低コストであること以外にも理由がある。それは、高度で微細なプロセスと比べてリーク電流がかなり少ないことだ。ほとんどの時間をスリープ状態で過ごすようなシステムでは、このことは特に重要である。ただし、リーク電流が少ない製造プロセスを選択した場合、システムの動作時のアクティブ電流は微細プロセスを利用する場合よりも多くなる。そのため、消費電力は、システムのスリープ状態とアクティブ状態の比率に依存することになる。大規模なプロセッサと小規模のプロセッサとでは、処理の実行にかかる時間が大きく異なる可能性がある。そのため、この比較はさらに難しくなる。32ビットプロセッサは、8ビットプロセッサよりも速く処理を完了することができるので、スリープ状態で過ごす時間も長い。このため、プロセッサ単体では32ビット品のほうが消費電力が多くても、システム全体として見れば8ビット品を使ったほうが消費電力が少なくなることもある。なお、最新のプロセッサには、高度な電源管理技術が実装されているものがある。

　また、リソースの割り当てやリソースの容量調整についても検討の余地がある。例えば、NXP社やTexas Instruments社の製品は、システムドライバやライブラリを格納したROMを、それぞれハードウエアブロックやファームウエアブロックであるかのように利用している。ROMをこのように利用することによって低レベルの機能を安定させられれば、プログラムを格納するのに必要となるフラッシュメモリーの容量を小さくすることができるかもしれない。

　ただし、こうした低レベルの機能をソフトウエアとして技術者にオープンにする場合には、プログラム用のフラッシュメモリーにある程度の容量が必要となる。フラッシュメモリーの容量を小さくすることができれば、全体的なシリコンコストとシステムの消費電力をいくばくか低減することが可能だ。このことだけによる節減効果は大きなものではないが、このような小さな工夫の積み重ねが、全体的なコストと消費電力の大きな節減につながるのである。