2009年10月20日

エミュレータとシミュレータという用語の使い分けについて、私自身もいろいろ混乱していたところがあったので、ここでもう一度考えてみようと思います。

続きを読む

2009年10月16日

以前の記事で使用した 「リアルタイムトレース」 という用語は、KMC が製品の特徴を一言で伝えるためのキーワードとして使用している独自の用語であり、一般的な技術用語では無いので、社外や blog などで使用する時は注意が必要、という指摘を辻さんからいただきました。ありがとうございます。

ARM の ETM/ETB などのトレース機能は、例えばバッファに一時的にトレースデータをため、タイムスタンプなどはパケットがまとめて送信される時に付くので、厳密には本当にリアルタイムではないのだそうです。ARM 社などが「リアルタイム」という用語をあえて避けているのは、その辺の誤解を嫌ってのことなのでしょう。

KMC が「リアルタイムトレース」と言う時のリアルタイムとは、厳密な技術用語の文脈の「リアルタイム」ではなく、「プログラムの実行を止めなくても、動かしながらトレースログを見れる」という意味で使用しています。

例えばリアルタイム OS と言った場合には、スケジューリングや割り込み、システムコールなどの各種処理の実行時間の予測可能性が保証されている、という意味であるように、リアルタイムという用語には様々な技術的文脈でいろいろな意味があるので、説明無しに「リアルタイム」という用語を使ってしまったのは我ながら軽率だったと思います。技術者たるもの、誤解やすれ違いを避けるために、用語の使い方には常に気をつけたいものです。

2009年10月14日

前回exeGCCのVLINK機能を利用してPARTNERのコマンドウインドウで動く対話的なコンソールアプリケーションを作る例を紹介しました。今回は逆にバッチ処理で便利なようにVLINKでコマンドラインの引数を取得する例を紹介します。

続きを読む

2009年10月08日

twitter で gas の構文は理解しにくいと hmori さんがつぶやいていたのを見て、意外と知られて無さそうなので書きます。

x86 と x86-64 において、gas と GCC が出力するアセンブリコードのデフォルト構文は AT&T 構文と呼ばれる UNIX アセンブラの伝統的な構文です。プログラミングの力を生み出す本や、ふつうのコンパイラをつくろうなど、最初から一貫して AT&T 構文を元にアセンブリプログラミングを解説している書籍も無いことは無いのですが、確かにintel のマニュアルの構文とは引数の順番などが異なるので、慣れないと混乱の元になるのではないかと思います。

また、%レジスタや$即値などの独特のプリフィクスが大量に付くので、見た目が少しゴチャゴチャするようにも感じます。(movl などの b/w/l のように、データ長を指定するサフィックスも便利と言えば便利なのですが、区切りが紛らわしい気もします。サフィックスを付けるならば、mov.l のように区切りがある方が、個人的には好みです。ちょっと脱線しました。)

実は gas (GNU Assembler) は、バージョン 2.10 から、インテル構文 (intel syntax) もサポートしています。

続きを読む

2009年10月06日

前回exeGCCのVLINK機能を使ってターゲット側からホストPCの標準入出力を利用することができることを説明しました。

今回はコマンドウィンドウへのキー入力を拾って対話的なプログラムをつくる時の具体例を紹介します。

続きを読む

2009年10月02日

GDBの7.0からReverse Debugging(ヒストリの逆実行)が入るということで、一部で話題になっているようです。

http://www.gnu.org/software/gdb/news/reversible.html
http://d.hatena.ne.jp/hayamiz/20090930/1254323169

(ネタ元は、私がtwitterに張ったURLのようです。すごいブックマークの数ですね。)

ちなみに私は、greenteaさんの獲物で知ったのですが、同僚の佐藤さんやkobaさん、社長などは既に知っていました。

この機能は、GCC Summit 2007で発表されたようです。
http://ols.108.redhat.com/2007/GCC-Reprints/GCC2007-Proceedings.pdf
"Reversible Debugging", Paul Brook(CodeSourcery), Daniel Jacobowitz (CodeSourcery), pp.69-76

佐藤さん曰く、Non-stop multi-threaded debuggingも地味だけど面白いとのことです。

続きを読む

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されるようです。

続きを読む

2009年09月28日

今日は弊社の製品であるexeGCCのVLINK(Virtual Link)機能について紹介します。

これはターゲットボードに弊社のPARTNER-Jetがつながっていれば、CPUとRAMしか動いていない状況でも使うことができます。

続きを読む

2009年09月24日

これまでの流れ

- DWARF と有限状態機械
- DWARF と有限状態機械 (2)


概要、プログラムヘッダときて、今回のバイトコードで行番号プログラムの仕様は最後です。

行番号プログラムの目的は、1つのコンパイル単位中の行番号情報表を構築することです。つまり、プログラムを実行すると、表が出力として得られます。

この表は、命令アドレス、ファイル名、行、列、各種位置フラグ(ブレークポイント関係など)など、有限状態機械の状態と1列が対応するようなものです。つまり、行番号プログラムの実行過程における有限状態機械の状態遷移の記録=行番号情報表となります。
この表において、命令アドレスは増加する一方ですが、行番号はコンパイラの最適化などによる命令の並び替えによって減少する場合もあります。

続きを読む

2009年09月18日

私がよく使うgccの便利なオプションをまたひとつ紹介します。

gccのコマンドラインオプションをちょっと調べたいときには、gcc自身のhelpが便利です。

続きを読む

2009年09月16日

これまでの流れ

- DWARF と有限状態機械

前回は、どのようにして行番号情報が保持されているのかという概要、そして有限状態機械の仕様について説明しました。
今回は、具体的なヘッダのフォーマットを見ていきます。

デバッグ情報の自由なベンダー拡張を許しつつ、それをサポートしないデバッガでも独自拡張部分以外のデバッグ情報は正しく読めるような工夫がしてある点が面白いところだと思います。このしくみは実際に多用されていて、コンパイラベンダーごとに、様々な独自拡張が入ったDWARFが生成されるようです。

行番号プログラムヘッダ(The Line Number Program Header)は、以下のようなフォーマットになっています。

続きを読む

2009年09月14日

DWARF はソースレベルデバッギングのための情報をオブジェクトファイル中に保持する際のデータフォーマットです。

ソースレベルデバッガが最低限必要とする情報として、ソースコード中のプログラム行の位置と、対応するマシン命令アドレスの表があります。特にコンパイラによる高度な最適化が入ってくると、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 のみで済むというのはメリットでもあります。

簡単ですが、以上を図にまとめると、以下のようになるかと思います。

リアルタイムトレース説明図

2009年09月04日

これまで2回に渡ってDalvikVMのインタープリタの部分でFPU命令を使って高速化する変更方法を紹介しました。

残りのCの部分で書いてある部分もコンパイルオプションを変えればFPU命令を使うようになるはずです。ソースをながめてみるとsetjmpの部分でFPUレジスタが退避されていなかったので、そのソース修正も合わせて紹介します。

続きを読む

記事検索
最新コメント
アクセスカウンター
  • 今日:
  • 昨日:
  • 累計:

QRコード
QRコード