2009年07月

2009年07月31日

KMC のデバッガを一番使っているのは、実は KMC の開発スタッフなのかもしれません。
開発スタッフのディスプレイを覗き込むと、常に PARTNER が起動しています。PARTNER でデバッグし、PARTNER からエディタを起動してソースコードを修正し、PARTNER から make を打ち、ロードし、実行する。もはや完全に PARTNER が OS (shell) のような感じになっています。

KMC には、製品は社内で使い込んで十分に揉んでから出荷するという文化があります。マイクロソフトは、このことを 「ドッグフードを食べる」と表現しているようです。

参考 :「マイクロソフトが社員に勧める“ドッグフード”栄養学」
http://japan.cnet.com/interview/story/0,2000055954,20060067,00.htm
(私は Joel Spolsky の本でこの言い回しを知りました。)

自分たちで日常的に使うことにより、使いにくいところや不具合を改善していくことこそが、良い製品を作るためには必要不可欠なプロセスだと思います。そもそも、社内の人が難しすぎて使えなかったり、不具合が多くて使ってくれないような製品が売れるわけがありません(笑)まずは社内の人に使っていただけるところまで持っていくのが、製品開発の第一の壁です。

最近 koba さんが、exeGCC のテストプロセスの一部に、私の開発している CPU シミュレータを利用してくださっています。膨大な数の GCC のテストスイートを常に通してくださることにより、シミュレータに対する自信が深まりますし、koba さんも実機に JTAG をつなぐ手間なく、多くの CPU でテストを行うことができるという Win-Win の関係が築けています。大変うれしいことです。

2009年07月30日

私がよく使うgccの -save-temps というオプションを紹介します。

続きを読む

2009年07月29日

PARTNER(ARM) のマニュアルを編集していた際、mmu コマンドに /T というオプションを見つけました。マニュアルの説明を読んでもよくわからなかったので先輩に聞いてみたところ、これは TCM (Tightly Coupled Memories) という、ARM コアの内部に存在する超高速メモリ (SRAM) を操作するためのオプションなのだそうです。

TCM は、要するに、ユーザが読み書きできるキャッシュメモリのようなものなのだそうです。容量は小さい (10 数 KB ほど) のですが、DRAM の初期化が済んでない状況でも使えるので、開発の初期段階でちょっとデバッガや簡単なプログラムを動かしてみたい時などに重宝するそうです。また、OS などのシステムソフトウェアの高速化の際にも有用です。(こちらの方が一般的な用途。)

TCM は全ての ARM コアに存在するわけではなく、オプション的に実装されるものなのだそうです。あまりアプリケーションプログラマは恩恵を受けられない機能ですし、SRAM は回路が大きくて実装コストが高いため、実装されないケースも多そうです。特殊な用途の TCM よりも、同じ SRAM を実装するならば、より大きなキャッシュを実装してくれた方がうれしい技術者が多いと思います。

しかし、CPU が速くなれば、相対的にメモリアクセスがボトルネックになりますから、シリコンが余ってきた状況ではおいしい場面も出てくるかもしれません。組み込みの世界では、必ずしも絶対性能は重要ではなく、過去のソフトウェア資産やコストパフォーマンスが重要視されます。ARM 9 ファミリーなどの少し古い v5 アーキテクチャもまだまだ現役です。プロセッサの加工技術が向上すれば、同じアーキテクチャを実装したとしても、シリコンの面積が小さくて済むので、どんどんシリコンが余ります。そのため回路の 1 チップ化 (SoC) を進めたり、コアの数を増やしたりしているようなのですが、TCM のような SRAM もどんどん大きくなっていくのかもしれません。

また、iPhone や Android などが普及し、LLVM などの動的最適化技術 (JIT をより一般的にしたような技術)が進歩すれば、プログラマが意識しなくても、勝手に TCM を使って高速化してくれたりとかいう未来が来るかもしれません。

2009年07月28日

定義宣言と参照宣言の話に関連して、実際にこのコードをコンパイルして、変数がどう割り当てられるかをみてみましょう。

