メディア

プロセッサの選択肢を広げるソフトウエア開発ツール（1/2 ページ）

組み込みソフトウエアの開発ツールは、当初、プロセッサベースの設計をより迅速かつ容易に行えるようにすることを目的として提供されていた。しかし、最近ではその目的に変化が現われてきている。数多くのプロセッサアーキテクチャの選択肢を提供し、設計者が最適なプロセッサを選べるようにすることに主眼が置かれつつあるのだ。

» 2008年09月01日 00時00分公開

[Robert Cravotta，EDN]

アーキテクチャの多様化

　半導体ベンダーは、プロセッサ製品とともに、組み込みソフトウエアを開発するためのソフトウエアツールを提供するようになってきた。こうしたソフトウエア開発ツールのおかげで、組み込みソフトウエア開発に関する状況は、設計者が自力ですべてを何とかしなければならない時代とは大きく異なってきた。

　プロセッサ製品とともに最初に提供されたソフトウエア開発ツールは、プログラミングを容易にするためのアセンブラやコンパイラなどであった。その後、数十年ほどをかけて、半導体ベンダーやその開発ツールパートナが組み込みソフトウエア開発をサポートするために提供するソフトウエアは大きく変化を遂げた。その主な目的は、ターゲットとするプロセッサや類似のプロセッサファミリの使用/開発を容易にし、促進することであった（別掲記事『組み込みソフトウエアの生産性を高める』を参照）。

　それに対し、最近では異なる目的が前面に押し出されてきている。すなわち、設計者が要件に応じて設計を確定し、最適化を行う前に、より多くの選択肢を検討できるようにすることである。

　組み込みプロセッサ市場におけるソフトウエア開発の課題の1つは、膨大な数のプロセッサのアーキテクチャに対し、いかに生産的に対処するかということだ^＊1)^、^＊2)。選択肢が数多く存在する理由の1つは、コストを抑えられるよう、最小限のリソースによって機能、特徴、消費電力をバランス良く提供する方法を見つけ出すことが、組み込み設計における重要な作業だからである。

　組み込みシステム設計者に対してプロセッサを提供する半導体ベンダーの数は数十社に上り、いかにうまく問題を解決するかに焦点を当てた異なる対処法がいくつも存在する^＊3)。マイクロプロセッサ、マイクロコントローラ、DSP、プログラマブルロジック、DSC（デジタル信号コントローラ）などはその例である。いずれも、アーキテクチャ上で生じるいくつかのトレードオフに対して取捨選択を行い、その製品が最も得意とする種類の処理に対して能力を最適化してある。その一方で、ターゲットとする処理を迅速かつ効率的に実行する上では問題とならないが、ほかのアーキテクチャでは問題になる制約が課せられている場合が多い。

　単一のシステム内で、DSP、マイクロプロセッサ、ハードウエアアクセラレータなどの異なるアーキテクチャを採用した複数のチップが使用されるため、組み込み分野のソフトウエア開発はさらに複雑なものになっている。デスクトップ型パソコンの場合、メインのCPUに注目が集まりがちだが、ほかにもディスクドライブ、ネットワーク接続、ビデオ表示などの周辺機能の実現を担う多くの組み込みプロセッサが使われている。また、最近の自動車は、数十個ものプロセッサを搭載している。あるいは、洗濯機、電子レンジ、冷蔵庫といった家庭用電化製品にも、モーターやユーザーインターフェースを制御し、システム全体を監視するためのマイクロコントローラが何個か搭載されているケースが多い。このような複数の処理ユニットにより、消費電力とコストを抑えつつ、十分な性能を提供しているのである。

　アーキテクチャが異なる各種プロセッサには、コードに互換性のない場合が多い。そのためソフトウエア開発チームは、まず最初に、ターゲットとするプロセッサ（のアーキテクチャ）を決定しなければならない。最終的に必要なリソースは何かという情報が乏しい場合には、ここでの決断がプロジェクト全体のコスト、設計の難易度、リスクに対して大きな影響を及ぼす。

開発ツールによる支援

　半導体ベンダーは、自社が提供するソフトウエア/実行環境/開発ツールは、もはやチップの宣伝と販売を支援するためのものではなく、自社のシステム製品全体の中で重要な位置を占めるコンポーネントであると強く認識している。実際、半導体ベンダーは、IC製品の付属品として提供するソフトウエア開発ツールにかなりのコストを投入している。プロセッサメーカーが、「われわれはソフトウエア事業には携わっていない」などと言っていた時代はもう終わった。現在では、半導体ベンダーの目標は、システムの一部をハードウエアとソフトウエアに切り分けて提供する“システムハウス”に変貌することとなっている。

