プロジェクト初期のツール評価

技術・開発の閑話 ：ソフト開発コラム

• サウンドコラム/技術開発コラム
• サウンドコラム
• 音響測定編
• ソフト開発
• 技術開発の閑話2

プロジェクト初期のツール評価

コラム：プロジェクト初期のツール評価【01】

01

前回は、DSPやCPUのツール選択時の評価についてでした。今回も前回に続き、開発プロジェクト当初の評価についてです。

開発ツールの評価

開発ツールの評価は、特殊なプロセッサでメーカーの純正品しかなかったとしても必ず行ないます。ここまで「ツール選択」のという表現をしていますが、DSPや組込用マイコンの場合、メーカー製ツールが唯一のツールであることがあります。このような場合には、選択の余地はありませんが、それでも、最初の評価は重要です。

何を評価しようとしているのか...

プロジェクト初期のツール評価
コラム：プロジェクト初期のツール評価【01】

《 技術開発の閑話 : プロジェクト初期のツール評価 》

プログラムの動作・ソースの作成

コラム：プロジェクト初期のツール評価【02】

02

開発ツールの評価は、地味ですが、ソフトウェア開発プロジェクトの成功を左右する重要な作業であることは前回お話しました。今回は、評価にかかわるコンパイル、アセンブル、リンク、デバッグの作業を簡単にご説明します。

ご覧いただいている読者の方は技術者の方ばかりではありませんので、少し開発ツール評価と離れますが、具体的な内容を記すのに必要な基本的なプログラムの動作などについて、先に数回に分けてお話しすることにしました。

１．プログラムソースの作成

まず、プログラムをする場合には、ソースコードという人間が作成しやすく、コンピュータ用の実行コードに変換可能な様式をもつテキストファイルを作成します。これが、一般に言われるプログラミング、コーディング作業ということになり、ソースコードの作成ルールがプログラミング言語などと言われるものです...

プログラムの動作・ソースの作成
コラム：プロジェクト初期のツール評価【02】

《 技術開発の閑話 : プログラムの動作・ソースの作成 》

コード生成　アセンブラ、コンパイラ

プロジェクト初期のツール評価【03】

03

コンパイル、アセンブル

前回は、ソースプログラムの作成についてでした。ソースプログラムを作成し、アセンブル、もしくはコンパイルという専用プログラムによる機械翻訳をして最終的なプログラムコードを作成します。

DSPや現在の高速なCPUの場合には、並列実行やパイプライン実行されたり（Pentiumなどの場合には、μOPと呼ぶパイプライン用のコードにCPUで翻訳され、パイプライン実行）投機実行などを持ちますから、単純に順次ではないのですが、基本的にはプログラムされた通り１つづつ順次実行します（１ステップと呼ばれていた単位です）。

機械語とアセンブラ

この１ステップでは、「メモリを見る」、「加算する」、「メモリに記録する」など単純な動作をしています。機械コードに近いアセンブラでは、この単位でプログラムします。「Ａ＋Ｂ＝Ｃ」のように値を加算するプログラムの場合（多くのアーキテクチャの物は）...

コード生成　アセンブラ、コンパイラ
コラム：プロジェクト初期のツール評価【03】

《 技術開発の閑話 : コード生成　アセンブラ、コンパイラ 》

型変換を伴う式評価(コード生成)

プロジェクト初期のツール評価【04】

04

前回は、コンパイラの生成コードに関連して主にアセンブラ言語について簡単なお話をしました。今回は、コンパイラのコード生成の評価について具体的にどのような評価をしているかなど簡単にご紹介して見たいと思います。

型変換を伴う式評価

ANSIで決められているCコンパイラの評価の中で、組込などでは、影響が大きいものにchar型（文字のデータ型）の評価方法があります。

基本的にANSI規格に準拠というコンパイラであれば、整数型で演算評価されます。整数型は、16bit以上の語長と規定されていますので、char型が8bit語調のデータ型である場合、一旦、整数に型変換してから評価式が評価されます。

例えば、Cコンパイラの場合、次のようなソースコードの場合です。（ソフトウェア技術者ではない方にはスミマセン。）...

型変換を伴う式評価(コード生成)
コラム：プロジェクト初期のツール評価【04】

《 技術開発の閑話 : 型変換を伴う式評価(コード生成) 》

暗黙のライブラリ(コンパイラ生成コード)