v.c

int x;  /* (1) */
int y = 0; /* (2) */
int z = 1; /* (3) */
extern int x; /* (4) */

このファイルをコンパイルしてアセンブラ出力の結果を見てみましょう。

gcc -S v.c
続きを読む

2009年07月27日

C の規格に関するちょっとした話です。

今まで、extern が付いていない最上位宣言での変数宣言(グローバル変数)は、全て定義宣言になるのだと思っていたのですが、厳密には異なるそうです。
int x;         /* (1) */
int y = 0; /* (2) */
extern int x; /* (3) */

(1) と (2) は、単に初期値が与えられているかいないかだけの違いで、どちらも定義に見えます。

ところが、厳密には (2) だけが定義宣言で、(1) は仮定義という扱いになるのだそうです。続きを読む

2009年07月24日

このごろは組み込みソフトウェア開発でも C++ が使われるようになってきました。C から C++ に移行する際、おそらく誰もが一度は引っかかるのではないかという C++ の挙動について書きます。続きを読む

2009年07月23日

CNET Japan : Linuxの脆弱性を突くゼロデイエクスプロイトが公開に

Linux Kernel の脆弱性により、見慣れない GCC のコンパイルオプションが話題になっています。恥かしながら、私は今回の一件で始めて知りました。GCC の online manual を見る限り、少なくとも GCC 3.0.4 からは存在するオプションのようです。

GCC Manual 3.10 Options That Control Optimization -fdelete-null-pointer-checks

マニュアルの説明を読むと、既に一回ポインタを間接参照した後の NULL チェックは無意味だから削除するという、何の問題も無い最適化に見えます。

GCC 4.4.1 までは -O2,-O3,-Os で有効になっていたようですが、最新のマニュアルでは(一部のターゲットを除き)全ての最適化レベル(-O0 含む)で有効になると書いてあります。

このリンク元のブログ記事のコード
struct sock *sk = tun->sk;  // initialize sk with tun->sk

if (!tun)
return POLLERR; // if tun is NULL return error
を一見した時、何が問題なのかよくわからなかった (NULL チェックがあろうがなかろうが、NULL ポインタを参照した瞬間に SEGV が発生して kernel panic になるはず、と思った) のですが、kosaki さんの記事を読んで納得。

革命の日々 : 「Linux カーネルの zero-day exploit コード、リリースされる」への余談

Linux Kernel では、ユーザプロセスが 0 番地に mmap を実行することが可能なので、

(1) 0 番地を間接参照しても SEGV が発生しないようにできる。
(2) NULL チェックが GCC の最適化によって削除されてしまっている。
(3) Kernel が 0 番地にアクセスしてしまう。(任意のコードを実行させることができる。)

というメカニズムのようです。なるほど。

私は、これは GCC の問題というよりは、ポインタを NULL チェック無しでいきなり参照している Linux Kernel のコードの問題だと思います。しかし、Kernel などのセキュリティが重要なソフトウェアをビルドする際には、fno-delete-null-pointer-checks を付けておいた方が良さそうです。

# あるいは、NULL チェックが行われていないポインタ参照全てにデフォルトのチェックコードを挿入するようなオプションがあれば良いのかもしれません。

2009年07月22日

ベテラン技術者の S 先輩からコラムを 1 本いただきました。ありがとうございます。




ユーザインターフェースは、人それぞれの好みや世の中の流行などがあって万人受けする設計はとても難しい。色、一つをとっても、KMCのPARTNERでは、Windows Ver3.1の時代に設計されたので、当時Windows Ver 3.1の制約で中間色がほとんど使えなかったため、青色,黄色,黒色などはっきりした色をベースとしました。

現時点では、勿論PARTNERでも中間色設定ができるのですが、新たにその色のデフォルト変更しようとすると、社内でもユーザに確認しても賛成意見(最近のソフトにあわせるべき)と反対意見(PARTNERらしい色使いを残すべき)が拮抗して判断に迷うことも多くあります。

また、好みによってメニューを変えられる機能を付けても、多くのユーザは、標準設定で使うことが多そうです。