　半導体ベンダーは、IC製品とともに提供するソフトウエア（開発ツール）をより一層充実させようとしている。ソフトウエアは、それまでチップで実現してきた機能を維持するための、より安価で安全で柔軟な手段だからである。プロセッサのチップには、周辺機能、メモリー、メモリーコントローラなど多くのリソースが集積されている。しかし、すべてをハードウエアとして集積することが、必ずしも実用的であるとは限らない。例えばCRC（cyclic redundancy check：巡回冗長検査）は、ソフトウエアで実行するにはコストのかかる機能である。ハードウエアで実装するのは比較的簡単だが、CRCレジスタを実際に搭載するプロセッサ製品は、米Microchip Technology社製のものなどほんの一部だ。この機能を必要とするアプリケーションはさほど多くないため、すべてのプロセッサにCRCレジスタを搭載するのは合理的ではないからである。しかし、プロセッサの主要なアプリケーションでこの機能が使用されるのならば、ハードウエアとして搭載する価値がある。

　プロセッサベンダーは、自社の製品間で柔軟性を確保できれば、かなり有利であると考えている。設計者にとっても、プロセッサアーキテクチャの選択肢が広がることは望ましい。ほとんどのプロセッサベンダーは、複数のアプリケーションをターゲットとするために複数のアーキテクチャを提供している。そうした製品すべてに適用可能なソフトウエア開発ツールを用意するのは難しい。特に、それらのアーキテクチャすべての間に、ソフトウエアの柔軟性を確保するための手段が存在しない場合はそうである。実際、自社の一部のプロセッサ製品間で柔軟性を実現している企業はあるが、自社のすべてのアーキテクチャを網羅する、包括的なソフトウエア開発ツールが提供できるようになるのはまだまだ先のことであろう。

　プロセッサアーキテクチャの選択肢が広がることは設計者にとって望ましいことだが、そのことは問題をさらに複雑にしている要因でもある。米HI-TECH Software社のCEO（最高経営責任者）であるClyde Stubbs氏によると、「業界の予測に反し、プロセッサのアーキテクチャ数は激増している」という。ある意味で、アーキテクチャ（命令セット）の急増は、新世代コンパイラの優秀さを証明するものである。なぜなら、このことは、コンパイラによって、ターゲットとするプロセッサの命令セットの抽象化がうまく行われていることを示すものであるからだ。

　専用実行エンジンなどの特徴的機能が、各種プロセッサのアーキテクチャ上の違いになっている場合がある。主なものとしては、メモリーアクセスによって発生する遅延に対応するためのメモリーアーキテクチャが挙げられる。このようなアーキテクチャの多様化は、一時的な現象ではない。特定用途をターゲットとするプロセッサではさまざまなトレードオフが生じるが、アーキテクチャ設計において、その部分の適切な取捨選択を行うことによって生まれた真の差異化の結果なのである。

　このようにさまざまなアーキテクチャが存在すると、特にリアルタイム性の高いコードでは、サードパーティ製のIP（intellectual property）ブロックの利便性と効率的なコードの可搬性が妨げられる。C/C++のようなプログラミング言語は、このようなアーキテクチャ上の重要な違いに対応した構造は持たない。そのため、差異化を図るべく採用されたリソースを効率的に利用できるようにするには、コンパイラにおいて独自の言語拡張を行う必要が生じる。結果として、プロセッサのアーキテクチャは、命令レベルではコンパイラが処理しやすいものになったが、差異化を図った機能についてはコンパイラが処理しにくいものになってきている。

　プロセッサの命令セットは、常に大きな差異化が図れる部分であるとは限らない。メモリーのアーキテクチャと強い関連を持つ処理をいかに並列化して実行するか、または少ない消費電力で実行するかといったことのほうが、効果的に差異化が図れる部分だと言える。残念ながら、この辺りはコンパイラが得意な領域ではない。

　プロセッサ製品間で同一の命令セットを使用するだけでは、プロセッサ間に持たせるべき柔軟性としては不十分である。例えば、英ARM社の「ARM7」を利用する製品の差異化を図るためにその製品のベンダーがとるべき方法の1つは、割り込み機能、バス、周辺機能、メモリーアクセス構造を独自に実装することである。この方法により、そのプロセッサはある種の負荷に対しては強い製品になるが、同じARM7を用いるほかの製品に対してコードのポーティングを行おうとした場合に、その作業は複雑なものとなる。ARM社の「Cortex」では、アーキテクチャにおいて割り込み処理に関して一貫した方法を指定することなどにより、ソフトウエアのポーティングにかかる作業負荷の軽減を図ろうとしている。

組み込みソフトウエアの生産性を高める

　プロセッサベンダーが、容易かつ迅速にプログラミングが行えるよう、最初にアセンブラを提供してからかなりの歳月が経過した。その後、プロセッサのアーキテクチャとソフトウエア開発ツールは大きく変貌した。

■アセンブラからコンパイラへ

　基本的に、アセンブラは基盤となるプロセッサのアーキテクチャと命令コードセットの1対1のマッピングを行うものである。また、高い信頼性で、より容易にロジックを機械語に変換するものだとも言える。

