「ARM Cortex-M3の高いコード効率」

まず英国ARMホールディングス社は、アーキテクチャの設計を行いそのライセンスを半導体メーカーへ知的財産（IP：Intellectual Property）として販売するというビジネスモデルをとるIPプロバイダーです。パートナー会社はCPUコアの提供を受け、その上に周辺機器を組み込んでCPUとして販売します。ARMコアは世界中のパートナー会社にライセンスを提供され、日本の富士通、東芝、ルネサスなどもライセンス提供を受けています。
そのARM社が開発したCPUコアファミリのひとつがCortexです。

CortexはカテゴリをA、R、Mの3つのシリーズに分けて、必要とされる分野へそれぞれのプロセッサを提供しています。

Cortex-Aシリーズ ‐ 高性能のアプリケーションプラットホーム用に設計されたシリーズ。
LinuxやAndroidなどハイエンドな組み込み用OSを使用するスマートフォンなどを想定し、動作周波数も1GHzを超える。また、直接Javaのバイトコードの実行も可能で、マルチメディアデータも効率的に処理する機能も組み込み可。

Cortex-Rシリーズ ‐ 高性能なリアルタイム性能が求められる、組み込みシステムのために設計されたシリーズ。ハードディスクドライブコントローラーなどの高性能なリアルタイム制御が必要な機器を想定し、動作周波数の目安は数百MHz。

Cortex-Mシリーズ ‐ 低消費電力の組み込みマイクロコントローラ用に設計されたシリーズ。小型の組み込み機器全般を想定し、動作周波数の目安は数十MHz。
さらにMシリーズは、下図のようにCortex-M0、Cortex-M3、Cortex-M4とFPGA向けのCortex-M1と用途に応じて選択できるようになっています。

図1. Cortex-Mシリーズロードマップ

このことから、Cortex-M3は組み込み向けの標準的なプロセッサとして位置づけられており、富士通（FM3ファミリ）や東芝（TX03シリーズ）もCortex-M3を採用しています。

そして、このCortex-Mには以下のな特徴があります。

今回は、この特徴の中でも、実際に使用して魅力を感じた、Thumb2命令による「高コード効率」について取り上げたいと思います。

一般的に32ビットプロセッサでは、命令長も32ビット長が使用されますが、ARMプロセッサでは、32ビット命令を16ビット長の命令コードに圧縮し、動作時には32ビット長へ伸張して実行するという方法が可能です。このアーキテクチャはThumbと呼ばれ、高いコード密度を実現すると言われています。
また、Thumb命令では32ビット命令を実行する際には動作モードの切り替えが必要でしたが、Thumb2命令では、切り替えのオーバーヘッドなしで高速に実行できるようなっています。

ARM社が公開している「EEMBC社による相対的なCoreMarkテスト（ベンチマークテスト）サイズを使用したコード サイズの比較」では、他プロセッサとCortex-Mのコードサイズで、1.1〜2.0倍程度の差があるという結果が公開されています。

そこで、実際に開発で使用したコードにおいて、某社の16ビットプロセッサとCortex-M3でのコードサイズを比較してみたところ、以下のような結果となりました。（最適化なし）

表1. コード比較

この開発では、シリーズ毎にCPUをAとBに分けて開発する必要がありました。
実際にはAとBで機能が異なりますが、C言語で共通化されている部分も多々あり、その一部を抜粋したものです。

結果からわかるように、コードサイズ差は約19KByte Cortex-M3の方が少なく、また比率も平均すると約1.6倍の違いがあり、公開されている情報通りであることが分かります。

更にARM系のコンパイラのC言語最適化は優秀だと言われていたので、AとBで最適化前と後でそれぞれ調査してみた結果が以下となります。

表2. 最適化比較A

表3. 最適化比較B

更に、最適化後のAとBの比較結果をまとめてみました。

表4. コード比較2

このことから、最適化率はAが70%であるのに対してBは62%であり、たしかにCortex-M3の圧縮率が8％も高い結果となりました。
また、最適化後の両プロセッサでの比較でも、コードサイズは約16KByte Cortex-M3の方が少なく、また比率も平均すると約1.8倍の違いがあるという結果となっています。

たかが16KByteの差、たかが8％の差に見えるかもしれませんが、実際のコードは、今抜粋している何倍ものコードサイズになります。
一般的に、「最適化あり」のコードサイズから更に8%下げることは、コーディングミスなどによる余計なコードが残っている場合を除き、構造的な変更をしない限りとても難しいものです。

そのため、ROM容量が厳しいことが見込まれる組み込みソフトウェアの開発では、設計時点で使用ROM容量予測を行い、また、途中で変更が入るたびにも再度予測をしなおすという作業を繰り返し行うことになります。

なお、余談ですが、Cortex-M3では、デフォルトのCライブラリの代替ライブラリとして、MicroLIBというライブラリが準備されています。これは、デフォルトのCライブラリよりも約40%（約15KByte→約6KByte）コード圧縮されたもので、このライブラリの存在も非常に助かりました。

弊社で開発する組み込みソフトウェアは、小規模なものから大規模なものまでいろいろありますが、ものによっては大規模ながらも、内部ROM容量が少ない低CPUスペックを採用することでハードコストを抑えたい、ハード的な制約から外部ROMを追加できないなどの理由からプログラムサイズ（ROMサイズ）の少量化を求められる場合があります。

少量化の方法として、小規模なソフトウェアの場合、階層的なプログラム構造を崩して、プログラムコード量を減らす設計とすることで対応は可能ですが、大規模なソフトウェアの場合、そのような対応をすると、複数人数で開発が難しくなったり、コードがスパゲッティ化し不適合が多発してしまったり、将来的な改造などの保守が難しくなるなど、大きな影響を与えるケースが非常に多いです。
また、当然アセンブラで作成することも選択肢としてはあるのですが、その場合は、開発期間や費用が合わないといった問題に直面します。
そのため、大規模なソフトウェアで、コードサイズの少量化というのは難しいもので、ARMのような高いコード効率のプロセッサは、開発の現場においてはとても有効と感じました。

なお、2012年2月にMicrosoftもARM対応したWindowsを開発中と発表しています。
このことからも、ARMの需要は更に増えると思いますので、ARMについて学んでおいて損はないと思う今日このごろです。