そこで、長い間デバッガの開発にたずさわってきた経験とそのデバッガを使ってきた経験からいえることは、デバッグ作業の特性上同じことの繰り返しが非常に多い事です。実は、CUI(コマンド入力)とコマンドヒストリ機能を使うのが早くて便利なのです。
  • デバッグのファイルロード
  • ブレークポイントの設定
  • 変数参照
  • ファイル参照
など、これらの同じ操作の繰り返しは、あまりGUIに向きません。GUIでは、メニューを選択してダイアログボックスが表示され、その項目に従って、データを設定すれば、視覚的でかつ初心者でも分かり易いのは勿論、他のソフトウェアを使った経験もそのまま有効です。

しかし、何度もマウス操作とクリックおよびキー入力、また、表示の変化がディスプレイ上のいろんな場所に変わっていく(メニュー、ダイアログ、タグなど)ので認識に時間がかかります。

一方、CUI(コマンド入力)では、コマンドを覚えないと使えないし、パラメータの意味もマニュアルを見ないと分からない、キーのストローク回数も多いといった問題があって、最近のデバッガではCUIのない(コマンド入力のできない)もしくは使わないデバッガがほとんどです。

KMCのPARTNERでは、GUIの便利な点とCUIの便利な点を組み合わせて利用できる方法は無いものか?と思案した結果。安直ではありますが、GUIでの動作(ロードやブレーク設定など)をCUIのヒストリとして登録する方法をとっています。

これで、最初のロードは、GUIを使ってマウスでファイル指定してロードし、その後のロードは、'L',SHIFT+↑,Enter の3つのキー操作でリロードできるようになりました。社内の開発スタッフは、みんなこの方法をうまく使っています。

このように、GUIだけにたよらず、CUIを組み合わせて使ってみることも良いのではないでしょうか?




参考リンク : PARTNER のデバッグ風景を Flash で見ることができます。

「GUI と CUI の連携」
http://www.kmckk.co.jp/jet/gui_cui.html
「シンボルラインでのシンボル名拡張機能」
http://www.kmckk.co.jp/jet/symbol.html
「関数バックトレースと関数ローカル変数ウィンドウの連動」
http://www.kmckk.co.jp/jet/debugger.html
「モジュールウィンドウからの関数の選択」
http://www.kmckk.co.jp/jet/module.html

2009年07月21日

こんにちは、若槻です。今回は決意表明もかねて、健康に関する話を書きたいと思います。(公式ブログに書いてしまえば、イヤでも生活改善をやらざるを得ないでしょう… 苦笑。)続きを読む

2009年07月17日

前回のprintfの話で以下のコメントをいただきました。

> 以下が気になりました。
> -libcに改行なしのputsが無い
> -gccが二つ以上のprintfやputs、putcharの合成をしない
> 何か理由があるのかな

直接この疑問に答えられているわけではありませんが、ちょっとだけ調べてみたのでここに記しておきます。

続きを読む

2009年07月16日

日本Androidの会の7月のイベントで、日立製作所の川崎さんからAndroidをSHに移植した話がありました。

SuperH アーキテクチャ向けAndroidの開発
続きを読む

2009年07月15日

KMC は、基本的にはソフトウェアに重点を置く会社です。開発スタッフの多くはソフトウェア技術者です。

しかし、JTAG-ICE デバッガの最下層では、非常にハードウェアに近い技術が必要です。ここら辺は、徐々に若手への技術移転を進めている(進めないといけない)ところなのですが、現在はほぼ CTO と、数人の先輩に強く頼っています。

PARTNER-Jet デバッガが、高速性と高機能を両立できているのは、KMC がソフトウェアとハードウェアの役割分担が上手くできているという点が大きいと思います。ハードの人たちが、非常に高度な JTAG プログラミング技術や、FPGA などのハード的な高速化技術を駆使して、最も負荷がかかる JTAG 通信部分をチューニングしてくれているおかげで、ソフトウェア技術者はあまりパフォーマンスチューニングを意識する必要が無く (もちろん PARTNER-Jet の最大のウリは速度なので、常に速度には神経を使っています)、機能の実装に集中することができるという体制になっているからです。