　アセンブラに続いて普及した高級言語コンパイラの目的は、低レベル層の複雑さを抽象化することである。それによって、プログラマは、低レベルのコードの実装ではなく、ロジックの実装に集中できるようになった。

　初期のコンパイラで問題になっていたのは、プロセッサのアーキテクチャが、ソフトウエアチームではなくアーキテクチャチームにとって都合が良いように設計されている場合が多かったことだ。そのため、コンパイラを用いた場合、アセンブリ言語を使って手作業で最適化したコードと比べてかなり効率の悪いものしか生成できなかった。その理由の1つは、初期のプロセッサのアーキテクチャが、特殊な機能を備えたレジスタやアドレスバンクといった専用リソースの構造に依存していたことである。これらの専用リソースを効率的に利用するには、システムの誤動作につながる恐れのあるリソースの競合を回避するために、設計者がその動作を追跡しなければならない。プログラミング言語は、そうした特殊な専用リソースを認識すらしない。また、個々の専用リソースに対応するための情報をコンパイラが取得する標準的な方法も存在しない。従って、コンパイラは安全性を重視した仮定に基づき、競合などは発生しないものの、効率の悪いコードを生成するしかなかったのである。

■新世代のコンパイラ

　ソフトウエアの生産性を向上するために次に行われたのは、アセンブラやコンパイラのようにソフトウエアだけに頼るのではなく、コンパイラにとってプロセッサのアーキテクチャを処理しやすいものにすることであった。そのために、アーキテクチャの設計者とソフトウエアツールの開発者が協力し始めた。その結果、コンパイラはコードの生成時に、より合理的で適切な処理を行うことが可能となった。コンパイラ技術は、手作業による最適化が不要になるほど成熟したのである。

　新世代のコンパイラの多くは、独自の命令に対応するよう実装されている。開発者がコンパイラに対して条件を設定できるようになっており、より効率的なコードを生成することが可能になっている。

　多くの新世代コンパイラでは、プロセッサの命令フェッチと実行メカニズムに適した命令の再順序付けが行えるようになっており、プロセッサにおける遅延を最小化している。しかし、そうした新世代コンパイラを利用する場合でも、従来と同様にプロセッサの専用リソースにいかにうまく処理を割り当てて使用するかという点が課題となっている。ここで問題になるのは、バスやメモリーアクセス部など、システムにおいて特に遅延が生じがちな部分を補うためのリソースである。具体的には、専用バス、メモリー、DMA（direct memory access）構造などをうまく利用することにより、ある種のタスクに対しては大きな効果を得ている。今日でも、リソースの最適な利用を実現するためには、明示的な割り当てを宣言する必要がある。コンパイラとは異なり、ソフトウエア開発ツールはそのための機能を持たないものが多い（これに関する情報はアプリケーションノートに記載されていることがある）。コンパイラやソフトウエア開発ツールにおいて改善できる部分があることは確かなのだが、それを実現するための明確な方法はまだ存在しない。

■IDEの効用

　その次にソフトウエアの生産性向上をもたらしたのは、統合開発環境（IDE：integrated development environment）である。これには、プログラムエディタ、プロファイラ、デバッガ、プロジェクトマネジャなどのツールが含まれ、単一の環境内で各ツールにアクセスできるようになっている。

　IDEは、さまざまなプロセッサをターゲットとするソフトウエア開発において、一貫性を持った手段を提供することを可能にする。これにより、プロジェクトごとに異なるプロセッサとツールセットを利用しなければならず、そのたびに使用方法を学習し直さなければならないという状況が回避できる。Texas Instruments社のDaVinciやFreescale社のFlexisのように、設計サイクルの後工程においてターゲットとするプロセッサを変更することを可能にするものもある。

■ハードウエアでの対策

　ソフトウエア開発ツールが進化すれば、ソフトウエアの生産性が改善する。それに伴ってハードウエアに変更が生じるケースもある。優れたハードウエアリソースを利用すれば、OSの処理効率を向上させることができる。また、オンチップのハードウエアデバッグリソースは、ますます複雑になっていくプロセッサの内部で何が生じているのかを知るために必須のものだと言える。

　半導体ベンダーは、設計者を支援するために、開発ツールにおいて、周辺機能の構成（コンフィギュア）用ウィザードをサポートするといったことに取り組んでいる。ほかにも、自社の製品ラインで周辺ブロックの共通セット（つまり、インターフェースラッパー）を採用することにより、開発者が対処すべき問題の複雑さを緩和するなどの取り組みも行っている。このことは、ソフトウエア開発ツールが複雑になることへの対策にもつながる。

　プロセッサに集積されるトランジスタの数はますます増加している。そうした中で、ソフトウエアの生産性を向上させるために集積されるトランジスタの数もより一層増加していくだろう。