2009年09月28日
今日は弊社の製品であるexeGCCのVLINK(Virtual Link)機能について紹介します。
これはターゲットボードに弊社のPARTNER-Jetがつながっていれば、CPUとRAMしか動いていない状況でも使うことができます。
2009年09月24日
- DWARF と有限状態機械
- DWARF と有限状態機械 (2)
概要、プログラムヘッダときて、今回のバイトコードで行番号プログラムの仕様は最後です。
行番号プログラムの目的は、1つのコンパイル単位中の行番号情報表を構築することです。つまり、プログラムを実行すると、表が出力として得られます。
この表は、命令アドレス、ファイル名、行、列、各種位置フラグ(ブレークポイント関係など)など、有限状態機械の状態と1列が対応するようなものです。つまり、行番号プログラムの実行過程における有限状態機械の状態遷移の記録=行番号情報表となります。
この表において、命令アドレスは増加する一方ですが、行番号はコンパイラの最適化などによる命令の並び替えによって減少する場合もあります。
続きを読む
2009年09月18日
2009年09月16日
- DWARF と有限状態機械
前回は、どのようにして行番号情報が保持されているのかという概要、そして有限状態機械の仕様について説明しました。
今回は、具体的なヘッダのフォーマットを見ていきます。
デバッグ情報の自由なベンダー拡張を許しつつ、それをサポートしないデバッガでも独自拡張部分以外のデバッグ情報は正しく読めるような工夫がしてある点が面白いところだと思います。このしくみは実際に多用されていて、コンパイラベンダーごとに、様々な独自拡張が入ったDWARFが生成されるようです。
行番号プログラムヘッダ(The Line Number Program Header)は、以下のようなフォーマットになっています。
続きを読む
2009年09月14日
ソースレベルデバッガが最低限必要とする情報として、ソースコード中のプログラム行の位置と、対応するマシン命令アドレスの表があります。特にコンパイラによる高度な最適化が入ってくると、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日
（ただし、これはあくまでも私が理解したところなので、間違いが多分にあるかと思いますし、特にレビューを受けてもいない文章です。文責は私にあります。）
リアルタイムトレースとは、プログラムの実行中の 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レジスタが退避されていなかったので、そのソース修正も合わせて紹介します。
2009年09月02日
2009年08月31日
AndroidのDalvik VMではJavaのバイトコードから変換されたDXコードというものをインタープリタで実行しています。DXコードの中には浮動小数点演算を行うための命令もあるのですが、現状のDalvik VMではFPU命令を使わずにすべてソフトウェアによる浮動小数点演算のライブラリを呼び出しています。
Android SDKのシミュレータでは実はkernelとqemuはVFPが有効になっているのでFPU命令を使うことができます。そこでインタープリタのコードの浮動小数点の四則演算の部分をFPU命令を使うように書き換えて少し高速化してみました。
2009年08月28日
デバッガの肝の一つとして、ELF バイナリに入ってるデバッグ情報の解析があるのですが、そこらへんはほぼ全て社長と佐藤さんが行ってきたそうです。
私は入社してから今まで、ほぼずっとシミュレータ周りの開発をしてきましたので、どちらかというと PARTNER のコア部分とは少し離れた位置にいます。
しかし、デバッガベンダーに勤めていながら、全くデバッグ情報の解析について知らないというわけにもいかないので、少しずつ勉強していく過程をメモしていこうかと思います。
続きを読む
2009年08月26日
2009年08月24日
2009年08月21日
プログラミング言語 C 第2版の、奇妙な記述が気になりました。
「付録 C 変更点の要約」より引用。
・誰もが好きなつまらぬ変更：8 と 9 は 8 進数ではない。(p.328)
あまりにもさらっと書かれていますが、意味不明です。当たり前では ?
実は当たり前ではなくて、UNIX のアセンブラでは、8 と 9 は、8 進数の 10 と 11 として扱われていたんですね… いやはや。
「UNIX Assembler Reference Manual, Dennis M. Ritchie」
http://www.tom-yam.or.jp/2238/ref/as.pdf
An octal constant consists of a sequence of digits; ‘‘8’’ and ‘‘9’’ are taken to have octal value 10 and 11.
UNIX v6 以前のアセンブラの奇妙な習慣が、K&R の第1版まで脈々と続いていたわけです。UNIX と C の歴史は、こういうのがけっこう多いです。
2009年08月19日
PowerPCにはCPUのクロックサイクルでカウントアップされるタイムベースレジスタというカウンタがあります。これを利用して簡単にプログラムの2点間の時間を計測することができます。
ある関数を複数の方法で実装して、どちらが速いかを比較する場合に便利です。
手軽に使えるようにソースコードを一つのヘッダファイルにまとめてみました。