また、PARTNER デバッガソフトウェアは、25 年以上にも渡りブートストラップ的な開発(デバッガを開発するためには、デバッガが必要という、不思議な循環)を続けてきた結果、非常に独特な内部構造になっています。詳細はもちろん企業秘密なのですが、ちょっと一朝一夕には真似できない、優れた設計になっていると思います。

この独特の設計は、完全に PARTNER (x86 版。今のところは製品としては販売されていない、社内用ツールです) に依存した、PARTNER ありきのものなので、通常のデバッガしか無い状況では、ちょっと実装やデバッグは不可能なのではないかと思います。そしてこの構造こそが、PARTNER のデバッガソフトウェア部分の開発効率が非常に良い(一度理解してしまえば、非常にコードが書きやすい。慣れるまでは大変ですが…)ことの本質となっているのではないかと思います。

2009年07月14日

Ubuntuのmingw32のsnprintfのバグを見つけて修正しました。

どうやら既知の問題だったようですが、もしかしたら役に立つかもしれないのでここにメモを残します。

mingw32とwineについて

Ubuntuのmingw32パッケージはWindows用のクロスコンパイルツールです。このコンパイラを使うとUbuntu上でWindowsアプリをビルドすることができます。

WineはWindowsアプリを動かすための互換レイヤです。全てのWindowsアプリを動かすことができるわけではありませんが、クロスコンパイルしたものをちょっと確認するには重宝します。

続きを読む

2009年07月13日

このたび社内のプロジェクト管理システムを Trac から Redmine に更新しました。実作業を行った北川先輩から、その時の作業メモをブログのネタとしていただきました。ありがとうございます。

北川さんが作業を行った際、ネット上にまとまった情報が無くて非常に苦労したそうです。この情報が誰かのお役に立てれば幸いです。続きを読む

2009年07月10日

巷ではプログラマ 35 歳定年説なるものがまことしやかに囁かれているそうです。

私は KMC 以外の会社を知らないのでなんとも言えないのですが、これはどうやら新しいことが覚えられなくなってくるなどの能力的な限界というよりは、単に技術者のキャリアパスが十分に整備されていないため、ある程度以上の年齢で正当な待遇を得るためには、向き不向き関係なく、技術者から管理者に否応なしにシフトせざるをえないという現状に対する嘆きのようです。

一方 KMC 社内を見渡してみると、なんと 35 歳以下の技術者がほとんどいません(笑)社長と CTO が、ともに 50 間近にして現役の技術者です。というよりもむしろ、社内で最も多く、かつ重要なコードを書いているのがこのお二方だと思います。

この間、社内のソースコード管理システムが変わり、社長困ってるんじゃないのかなとひそかに心配していたのですが、全くの杞憂でした。「git 便利やわ〜、ちょっとまだ不安定で master に入れるのが怖い状態の時、ローカルに branch 切って置いておけるもんな」と、普通に使いこなしていました。

組み込み業界はただでさえ年齢層が高めと言われますし、25 年以上の歴史を持つ老舗デバッガベンダーというと、なんとなく保守的なイメージを持たれている方もいるかもしれません。もちろん、これまで積み重ねてきた信頼と実績を守るために、重要な製品コア部分そのものの変更には慎重ですが、それ以外の技術、例えば最近は redmine という Ruby on Rails で組まれたバグトラッキングシステムが運用されていたりと、活発に新しい技術に取り組んでいく風土が社内にあります。

そもそもこのブログ自体が、わりと組み込み業界では珍しい試みなのではないかと思います。非常に狭い業界ですから、社外秘や NDA は当然としても、それ以外にもうっかり書いてしまうとまずいことがたくさんあったりするようです。このブログを始める際、正直不安もありましたが、社長が「失敗を必要以上に恐れていたら、新しいことはできへん」というスタイルなので、だいぶ救われています。

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

QRコード
QRコード