2009年07月10日
巷ではプログラマ 35 歳定年説なるものがまことしやかに囁かれているそうです。
私は KMC 以外の会社を知らないのでなんとも言えないのですが、これはどうやら新しいことが覚えられなくなってくるなどの能力的な限界というよりは、単に技術者のキャリアパスが十分に整備されていないため、ある程度以上の年齢で正当な待遇を得るためには、向き不向き関係なく、技術者から管理者に否応なしにシフトせざるをえないという現状に対する嘆きのようです。
一方 KMC 社内を見渡してみると、なんと 35 歳以下の技術者がほとんどいません（笑）社長と CTO が、ともに 50 間近にして現役の技術者です。というよりもむしろ、社内で最も多く、かつ重要なコードを書いているのがこのお二方だと思います。
この間、社内のソースコード管理システムが変わり、社長困ってるんじゃないのかなとひそかに心配していたのですが、全くの杞憂でした。「git 便利やわ〜、ちょっとまだ不安定で master に入れるのが怖い状態の時、ローカルに branch 切って置いておけるもんな」と、普通に使いこなしていました。
組み込み業界はただでさえ年齢層が高めと言われますし、25 年以上の歴史を持つ老舗デバッガベンダーというと、なんとなく保守的なイメージを持たれている方もいるかもしれません。もちろん、これまで積み重ねてきた信頼と実績を守るために、重要な製品コア部分そのものの変更には慎重ですが、それ以外の技術、例えば最近は redmine という Ruby on Rails で組まれたバグトラッキングシステムが運用されていたりと、活発に新しい技術に取り組んでいく風土が社内にあります。
そもそもこのブログ自体が、わりと組み込み業界では珍しい試みなのではないかと思います。非常に狭い業界ですから、社外秘や NDA は当然としても、それ以外にもうっかり書いてしまうとまずいことがたくさんあったりするようです。このブログを始める際、正直不安もありましたが、社長が「失敗を必要以上に恐れていたら、新しいことはできへん」というスタイルなので、だいぶ救われています。
私は KMC 以外の会社を知らないのでなんとも言えないのですが、これはどうやら新しいことが覚えられなくなってくるなどの能力的な限界というよりは、単に技術者のキャリアパスが十分に整備されていないため、ある程度以上の年齢で正当な待遇を得るためには、向き不向き関係なく、技術者から管理者に否応なしにシフトせざるをえないという現状に対する嘆きのようです。
一方 KMC 社内を見渡してみると、なんと 35 歳以下の技術者がほとんどいません（笑）社長と CTO が、ともに 50 間近にして現役の技術者です。というよりもむしろ、社内で最も多く、かつ重要なコードを書いているのがこのお二方だと思います。
この間、社内のソースコード管理システムが変わり、社長困ってるんじゃないのかなとひそかに心配していたのですが、全くの杞憂でした。「git 便利やわ〜、ちょっとまだ不安定で master に入れるのが怖い状態の時、ローカルに branch 切って置いておけるもんな」と、普通に使いこなしていました。
組み込み業界はただでさえ年齢層が高めと言われますし、25 年以上の歴史を持つ老舗デバッガベンダーというと、なんとなく保守的なイメージを持たれている方もいるかもしれません。もちろん、これまで積み重ねてきた信頼と実績を守るために、重要な製品コア部分そのものの変更には慎重ですが、それ以外の技術、例えば最近は redmine という Ruby on Rails で組まれたバグトラッキングシステムが運用されていたりと、活発に新しい技術に取り組んでいく風土が社内にあります。
そもそもこのブログ自体が、わりと組み込み業界では珍しい試みなのではないかと思います。非常に狭い業界ですから、社外秘や NDA は当然としても、それ以外にもうっかり書いてしまうとまずいことがたくさんあったりするようです。このブログを始める際、正直不安もありましたが、社長が「失敗を必要以上に恐れていたら、新しいことはできへん」というスタイルなので、だいぶ救われています。
2009年07月09日
KMC に入社して、初めて JTAG-ICE デバッガを触った時は感動しました。(と言っても、わずか半年ほど前なのですが。)
それまで私は PC の世界しか知らなかったので、いきなり CPU (たしか、たまたま社長の手元にあった MIPS ボード ?) が剥き出しの基板を渡されても、「これで一体何をどうすれば良いのだろうか…」と戸惑ってしまいました。
PC の上でプログラムを書いていた時、いかに自分が分厚く抽象化された世界の上で生きていたのかということを実感させられます。シェルはもちろん、OS も何も無い世界。当然ディスプレイもマウスもキーボードも、つながるインタフェースすらありませんし、唯一存在している NIC も、ドライバが無いのでそんなに簡単には動かせません。はてさてどうしたものか。
すると社長が慣れた手つきで、ささっと JTAG コネクタにケーブルを指して、JET と PC をつないでデバッガを起動してくれました。PARTNER デバッガは ELF を理解するので、GCC などのクロスコンパイラが生成した実行ファイルをそのままロードできるのですが、これだけでも驚きました。そしてそのままステップ実行できる。全てのメモリが見える。レジスタの値も何もかも自由に変えられる。すごいと思いました。
次に感動したのは、シリアルコンソールがつながった時でした。もちろんシリアルコンソールなんて使ったのは初めてでした。最終的には、最も素朴なメモリマップト I/O を叩くわけで、printf とかも最終的にはこういう風なところに落ちるんだなぁと、もちろんそれまで知識は多少あったわけですが、やはり実際に経験してみたことにより、ふっと腑に落ちてつながる感覚がありました。
プログラミングの入門書の一番最初の例題である printf が出るまでには、シェルが動いてローダが動いて OS が動いてドライバが動いて… 数え切れない抽象化層を経由して、GUI が作り出した仮想のコンソールの上に文字が出るわけです。
そういう抽象化層を全て取っ払った世界にいきなり入ることが出来る。やはり JTAG-ICE デバッガの感動は、実際に味わってみるのが一番ではないかと思います。組み込み業界の社会人だけではなく、むしろ学生さんにこそデバッガ使って欲しいなと思ったりもします。CPU を身近に感じられ、教育用にも最高なのではないかと思います。
この直接 CPU を操作できるという JTAG-ICE デバッガのメリットは、開発や教育だけでは無く、実は意外なことに、CPU シミュレータ作成においても大変魅力的だと私は個人的に思っています。
CPU のシミュレータだけ作っても、基本的には何もできません。I/O メモリを実装して、割り込みが動くようにして、シリアルコントローラや NIC などの仮想ハードウェアエミュレーションを実装して、プログラムをロードするしくみを作って… 実際に、QEMU などのエミュレータでは、自前の ELF ローダや、I/O デバイスや UI という、ある意味では非本質的な部分に非常に多くの労力が割かれています。
デバッガがあれば、CPU とデバッガをつなぐ部分 (デバッガにレジスタやメモリの値を渡す通信のしくみ。簡略化された JTAG インタファースを、ソフトウェア的に実装するようなイメージ) さえ実装すれば、あとは PARTNER デバッガソフトウェアの汎用的なしくみをそのまままるごと利用することができます。ローダなどの再実装は不要で、いきなり ELF をシミュレータのメモリにロードして実行することができます。OS もシェルも何も動いていなくても、PARTNER のマクロ機能を使えば、様々なテストが自動化可能です。
私は今、PARTNER に直接つながるシミュレータを研究開発しているわけですが、自分で書いた（と言っても、基本部分を社長が既に実装したものを引きついだのですが） ARM シミュレータに PARTNER がつながって、実機と同様に動いてデバッグできるというのは、ものすごく楽しくてうれしいものです。このシミュレータの上で、これまた自分で移植した Linux が動いた時が、第三の感動でした。
それまで私は PC の世界しか知らなかったので、いきなり CPU (たしか、たまたま社長の手元にあった MIPS ボード ?) が剥き出しの基板を渡されても、「これで一体何をどうすれば良いのだろうか…」と戸惑ってしまいました。
PC の上でプログラムを書いていた時、いかに自分が分厚く抽象化された世界の上で生きていたのかということを実感させられます。シェルはもちろん、OS も何も無い世界。当然ディスプレイもマウスもキーボードも、つながるインタフェースすらありませんし、唯一存在している NIC も、ドライバが無いのでそんなに簡単には動かせません。はてさてどうしたものか。
すると社長が慣れた手つきで、ささっと JTAG コネクタにケーブルを指して、JET と PC をつないでデバッガを起動してくれました。PARTNER デバッガは ELF を理解するので、GCC などのクロスコンパイラが生成した実行ファイルをそのままロードできるのですが、これだけでも驚きました。そしてそのままステップ実行できる。全てのメモリが見える。レジスタの値も何もかも自由に変えられる。すごいと思いました。
次に感動したのは、シリアルコンソールがつながった時でした。もちろんシリアルコンソールなんて使ったのは初めてでした。最終的には、最も素朴なメモリマップト I/O を叩くわけで、printf とかも最終的にはこういう風なところに落ちるんだなぁと、もちろんそれまで知識は多少あったわけですが、やはり実際に経験してみたことにより、ふっと腑に落ちてつながる感覚がありました。
プログラミングの入門書の一番最初の例題である printf が出るまでには、シェルが動いてローダが動いて OS が動いてドライバが動いて… 数え切れない抽象化層を経由して、GUI が作り出した仮想のコンソールの上に文字が出るわけです。
そういう抽象化層を全て取っ払った世界にいきなり入ることが出来る。やはり JTAG-ICE デバッガの感動は、実際に味わってみるのが一番ではないかと思います。組み込み業界の社会人だけではなく、むしろ学生さんにこそデバッガ使って欲しいなと思ったりもします。CPU を身近に感じられ、教育用にも最高なのではないかと思います。
この直接 CPU を操作できるという JTAG-ICE デバッガのメリットは、開発や教育だけでは無く、実は意外なことに、CPU シミュレータ作成においても大変魅力的だと私は個人的に思っています。
CPU のシミュレータだけ作っても、基本的には何もできません。I/O メモリを実装して、割り込みが動くようにして、シリアルコントローラや NIC などの仮想ハードウェアエミュレーションを実装して、プログラムをロードするしくみを作って… 実際に、QEMU などのエミュレータでは、自前の ELF ローダや、I/O デバイスや UI という、ある意味では非本質的な部分に非常に多くの労力が割かれています。
デバッガがあれば、CPU とデバッガをつなぐ部分 (デバッガにレジスタやメモリの値を渡す通信のしくみ。簡略化された JTAG インタファースを、ソフトウェア的に実装するようなイメージ) さえ実装すれば、あとは PARTNER デバッガソフトウェアの汎用的なしくみをそのまままるごと利用することができます。ローダなどの再実装は不要で、いきなり ELF をシミュレータのメモリにロードして実行することができます。OS もシェルも何も動いていなくても、PARTNER のマクロ機能を使えば、様々なテストが自動化可能です。
私は今、PARTNER に直接つながるシミュレータを研究開発しているわけですが、自分で書いた（と言っても、基本部分を社長が既に実装したものを引きついだのですが） ARM シミュレータに PARTNER がつながって、実機と同様に動いてデバッグできるというのは、ものすごく楽しくてうれしいものです。このシミュレータの上で、これまた自分で移植した Linux が動いた時が、第三の感動でした。
2009年07月08日
PARTNER-Jet には、イベントトラッカーという機能が標準で搭載されています。
http://www.kmckk.co.jp/event_tracker/index.html
イベントというと何やら難しそうですが、ここでいうイベントとは「ターゲットプログラムの実行中に、なんらかの変化が起こった」ということを指します。例えば OS のタスク切り替えや、OS が無い場合は pc が特定のアドレスに来た場合など、任意の状態変化をイベントとしてユーザ定義することができます。
イベントトラッカーは、メモリに記録したログデータをグラフィカルに表示・解析するための汎用的なしくみを提供します。
組み込みソフトウェア開発で printf デバッグができるのは、けっこう恵まれた状況です。開発初期はシリアルコンソールすらつながっておらず、一切の I/O が使えない状況がけっこうあります。
PARTNER-Jet のような JTAG-ICE デバッガを使えば、そのような状況でも、とりあえずステップ実行をしてプログラムの動きを追うことができます。しかし、割り込み処理など、タイミングが重要なプログラムをデバッグする際には、これだけでは厳しいです。
PARTNER-Jet には、VLINK という、ターゲット上で動くプログラムから直接デバッガに printf などで出力できるという機能もあるのですが、そもそも printf 自体が比較的重い処理となるため、RTOS などのイベントハンドラの中で呼ぶことは厳しいですし、printf を呼ぶとタイミングが狂って再現しなくなってしまうバグなどもありがちです。
このような場合、イベントトラッカーが威力を発揮します。イベントトラッカーは、JTAG がつながって、メモリの読み書きができて、ログ用のバッファが確保できる状況ならば使えます。しくみが単純で処理が軽いぶん、様々な場面に使える、非常に一般的なデバッグ手法と言えます。
OS を使う場合は、Linux や各種 RTOS (T-Kernel や Toppers) など、それぞれの OS ごとに KMC が提供するパッチを当てることにより、プロセスの切り替えなどのタイミングを詳細に記録することができます。
OS が無い場合は、直接 KMC が提供するヘッダとソースコードをプロジェクトに組み込み、初期化関数を読んだ後、任意のタイミングでイベント発行関数(引数に与えられた整数がイベントとして記録されます)を呼ぶことで、イベントログを取ることができます。1 ヘッダと 1 ファイルのみなので、カスタマイズも簡単にできます。
イベントトラッカーがやっていること自体は特別なことではなく、多かれ少なかれ、どこの組み込み開発でもアドホックに行われていることだと思います。しかし、デバッガと連携した汎用のしくみが最初から提供されることにより、CPU 占有時間の計算やイベントの抽出・マスク機能など、高度な表示や統計・解析機能が簡便に使えるようになり、工数が削減できます。また、しくみが共通化されることにより、デバッグの属人性が薄まり、ノウハウの共通化が可能になるため、開発そのものだけではなく、技術教育面などにも恩恵があると考えられます。
http://www.kmckk.co.jp/event_tracker/index.html
イベントというと何やら難しそうですが、ここでいうイベントとは「ターゲットプログラムの実行中に、なんらかの変化が起こった」ということを指します。例えば OS のタスク切り替えや、OS が無い場合は pc が特定のアドレスに来た場合など、任意の状態変化をイベントとしてユーザ定義することができます。
イベントトラッカーは、メモリに記録したログデータをグラフィカルに表示・解析するための汎用的なしくみを提供します。
組み込みソフトウェア開発で printf デバッグができるのは、けっこう恵まれた状況です。開発初期はシリアルコンソールすらつながっておらず、一切の I/O が使えない状況がけっこうあります。
PARTNER-Jet のような JTAG-ICE デバッガを使えば、そのような状況でも、とりあえずステップ実行をしてプログラムの動きを追うことができます。しかし、割り込み処理など、タイミングが重要なプログラムをデバッグする際には、これだけでは厳しいです。
PARTNER-Jet には、VLINK という、ターゲット上で動くプログラムから直接デバッガに printf などで出力できるという機能もあるのですが、そもそも printf 自体が比較的重い処理となるため、RTOS などのイベントハンドラの中で呼ぶことは厳しいですし、printf を呼ぶとタイミングが狂って再現しなくなってしまうバグなどもありがちです。
このような場合、イベントトラッカーが威力を発揮します。イベントトラッカーは、JTAG がつながって、メモリの読み書きができて、ログ用のバッファが確保できる状況ならば使えます。しくみが単純で処理が軽いぶん、様々な場面に使える、非常に一般的なデバッグ手法と言えます。
OS を使う場合は、Linux や各種 RTOS (T-Kernel や Toppers) など、それぞれの OS ごとに KMC が提供するパッチを当てることにより、プロセスの切り替えなどのタイミングを詳細に記録することができます。
OS が無い場合は、直接 KMC が提供するヘッダとソースコードをプロジェクトに組み込み、初期化関数を読んだ後、任意のタイミングでイベント発行関数(引数に与えられた整数がイベントとして記録されます)を呼ぶことで、イベントログを取ることができます。1 ヘッダと 1 ファイルのみなので、カスタマイズも簡単にできます。
イベントトラッカーがやっていること自体は特別なことではなく、多かれ少なかれ、どこの組み込み開発でもアドホックに行われていることだと思います。しかし、デバッガと連携した汎用のしくみが最初から提供されることにより、CPU 占有時間の計算やイベントの抽出・マスク機能など、高度な表示や統計・解析機能が簡便に使えるようになり、工数が削減できます。また、しくみが共通化されることにより、デバッグの属人性が薄まり、ノウハウの共通化が可能になるため、開発そのものだけではなく、技術教育面などにも恩恵があると考えられます。
2009年07月07日
皆さん、こんにちは。KMCの辻です。
さて、今日はPARTNER-Jet ver5.6に搭載した新しい機能「スナップショットデバッガ」についてお話します。
PARTNER-Jet ver5.6は、つい先日に僕たちがリリースした、新バージョンデバッガです。この新バージョンデバッガには、新たに「スナップショットデバッガ」という機能を追加しました。
このスナップショットデバッガを一口で説明すると、「コアダンプのCPU版」という感じでしょうか。UNIX上でのcoreファイルを使ったデバッグに似ています。PARTNER-Jetを使ってターゲットボードのソフトウェアをデバッグしている時に、デバッガ上からスナップショットを作成します。その後は、作成したスナップショットファイルを用いて、ターゲットボードなしにオフラインでデバッグを行う、という機能です。オフラインでのデバッグになるので、CPUの実行に関する事はできませんが、その他のデバッガの機能はほぼ全て利用可能です。
スナップショットファイルには、それを作成した時点でのメモリの内容とCPUの汎用レジスタや制御レジスタの情報などのほかに、PARTNER-Jetで採取していたETMやAUDなどの実行トレースの内容も保存しています。トレースデータを参照すれば、そこに至る過程も調べる事もできます。
私的な話になりますが、僕はその昔に通信機器のOSの開発をしていた事があります。電話網に使われる通信機器ですので、耐障害性など品質については厳しく”全てのバグを取り除く”という意識でのソフトウェア開発でした。しかし、難解なバグや再現性の低いバグも多く、そのようなバグ調査に実機を長時間占有させておくことも難しい事も事実でした。そのような状況でも、障害発生時に保存した実機のメモリを、ワークステーション上で解析をしてバグ対策を行っていました。また、同じ問題を一人ではなく複数人で解析したり、ファイルを転送して離れた場所の人と一緒に解析したりしていました。当時は物理メモリのファイルと、そしてシンボルデータをつき合わせて、構造体などをメモ書きしながら解析をしていました。
もちろん、このスナップショットデバッガを利用すれば、より快適にこのような作業を行うことができます（当時は本当に根性デバッグで大変でした）。
これからは、問題が発生した時には、スナップショットを保存しておくのはどうでしょうか？
さて、今日はPARTNER-Jet ver5.6に搭載した新しい機能「スナップショットデバッガ」についてお話します。
PARTNER-Jet ver5.6は、つい先日に僕たちがリリースした、新バージョンデバッガです。この新バージョンデバッガには、新たに「スナップショットデバッガ」という機能を追加しました。
このスナップショットデバッガを一口で説明すると、「コアダンプのCPU版」という感じでしょうか。UNIX上でのcoreファイルを使ったデバッグに似ています。PARTNER-Jetを使ってターゲットボードのソフトウェアをデバッグしている時に、デバッガ上からスナップショットを作成します。その後は、作成したスナップショットファイルを用いて、ターゲットボードなしにオフラインでデバッグを行う、という機能です。オフラインでのデバッグになるので、CPUの実行に関する事はできませんが、その他のデバッガの機能はほぼ全て利用可能です。
スナップショットファイルには、それを作成した時点でのメモリの内容とCPUの汎用レジスタや制御レジスタの情報などのほかに、PARTNER-Jetで採取していたETMやAUDなどの実行トレースの内容も保存しています。トレースデータを参照すれば、そこに至る過程も調べる事もできます。
私的な話になりますが、僕はその昔に通信機器のOSの開発をしていた事があります。電話網に使われる通信機器ですので、耐障害性など品質については厳しく”全てのバグを取り除く”という意識でのソフトウェア開発でした。しかし、難解なバグや再現性の低いバグも多く、そのようなバグ調査に実機を長時間占有させておくことも難しい事も事実でした。そのような状況でも、障害発生時に保存した実機のメモリを、ワークステーション上で解析をしてバグ対策を行っていました。また、同じ問題を一人ではなく複数人で解析したり、ファイルを転送して離れた場所の人と一緒に解析したりしていました。当時は物理メモリのファイルと、そしてシンボルデータをつき合わせて、構造体などをメモ書きしながら解析をしていました。
もちろん、このスナップショットデバッガを利用すれば、より快適にこのような作業を行うことができます（当時は本当に根性デバッグで大変でした）。
これからは、問題が発生した時には、スナップショットを保存しておくのはどうでしょうか？
2009年07月07日
前回に続いてもう少しgccのビルドイン関数を見ていきます。
gccはとてもたくさんのビルトイン関数があります。
オンラインマニュアルのこのページにリストがあります。
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Other-Builtins.html#Other-Builtins
標準の数学関数はほとんどがビルトイン関数になっています。引数が定数の場合にはコンパイル時に計算されてしまいます。
具体例を見てみましょう。
2009年07月06日
デバッガを作ってる会社と言われても、なかなか外からは何をやってるか想像できないのではないかと思います。この記事では、あまり組み込み業界に馴染みが無い方向けに、少し会社の仕事内容を説明してみたいと思います。
KMC が販売しているデバッガは、通常の PC の上で使われる VisualStudio のデバッガや GDB などとは少し異なり、JTAG-ICE デバッガと呼ばれる組み込みソフトウェア開発向けのデバッガです。
もともと ICE (In-Circuit Emulator) という用語は、CPU のデバッグのために作られた回路内のエミュレータ、つまりハードウェアのことを指していたのですが、現在ではその範囲が拡大され、デバッグのためのソフトウェア/ハードウェアをかなり広範囲に含む用語となっています（私の解釈。人それぞれ用語の使い方がけっこう違ったりします）。
PARTNER-Jet という、KMC の主力製品は、大きく分けて Jet という CPU の JTAG インタフェースを使って高速通信するためのハードウェア(通称、箱＜ボックス＞)と、PC の上で動くデバッガソフトウェアで構成されます。
デバッガ本体を作るだけでも、JTAG のプログラミング、高速化のためのハードウェア技術 (FPGA など)、CPU ごとの様々な対応、デバッグ情報の解釈系、わかりやすく表示するための UI 技術など、非常に高度で専門的なプログラミング技術がいくつも必要とされます。
（ちなみに、デバッガのデバッグにも、当然のことながらデバッガが必要で、KMC は PC の上で動くデバッガも社内用に開発し、開発メンバーは毎日使ってます。プログラミングが高度になればなるほど、デバッガの重要性も高まるわけなので、デバッガ自体を開発/改良できる KMC は非常に良い循環ができていると言えます。）
もちろんデバッガの新機能を開発したり、サポートや保守を行う人が多いのですが、そればかりではありません。ソフトウェアを製品にして、営業・販売するまでには、たくさんの人たちの様々な仕事が必要です。
まず、デバッガは非常に多機能なので、機能をわかりやすく説明するマニュアル類などの整備が必要です。(海外用の英訳なども含む)。また、デバッガは、ドライバ類からデバッガソフトウェアまで多数のコンポーネントで構成されているので、インストールのしやすさも重要です。
デバッガの機能をお客様に説明し、使っていただくためには、営業スタッフの方々のデモが必要です。(開発ツールを販売するという KMC の仕事の性質上、営業スタッフには、ある程度の技術力や開発経験が求められます。そのためほとんどの方が元技術者か、あるいは今でも現役の技術者です。よく噂に聞く、開発スタッフと営業スタッフの対立や相互無理解などは、KMC には無縁です。)
そしてその際には、各ターゲット CPU ごとのボードが必須なので、KMC は自社製ボードも開発しています。ボードの設計や製造管理、検査を行うことも、デバッガベンダーには欠かせない重要なお仕事です。
また、デバッガの能力を高め、連携するための各種製品開発も重要です。exeGCC という GCC を組み込み向けにカスタマイズしたものや、Eclipse のデバッガ用プラグインなどを開発している人たちもいます。
こうして見ると非常に幅広い業務内容ですが、KMC は 10 数人という少人数で対応しています。コンパイラ、デバッガ、ターゲット(実機) など多様な技術を、大企業のような分業制では無く、一つのオフィスの中で全て掌握し、頻繁なコミュニケーションを取っていることにより、仕事や発想の幅が広がると思います。そしてこれこそが、KMC の良さであり、強さの源なのではないかと個人的には思っています。
私自身は、デバッガとつながる CPU シミュレータという、少し他の人たちとは毛色が異なる研究開発を今のところメインでやっているのですが、少し長くなりましたので、またの機会に話そうかなと思います。続きを読む
KMC が販売しているデバッガは、通常の PC の上で使われる VisualStudio のデバッガや GDB などとは少し異なり、JTAG-ICE デバッガと呼ばれる組み込みソフトウェア開発向けのデバッガです。
もともと ICE (In-Circuit Emulator) という用語は、CPU のデバッグのために作られた回路内のエミュレータ、つまりハードウェアのことを指していたのですが、現在ではその範囲が拡大され、デバッグのためのソフトウェア/ハードウェアをかなり広範囲に含む用語となっています（私の解釈。人それぞれ用語の使い方がけっこう違ったりします）。
PARTNER-Jet という、KMC の主力製品は、大きく分けて Jet という CPU の JTAG インタフェースを使って高速通信するためのハードウェア(通称、箱＜ボックス＞)と、PC の上で動くデバッガソフトウェアで構成されます。
デバッガ本体を作るだけでも、JTAG のプログラミング、高速化のためのハードウェア技術 (FPGA など)、CPU ごとの様々な対応、デバッグ情報の解釈系、わかりやすく表示するための UI 技術など、非常に高度で専門的なプログラミング技術がいくつも必要とされます。
（ちなみに、デバッガのデバッグにも、当然のことながらデバッガが必要で、KMC は PC の上で動くデバッガも社内用に開発し、開発メンバーは毎日使ってます。プログラミングが高度になればなるほど、デバッガの重要性も高まるわけなので、デバッガ自体を開発/改良できる KMC は非常に良い循環ができていると言えます。）
もちろんデバッガの新機能を開発したり、サポートや保守を行う人が多いのですが、そればかりではありません。ソフトウェアを製品にして、営業・販売するまでには、たくさんの人たちの様々な仕事が必要です。
まず、デバッガは非常に多機能なので、機能をわかりやすく説明するマニュアル類などの整備が必要です。(海外用の英訳なども含む)。また、デバッガは、ドライバ類からデバッガソフトウェアまで多数のコンポーネントで構成されているので、インストールのしやすさも重要です。
デバッガの機能をお客様に説明し、使っていただくためには、営業スタッフの方々のデモが必要です。(開発ツールを販売するという KMC の仕事の性質上、営業スタッフには、ある程度の技術力や開発経験が求められます。そのためほとんどの方が元技術者か、あるいは今でも現役の技術者です。よく噂に聞く、開発スタッフと営業スタッフの対立や相互無理解などは、KMC には無縁です。)
そしてその際には、各ターゲット CPU ごとのボードが必須なので、KMC は自社製ボードも開発しています。ボードの設計や製造管理、検査を行うことも、デバッガベンダーには欠かせない重要なお仕事です。
また、デバッガの能力を高め、連携するための各種製品開発も重要です。exeGCC という GCC を組み込み向けにカスタマイズしたものや、Eclipse のデバッガ用プラグインなどを開発している人たちもいます。
こうして見ると非常に幅広い業務内容ですが、KMC は 10 数人という少人数で対応しています。コンパイラ、デバッガ、ターゲット(実機) など多様な技術を、大企業のような分業制では無く、一つのオフィスの中で全て掌握し、頻繁なコミュニケーションを取っていることにより、仕事や発想の幅が広がると思います。そしてこれこそが、KMC の良さであり、強さの源なのではないかと個人的には思っています。
私自身は、デバッガとつながる CPU シミュレータという、少し他の人たちとは毛色が異なる研究開発を今のところメインでやっているのですが、少し長くなりましたので、またの機会に話そうかなと思います。続きを読む
2009年07月03日
gccのtipsを紹介します。主にgcc3.x からgcc4.x で変わっているところです。
#include <stdio.h>
int main()
{
printf("Hello, world!\n");
}
このプログラムはgcc3では普通にprintfを呼び出すコードを生成しますが、gcc4ではどうなるでしょうか。ARM版のexeGCC4でちょっと試してみます。
2009年07月03日
1969 年に Bell Lab の Kenneth L. Thompson と Dennis M. Ritchie がプロトタイプを作成した時から数えて、今年は UNIX 40 周年の節目だそうです。UNIX の 1/4 世紀という本がありますが、あと10 年したら UNIX の半世紀ですね。
ちょっと昔の話をしたいと思います。35 年近く前の C の話です。（もちろん私は 20 代なので、まだ生まれてません。）1975 年、UNIX v6 がリリースされました (後の BSD UNIX につながる版です)。この版は pre K&R C という、現代の C (C99) から見ると非常に素朴な C で実装されています。
Dennis M. Ritchie, "C Reference Manual" (1975)
http://www.cs.bell-labs.com/who/dmr/cman.pdf
今日あたりまえのように使われている、void/unsigned/const/enum/union/volatile … ここらへんのキーワードが軒並み存在しません。（代わりに entry という謎のキーワードがあったりします。）
なんと、型のキャストという概念も存在しません。こんなんでまともなプログラムかけるのかな ? と思うかもしれませんが、Lions' Commentary on UNIX を読んでいると、いろいろと面白い技巧が垣間見れます。
参考サイト : 2238クラブ
キャストも unsigned も存在しないので、符号付き整数を unsigned で扱いたい場合は、ポインタ変数に代入してから計算していたようです。ポインタは unsigned ですから、アセンブラ的な感覚からすれば、unsigned というキーワードは無くても困りませんね :-)
rdwri.c
特定のメモリアドレスが定数として define されている場合、どのようにして参照すれば良いのでしょうか ? 今日の C ならば、*(int *)SW のように、ポインタへの型キャストを使えば良いわけですが、キャストは存在しません。
param.h を見てみますと。
いかがでしょうか ? 面倒で実用性が低い言語だと思われた方もいるかもしれませんし、パズル的で面白いと思われた方もいるかもしれません。
私には、pre K&R は、ある種のミニマリズム的美しさと実用性が奇跡のバランスで釣り合っている言語のように思えます。単に学術的な意味でのスマートな言語は他にもたくさんありますが、なんせ UNIX v6 を書いた言語なわけですから、やはり説得力が違います。
ちょっと昔の話をしたいと思います。35 年近く前の C の話です。（もちろん私は 20 代なので、まだ生まれてません。）1975 年、UNIX v6 がリリースされました (後の BSD UNIX につながる版です)。この版は pre K&R C という、現代の C (C99) から見ると非常に素朴な C で実装されています。
Dennis M. Ritchie, "C Reference Manual" (1975)
http://www.cs.bell-labs.com/who/dmr/cman.pdf
今日あたりまえのように使われている、void/unsigned/const/enum/union/volatile … ここらへんのキーワードが軒並み存在しません。（代わりに entry という謎のキーワードがあったりします。）
なんと、型のキャストという概念も存在しません。こんなんでまともなプログラムかけるのかな ? と思うかもしれませんが、Lions' Commentary on UNIX を読んでいると、いろいろと面白い技巧が垣間見れます。
参考サイト : 2238クラブ
キャストも unsigned も存在しないので、符号付き整数を unsigned で扱いたい場合は、ポインタ変数に代入してから計算していたようです。ポインタは unsigned ですから、アセンブラ的な感覚からすれば、unsigned というキーワードは無くても困りませんね :-)
rdwri.c
6323: /* Return the logical maximum
6324: * of the 2 arguments.
6325: */
6326: max(a, b)
6327: char *a, *b;
6328: {
6329:
6330: if(a > b)
6331: return(a);
6332: return(b);
6333: }
volatile はまぁ、この時代の C は PDP-11 マクロアセンブラみたいなものなので、もともとほとんど最適化は行われていなかったので問題は無かったのではないでしょうか。手で register のようなキーワードを使い、最適化を指示していた時代です。ある意味、C の成熟を象徴するようなキーワードだと思います。特定のメモリアドレスが定数として define されている場合、どのようにして参照すれば良いのでしょうか ? 今日の C ならば、*(int *)SW のように、ポインタへの型キャストを使えば良いわけですが、キャストは存在しません。
param.h を見てみますと。
0166: #define SW 0177570
0167:
0168: /* --------------------------- */
0169:
0170: /* structure to access : */
0171:
0172:
0173: /* an integer */
0174:
0175: struct { int integ; };
この意味を理解するには、pre K&R C の struct 内部のメンバーの名前空間が単一であるという仕様を知っている必要があります。単に先頭アドレスからのオフセットと、メンバーの型だけが意味を持ちます。そして、明示的なキャスト構文はありませんが、アセンブラ的な意味での暗黙の型キャストが行われます。アロー演算子 -> の左側にあるスカラ値は、問答無用で構造体へのポインタ扱いされます。整数型も文字型も一切型チェックは行われません。というわけで、特定のメモリアドレスから、整数型として値を参照したい場合は、SW->integ のようにして参照できるわけです。いかがでしょうか ? 面倒で実用性が低い言語だと思われた方もいるかもしれませんし、パズル的で面白いと思われた方もいるかもしれません。
私には、pre K&R は、ある種のミニマリズム的美しさと実用性が奇跡のバランスで釣り合っている言語のように思えます。単に学術的な意味でのスマートな言語は他にもたくさんありますが、なんせ UNIX v6 を書いた言語なわけですから、やはり説得力が違います。
2009年07月02日
開発メンバーの新人、若槻です。
去年の 11 月から、京都マイクロコンピュータ株式会社という、デバッガを作っている会社で働いています。
デバッガというと地味な感じがするかもしれませんが、本来ソフトウェア開発には無くてはならないものです。ところが残念なことに、プログラミングの教科書などでは、デバッガは全く触れられないか、非常にあっさりとした扱いで終わることがほとんどだと思います。また、初心者のうちからデバッガに頼ることを覚えてしまうと、ちゃんと脳内でプログラムの動きを想像して机上デバッグする癖がつかないので邪道だ、というような主張をする人もたまに見かけます。
そういう私も、この会社に入るまでは、それほどデバッガの必要性を感じていませんでした。しかし、今ではデバッガ無しでプログラムを書くことは大変もどかしく、苦痛に感じます。例えばよくある状況として、変数の値がおかしくなっているようだが、この変数への変更はどこで行われているのか調べたい、という状況があると思います。これをデバッガ無しで調べようと思ったら、ソースコードを隅々まで見なければいけないのでかなり大変 (見逃す可能性も高い) ですが、デバッガがあればデータブレーク機能 (特定番地のメモリの読み書きが発生した瞬間に止まる) で一発です。
デバッガ無しでプログラムを書くということは、例えるならば、CT や MRI などの最新医療機器を使わずに診察を行うことと同じように思えます。もちろん基本技術をきちんと習得することは重要ですし、問診や想像力を駆使し、聴診器一つ (printf デバッグ) で病気を診断するベテラン医師の能力は素晴らしいものですが、やはり直接内部を見ることができる確実性には代えられません。
私が会社に入ってすぐに先輩たちに言われて、いまでも強く印象に残っているのですが「仮説は重要だが、仮説はあくまでも仮説であって、(特に組み込み業界では)実際に動いているものだけが真実。プログラム上のロジックがいくら正しくても、もしかしたらハードウェアにバグがあるかもしれない。」という教訓があります。いくら仮説の上に仮説を積み重ねていっても、いつまでたっても砂上の楼閣です。デバッグの際には、確実性をコツコツと積み上げていくことが何よりも重要です。これもまた最近辻先輩に言われたことですが「デバッグとは怪しいところを闇雲に探すことではなく、確実なところを探すことだ。」至言だと思います。
また、デバッガは、バグを発見するためだけではなく、ソースコードを理解する際にも非常に有益です。GCC や Linux のように、大量の ifdef でソースコードが切られている場合、そもそもどの行が実際に実行される有効行なのか ? ということすらわかり難く、下手をすると全く関係ないところを延々と見ていたということにもなりかねません。当然のことながらデバッガを使えば、実際に動いているところだけを直接見ることができます。
先輩方に比べて、まだまだ知識も経験も浅い若輩者ですが、私がこの会社に入って感じたことや得た経験を書いていくことにより、一人でも多くの人にデバッガ（開発）の魅力を伝えていくことができたら良いなと思います。
去年の 11 月から、京都マイクロコンピュータ株式会社という、デバッガを作っている会社で働いています。
デバッガというと地味な感じがするかもしれませんが、本来ソフトウェア開発には無くてはならないものです。ところが残念なことに、プログラミングの教科書などでは、デバッガは全く触れられないか、非常にあっさりとした扱いで終わることがほとんどだと思います。また、初心者のうちからデバッガに頼ることを覚えてしまうと、ちゃんと脳内でプログラムの動きを想像して机上デバッグする癖がつかないので邪道だ、というような主張をする人もたまに見かけます。
そういう私も、この会社に入るまでは、それほどデバッガの必要性を感じていませんでした。しかし、今ではデバッガ無しでプログラムを書くことは大変もどかしく、苦痛に感じます。例えばよくある状況として、変数の値がおかしくなっているようだが、この変数への変更はどこで行われているのか調べたい、という状況があると思います。これをデバッガ無しで調べようと思ったら、ソースコードを隅々まで見なければいけないのでかなり大変 (見逃す可能性も高い) ですが、デバッガがあればデータブレーク機能 (特定番地のメモリの読み書きが発生した瞬間に止まる) で一発です。
デバッガ無しでプログラムを書くということは、例えるならば、CT や MRI などの最新医療機器を使わずに診察を行うことと同じように思えます。もちろん基本技術をきちんと習得することは重要ですし、問診や想像力を駆使し、聴診器一つ (printf デバッグ) で病気を診断するベテラン医師の能力は素晴らしいものですが、やはり直接内部を見ることができる確実性には代えられません。
私が会社に入ってすぐに先輩たちに言われて、いまでも強く印象に残っているのですが「仮説は重要だが、仮説はあくまでも仮説であって、(特に組み込み業界では)実際に動いているものだけが真実。プログラム上のロジックがいくら正しくても、もしかしたらハードウェアにバグがあるかもしれない。」という教訓があります。いくら仮説の上に仮説を積み重ねていっても、いつまでたっても砂上の楼閣です。デバッグの際には、確実性をコツコツと積み上げていくことが何よりも重要です。これもまた最近辻先輩に言われたことですが「デバッグとは怪しいところを闇雲に探すことではなく、確実なところを探すことだ。」至言だと思います。
また、デバッガは、バグを発見するためだけではなく、ソースコードを理解する際にも非常に有益です。GCC や Linux のように、大量の ifdef でソースコードが切られている場合、そもそもどの行が実際に実行される有効行なのか ? ということすらわかり難く、下手をすると全く関係ないところを延々と見ていたということにもなりかねません。当然のことながらデバッガを使えば、実際に動いているところだけを直接見ることができます。
先輩方に比べて、まだまだ知識も経験も浅い若輩者ですが、私がこの会社に入って感じたことや得た経験を書いていくことにより、一人でも多くの人にデバッガ（開発）の魅力を伝えていくことができたら良いなと思います。
2009年07月01日
以前少しはまってしまったのですが、Linux kernel 2.6.29 は、gcc 4.1.[01] ではコンパイルできなくなったようです。
エラーメッセージを頼りに linux-2.6.29/include/compiler-gcc4.h を見てみると、なるほど。
どうやらミスコンパイルが起こるので、はじかれているようです。
この時に入ったようですね。
http://kerneltrap.org/mailarchive/git-commits-head/2009/1/2/4576264/thread
Linux Kernel 2.6.28 のリリースが 2008 年 12 月で、2.6.29 のリリースが 2009 年 3 月ですから、その間に入った変更のようです。
エラーメッセージを頼りに linux-2.6.29/include/compiler-gcc4.h を見てみると、なるほど。
/* GCC 4.1.[01] miscompiles __weak */
#if __GNUC_MINOR__ == 1 && __GNUC_PATCHLEVEL__ <= 1
# error Your version of gcc miscompiles the __weak directive
#endif
どうやらミスコンパイルが起こるので、はじかれているようです。
この時に入ったようですね。
http://kerneltrap.org/mailarchive/git-commits-head/2009/1/2/4576264/thread
Linux Kernel 2.6.28 のリリースが 2008 年 12 月で、2.6.29 のリリースが 2009 年 3 月ですから、その間に入った変更のようです。
2009年07月01日
blog.kmckk.comを訪問してくださった皆さま。
こんにちは、はじめまして。京都マイクロコンピュータの辻です。
この度、僕たち京都マイクロコンピュータ(KMC)でも、BLOGを利用してメッセージ発信をして行こう、という事になりました。
皆さま、今後ともよろしくお付き合いください。
このBLOGでは、製品に関する技術・サポート情報なども取り扱いますが、直接に製品とは関係のない色々な事を取り上げていくつもりです。
このBLOGですが、訪問して頂いた皆さまと共に成長していきたいと思っておりますので、コメントなどもよろしくお願いいたします。
2009年7月1日
京都マイクロコンピュータ株式会社
スタッフ一同
こんにちは、はじめまして。京都マイクロコンピュータの辻です。
この度、僕たち京都マイクロコンピュータ(KMC)でも、BLOGを利用してメッセージ発信をして行こう、という事になりました。
皆さま、今後ともよろしくお付き合いください。
このBLOGでは、製品に関する技術・サポート情報なども取り扱いますが、直接に製品とは関係のない色々な事を取り上げていくつもりです。
このBLOGですが、訪問して頂いた皆さまと共に成長していきたいと思っておりますので、コメントなどもよろしくお願いいたします。
2009年7月1日
京都マイクロコンピュータ株式会社
スタッフ一同
