2009年09月
2009年09月30日
GoogleのDiego Novillo氏が、GCCのtrunkに大量のパッチを投げました。
[LTO merge][0/15] Description of the final 15 patches
http://gcc.gnu.org/ml/gcc/2009-09/msg00578.html
http://gcc.gnu.org/ml/gcc-patches/2009-09/
ついにLTO(Link-Time Optimization)branchがGCC trunkにmergeされるようです。
続きを読む
[LTO merge][0/15] Description of the final 15 patches
http://gcc.gnu.org/ml/gcc/2009-09/msg00578.html
http://gcc.gnu.org/ml/gcc-patches/2009-09/
ついにLTO(Link-Time Optimization)branchがGCC trunkにmergeされるようです。
続きを読む
2009年09月28日
今日は弊社の製品であるexeGCCのVLINK(Virtual Link)機能について紹介します。
これはターゲットボードに弊社のPARTNER-Jetがつながっていれば、CPUとRAMしか動いていない状況でも使うことができます。
2009年09月24日
これまでの流れ
- DWARF と有限状態機械
- DWARF と有限状態機械 (2)
概要、プログラムヘッダときて、今回のバイトコードで行番号プログラムの仕様は最後です。
行番号プログラムの目的は、1つのコンパイル単位中の行番号情報表を構築することです。つまり、プログラムを実行すると、表が出力として得られます。
この表は、命令アドレス、ファイル名、行、列、各種位置フラグ(ブレークポイント関係など)など、有限状態機械の状態と1列が対応するようなものです。つまり、行番号プログラムの実行過程における有限状態機械の状態遷移の記録=行番号情報表となります。
この表において、命令アドレスは増加する一方ですが、行番号はコンパイラの最適化などによる命令の並び替えによって減少する場合もあります。
続きを読む
- DWARF と有限状態機械
- DWARF と有限状態機械 (2)
概要、プログラムヘッダときて、今回のバイトコードで行番号プログラムの仕様は最後です。
行番号プログラムの目的は、1つのコンパイル単位中の行番号情報表を構築することです。つまり、プログラムを実行すると、表が出力として得られます。
この表は、命令アドレス、ファイル名、行、列、各種位置フラグ(ブレークポイント関係など)など、有限状態機械の状態と1列が対応するようなものです。つまり、行番号プログラムの実行過程における有限状態機械の状態遷移の記録=行番号情報表となります。
この表において、命令アドレスは増加する一方ですが、行番号はコンパイラの最適化などによる命令の並び替えによって減少する場合もあります。
続きを読む
2009年09月16日
これまでの流れ
- DWARF と有限状態機械
前回は、どのようにして行番号情報が保持されているのかという概要、そして有限状態機械の仕様について説明しました。
今回は、具体的なヘッダのフォーマットを見ていきます。
デバッグ情報の自由なベンダー拡張を許しつつ、それをサポートしないデバッガでも独自拡張部分以外のデバッグ情報は正しく読めるような工夫がしてある点が面白いところだと思います。このしくみは実際に多用されていて、コンパイラベンダーごとに、様々な独自拡張が入ったDWARFが生成されるようです。
行番号プログラムヘッダ(The Line Number Program Header)は、以下のようなフォーマットになっています。
続きを読む
- DWARF と有限状態機械
前回は、どのようにして行番号情報が保持されているのかという概要、そして有限状態機械の仕様について説明しました。
今回は、具体的なヘッダのフォーマットを見ていきます。
デバッグ情報の自由なベンダー拡張を許しつつ、それをサポートしないデバッガでも独自拡張部分以外のデバッグ情報は正しく読めるような工夫がしてある点が面白いところだと思います。このしくみは実際に多用されていて、コンパイラベンダーごとに、様々な独自拡張が入ったDWARFが生成されるようです。
行番号プログラムヘッダ(The Line Number Program Header)は、以下のようなフォーマットになっています。
続きを読む
2009年09月14日
DWARF はソースレベルデバッギングのための情報をオブジェクトファイル中に保持する際のデータフォーマットです。
ソースレベルデバッガが最低限必要とする情報として、ソースコード中のプログラム行の位置と、対応するマシン命令アドレスの表があります。特にコンパイラによる高度な最適化が入ってくると、1つの行から不連続なアドレスにマシン命令が生成されるようになってくるので、デバッグ情報が無ければ、どこのアドレスにブレークポイントを張れば良いのか、ステップ実行の時にどこで止めれば良いのか、などが全くわからなくなってしまいます。
この対応表は非常に巨大なものに成り得るので、DWARFは対応表をそのまま持つのではなく、行番号プログラム(line number program)によって対応表を生成するという仕様になっています。これは、JVMの仮想機械語のようなバイトコードプログラムとなっています。具体的には、ソースコードのファイル名、行/列番号、命令アドレスなどを状態とする有限状態機械を定義し、その仮想機械のバイトコード列(= 行番号プログラム)をデバッグ情報として保持します。
続きを読む
ソースレベルデバッガが最低限必要とする情報として、ソースコード中のプログラム行の位置と、対応するマシン命令アドレスの表があります。特にコンパイラによる高度な最適化が入ってくると、1つの行から不連続なアドレスにマシン命令が生成されるようになってくるので、デバッグ情報が無ければ、どこのアドレスにブレークポイントを張れば良いのか、ステップ実行の時にどこで止めれば良いのか、などが全くわからなくなってしまいます。
この対応表は非常に巨大なものに成り得るので、DWARFは対応表をそのまま持つのではなく、行番号プログラム(line number program)によって対応表を生成するという仕様になっています。これは、JVMの仮想機械語のようなバイトコードプログラムとなっています。具体的には、ソースコードのファイル名、行/列番号、命令アドレスなどを状態とする有限状態機械を定義し、その仮想機械のバイトコード列(= 行番号プログラム)をデバッグ情報として保持します。
続きを読む
2009年09月10日
この記事ではgcc 4.4.0を使用しています。もっと新しいgccの場合はこちら。
2013年06月27日 ARMのNEONのSIMD命令をgccのオートベクタライズの最適化で使う方法
AndroidのSDKのgoldfishのCPUをcortex-A8に置き換えてNEONのSIMD命令を試す(その2) のときにはarm_neon.hに定義されているintrinsicsを使ってNEONのSIMD命令を生成させました。この方法だとNEONの命令について詳細を知っていなければなりませんし、なによりもそのプログラムがNEONに依存したものになってしまいます。
今回はコンパイラの最適化の機能を使ってNEONのSIMD命令を生成させるコツを紹介します。
2009年09月08日
ARM のリアルタイムトレースで、ETM と ETB という似たような用語が存在し、それぞれがどのようなものなのかイマイチ理解していなかったのですが、辻先輩に軽くレクチャーしていただいたので忘れないうちにメモしておきます。
（ただし、これはあくまでも私が理解したところなので、間違いが多分にあるかと思いますし、特にレビューを受けてもいない文章です。文責は私にあります。）
リアルタイムトレースとは、プログラムの実行中の PC の動きや、データアクセスの際のアドレスやアクセスタイプ (R/W) などをキャプチャーする機能のことです。基本的には CPU に負荷をかけずに済むので、実際にプログラムを動作させた時の CPU の状態遷移をそのまま見ることができます。(遅くなるものもあるそうです。)
組み込みではリアルタイム性が重要なプログラムが多いので、トレースは非常にデバッグの役に立つ機能です。弊社の PARTNER-Jet は、1 GB の大容量トレースを難なくこなし、QProbe という解析ツールと連携することもできます。(Model 40 の場合。)
ETM (Embedded Trace Macrocell) は、CPU (ARM CORE) のバスを監視し、トレース信号を外部に直接出力するためのユニットです。ETM はたくさん線が必要なのですが、チップの線は高価 (未確認ですが、1本線が増えるたびに、単価が0.5円上がるという話も) ですし、接続するためのプローブも単価が高いものになります。
ETB (Embedded Trace Buffer) は、その名の通り、ARM SoC 内の超高速メモリです。直接信号を出力するのではないため、トレースデータを取りこぼすこと無くためて置くことができます。ただし、SoC 内のシリコンには限りがあるのでそれほど大容量にはできませんし、JTAG 経由でデータを吸いだす必要があります。特別なプローブが必要無く、JTAG のみで済むというのはメリットでもあります。
簡単ですが、以上を図にまとめると、以下のようになるかと思います。
（ただし、これはあくまでも私が理解したところなので、間違いが多分にあるかと思いますし、特にレビューを受けてもいない文章です。文責は私にあります。）
リアルタイムトレースとは、プログラムの実行中の PC の動きや、データアクセスの際のアドレスやアクセスタイプ (R/W) などをキャプチャーする機能のことです。基本的には CPU に負荷をかけずに済むので、実際にプログラムを動作させた時の CPU の状態遷移をそのまま見ることができます。(遅くなるものもあるそうです。)
組み込みではリアルタイム性が重要なプログラムが多いので、トレースは非常にデバッグの役に立つ機能です。弊社の PARTNER-Jet は、1 GB の大容量トレースを難なくこなし、QProbe という解析ツールと連携することもできます。(Model 40 の場合。)
ETM (Embedded Trace Macrocell) は、CPU (ARM CORE) のバスを監視し、トレース信号を外部に直接出力するためのユニットです。ETM はたくさん線が必要なのですが、チップの線は高価 (未確認ですが、1本線が増えるたびに、単価が0.5円上がるという話も) ですし、接続するためのプローブも単価が高いものになります。
ETB (Embedded Trace Buffer) は、その名の通り、ARM SoC 内の超高速メモリです。直接信号を出力するのではないため、トレースデータを取りこぼすこと無くためて置くことができます。ただし、SoC 内のシリコンには限りがあるのでそれほど大容量にはできませんし、JTAG 経由でデータを吸いだす必要があります。特別なプローブが必要無く、JTAG のみで済むというのはメリットでもあります。
簡単ですが、以上を図にまとめると、以下のようになるかと思います。
2009年09月04日
これまで2回に渡ってDalvikVMのインタープリタの部分でFPU命令を使って高速化する変更方法を紹介しました。
残りのCの部分で書いてある部分もコンパイルオプションを変えればFPU命令を使うようになるはずです。ソースをながめてみるとsetjmpの部分でFPUレジスタが退避されていなかったので、そのソース修正も合わせて紹介します。