プロジェクト初期のツール評価【05】

05

前回は、コンパイラの生成コードの評価の具体例として型変換が行なわれる時の生成コード評価についてでした。ポイントは、暗黙の型変換による語長拡張、符号拡張と式評価のコードのオプティマイズです。

最適化(オプティマイズ)とハードウェアの進化

組込系であっても、Windowsアプリケーションであっても、実行モジュールのサイズ(ファイルサイズ)や実行速度に代表されるCPU効率は重要です。

昨今のパソコンは高速化が著しいため最適化など必要がないという意見があります。しかし、１０年前でも同様の意見がありました。

高速化することによってリアルタイムに処理できなかった動画などの処理が可能になったように、例えば、数学的な大量の計算を必要とする処理がリアルタイムに計算可能であれば、利用方法が進化しますから、限界までの処理速度が要求されるのは、少なくても、まだ、数年は続くことでしょう...

暗黙のライブラリ(コンパイラ生成コード)
コラム：プロジェクト初期のツール評価【05】

《 技術開発の閑話 : 暗黙のライブラリ(コンパイラ生成コード) 》

組込みCPUのメモリアクセス1

コラム：プロジェクト初期のツール評価【06】

06

前回までは、コンパイラの生成コードの評価の具体例として型変換と暗黙のライブラリについてでした。今回は、メモリアクセスについての対応コードです（メモリアクセスとは、プロセッサからメモリを読み書きすることです）。

メモリアクセスとアーキテクチャ

DSPやCPUの中には、メモリやスタック、メモリアクセス方法などに特殊な条件を持つものが多く存在します。

パソコン上で動作するプログラムコードを生成するためのコンパイラのカスタマイズ版であったり、スタートアップコードやライブラリなどを変更して行うクロス開発の場合、特殊用途のメモリアクセスについては生成コードを意識したコーディングが必要となります。

少しだけメモリ関連の特殊な例を上げてみたいと思います...

組込みCPUのメモリアクセス1
コラム：プロジェクト初期のツール評価【06】

《 技術開発の閑話 : 組込みCPUのメモリアクセス1 》

組込みCPUのメモリアクセス2

コラム：プロジェクト初期のツール評価【07】

07

前回は、組込系CPU,DSPなどのメモリアクセスについてでした。

特殊なメモリアクセスが関係するコードはコンパイラを利用せず、アセンブラで実装する場合には、何ら問題が生じませんが、プロジェクトの方針で（コードの保守、流用のためなどの理由によって）スタートアップなどを除いて基本的にコンパイラで作成すると決定している場合や、アセンブラとのミックスモデルで実装していても、高級言語のソースで頻繁にアクセスする必要があるI/Oポート等が存在するとコンパイラの出力コードで動作させる必要が生じます。

特殊なメモリアクセス方式は、コンピュータやＣＰＵの本質的なものではなく、コンピュータの創生期やマイクロプロセッサの創生期に、ハードウェアとソフトウェアの性能バランスを工夫してプログラムによって制御する製品などを実現するために考え出されたものが主です...

組込みCPUのメモリアクセス2
コラム：プロジェクト初期のツール評価【07】

《 技術開発の閑話 : 組込みCPUのメモリアクセス2 》

組込みCPUのメモリアクセス3

コラム：プロジェクト初期のツール評価【08】

08

前回は、組込系CPU,DSPなどのメモリアクセスについて簡単にご紹介しました。今回はメモリアクセスのコードの注意についてです。

メモリ・ハードウェアの特性とオプティマイズ

メモリアクセスに関しての注意点の1例をご紹介します。

一般に、高速プロセッサは、外部メモリアクセスは低速な動作となる場合が多いのでオプティマイザは、メモリアクセス数を少なくするようなコードを生成しようとします。

同一アドレスにマッピングされたI/Oポートを複数アクセスすることで、読み出し回数によって内容を変更するように設計された周辺I/Oなどの場合、連続して読み出しアクセスしている行為は無駄なので、初回に読み出した値を代替として利用するようなコードが生成される場合があります...

組込みCPUのメモリアクセス3
コラム：プロジェクト初期のツール評価【08】

《 技術開発の閑話 : 組込みCPUのメモリアクセス3 》

コード生成〜デバッガ

コラム：プロジェクト初期のツール評価【09】

09

前回までは、ちょっと専門的で細かいお話が続きました(テーマの性質上しかたのない部分もありますが)。少し本流に戻ってみたいと思います。

