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 シミュレータという、少し他の人たちとは毛色が異なる研究開発を今のところメインでやっているのですが、少し長くなりましたので、またの機会に話そうかなと思います。続きを読む

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
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 でソースコードが切られている場合、そもそもどの行が実際に実行される有効行なのか ? ということすらわかり難く、下手をすると全く関係ないところを延々と見ていたということにもなりかねません。当然のことながらデバッガを使えば、実際に動いているところだけを直接見ることができます。

先輩方に比べて、まだまだ知識も経験も浅い若輩者ですが、私がこの会社に入って感じたことや得た経験を書いていくことにより、一人でも多くの人にデバッガ(開発)の魅力を伝えていくことができたら良いなと思います。

2009年07月01日

以前少しはまってしまったのですが、Linux kernel 2.6.29 は、gcc 4.1.[01] ではコンパイルできなくなったようです。

エラーメッセージを頼りに 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日
京都マイクロコンピュータ株式会社
スタッフ一同

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

QRコード
QRコード