高度なCPUとコンパイラのオプティマイザ

これまでの細かい話は、大きく分けるとコンパイラのオプティマイズ（最適化）やコード効率評価の評価と正常動作させるための評価が主な内容でした（この評価の比重が一番重要になりますから）。

現在の高速ＣＰＵでは、パイプラインやキャッシュの技術が主となっていますので、コンパイラのオプティマイザのパイプラインに対する最適化やキャッシュ性能を生かすリンカーの配置などが欠かせません...

コード生成〜デバッガ
コラム：プロジェクト初期のツール評価【09】

《 技術開発の閑話 : コード生成〜デバッガ 》

• 開発ツールの話 vol.01〜02
  ソフト開発コラム
• 
• プロジェクト初期のツール評価
  コラム : プロジェクト初期のツール評価【01】

• サウンドコラム/技術開発コラム
• サウンドコラム
• 音響測定編
• ソフト開発
• 技術開発の閑話2

ソフトウェア開発コラム ： 技術・開発の閑話

ソフトウェア開発と開発ツール関連の雑記

機器組込みのエンベデット・ソフトウェア(ファームウェア)の開発に関連したコラムです。 メールマガジン「アメニティ＆サウンド 音と快適の空間へ」に連載していた技術・開発コラムを編集掲載しています。

技術・開発の閑話 : ソフト開発コラム 01 ファームウェア(組込み)開発の技術 コラム：技術・開発の閑話【01】 02 デバッギング・ミステリー コラム：技術・開発の閑話【02】	開発ツールの話 : ソフト開発コラム 01 ソフトウェアの分類 コラム：開発ツールの話【01】 02 CPUとDSPのアーキテクチャの違い コラム：開発ツールの話【02】
プロジェクト初期 ツール評価 : ソフト開発ツールの話 01 プロジェクト初期のツール評価 プロジェクト初期のツール評価【01】 02 プログラムの動作・ソースの作成 プロジェクト初期のツール評価【02】 03 コード生成　アセンブラ、コンパイラ プロジェクト初期のツール評価【03】 04 型変換を伴う式評価(コード生成) プロジェクト初期のツール評価【04】 05 暗黙のライブラリ(コンパイラ生成コード) プロジェクト初期のツール評価【05】 06 組込みCPUのメモリアクセス1 プロジェクト初期のツール評価【06】 07 組込みCPUのメモリアクセス2 プロジェクト初期のツール評価【07】 08 組込みCPUのメモリアクセス3 プロジェクト初期のツール評価【08】 09 コード生成〜デバッガ プロジェクト初期のツール評価【09】	デバッガとICE　ツール評価2 : ソフト開発ツールの話 01 CPU,DSPの内部の状態モニター コラム : デバッガとICE【01】 02 プロセッサ周辺のモニター(メモリ、I/O) コラム : デバッガとICE【02】 03 実行の停止(ブレーク機能) コラム : デバッガとICE【03】 04 シングルステップ実行 コラム : デバッガとICE【04】 05 任意部分の実行(および再実行) コラム : デバッガとICE【05】 06 ヒストリー - 実行トレースとコマンド コラム : デバッガとICE【06】 07 各種ファイルのロード、セーブ コラム : デバッガとICE【07】 08 シンボル化(読み込み、設定、編集) コラム : デバッガとICE【08】

技術・開発の閑話 -2-

ソフト、ハードウェア 技術関連の雑記

このコラムは無料メールマガジン「アメニティ＆サウンド 音と快適の空間へ」　vol.36〜vol.64(2003年8/21〜2004年11/18)に 音響と開発の関連コラムとして連載していたものを編集掲載したものです。

技術・開発の閑話-2- vol.11〜20 F1とコンピュータ技術 / ソフトウェアの標準と部品化 ( 戦術と戦略の誤解 / アジャイル開発 / リファクタリング / 遺産と再生産 / 標準と生産管理 ほか)

技術・開発の閑話-2- vol.01〜10 「ありえない」フェイルセーフと安全機能の連鎖 / HDD容量の差(天使の分け前) / リアルタイムとベストエフォート / エラーとコスト(ブルースクリーン/XP) / NDAと情報公開 / 専門ドメインの基礎範囲 / NHK技研公開(超高精細映像システム)

≪ 技術・開発の閑話 ：技術・開発コラム ≫