KMC 京都マイクロコンピュータ株式会社

NHK の連続テレビ小説「ゲゲゲの女房」、面白いですね。出勤前によく見てます。

原案の「ゲゲゲの女房」（布枝夫人著）と、書店で隣に並んでいた「ゲゲゲの人生 わが道を行く」、「敗走記」、白い旗（水木しげる著）などを休日に読み、パプアニューギニアについての記述に、とても懐かしい気持ちになりました。

続きを読む

KMC は、おそらく日本の企業では珍しいのではないかと思うのですが、社員一人一人が自分の一年間の自己評価と、それをベースにした希望年収金額をレポートにまとめて提出し、最終的には評価者との面接(交渉)により給与が決まるという制度を取っています。

評価は、経営サイドの最高責任者(つまり社長)と、技術サイドの最高責任者(CTO)のお二人が行います。人を評価するということは非常に大変なことで、普段はバリバリの技術者である社長たちは、慣れない仕事にかなり消耗していた感じでした。

それでもこのような制度を取っているのは、「誠実でありたい」「（与えられた仕事をこなすだけの）"サラリーマン"になるな」という、常日頃から社長が主張されている信念の表れ（の一つ）なのだろうと思います。

続きを読む

辻さんは Linux がバージョン 0.9 の頃から kernel を見てきたそうなのですが、当時は Yggdrasil Linux というディストリビューションを使っていたという話をこの間聞きました。92-3 年あたりとのことです。

続きを読む

2 ちゃんねる発祥の Mona OS の開発者 higepon さんが、Mona OS のデバッグ環境を整えようと努力されているようです。

Mona OS は QEMU 上で開発されていて、QEMU は gdbstub.c というプログラムで GDB と接続し、ICE のように使うことができます。

ひげぽん OSとか作っちゃうかMona- 2009/12/08 GDB スタブを書いてみよう その1
GDB スタブを書いてみよう その2

目的

達成したいのは Mona 中のユーザープロセスのデバッグ。ユーザープロセスが出来れば Kernel は簡単だと思う。
特にユーザープロセスが死んだときにソースコード上のどこで死んだかが GDB 一発で分かるようにしたい。

弊社の JTAG デバッガ PARTNER-Jet は、まさしくこのような機能を備えていて、弊社ではそれを「OS 対応」と呼んでいます。Linux、Win CE、(T-Kernel などの各種) RTOS、などに対応しており、オプションとして購入可能です。

続きを読む

おとといの月例会議中に、社長から突然社長賞（表彰 + 特別ボーナス）という制度の設立が発表され、誰もが納得する 3 人の先輩が第 1 回目を受賞されました。おめでとうございます。

弊社のように、全体で 10 数人という規模の会社では、案件の種類によっては、特定の人に大きな負担がかかってしまうことが避けられない側面があります。

だからこそ全員で助け合い、負荷を分散する必要があるのですが、やはり技術に重点をおく会社の性質上、特定の人以外には手が出せない（アウトソースもなかなか難しい）領域というものが存在し、その工数が多い時期というものが存在してしまうのが現実です。

小さな組織は、柔軟で効率的な運営ができる反面、なあなあになりがちで、ともすれば特定の人への仕事の偏りが常習化してしまうという弊害もあると思います。定期的に組織編成を見直し、正当に働きを評価をする機会として、このような会議中の表彰制度というのは有効なのではないかと思いました。

# そのほかにも、ちゃんと会社から評価されているということを、ご家族の方々にも知らせて、ご理解をいただくことを期待する、というような心理面でのケアという側面もあると思います。

もちろん、お金さえ出せば万事解決、などとは誰も思っていません。
ちゃんと若手を育成し、複数人でのバックアップ体制を作っていくという組織改善の努力が重要ですし、これはみんなで考えていかなければいけない問題です。しかし、そのような本質的な解決にはやはり時間がかかります。社長は常にここらへんを気にかけ、どうしたものかと苦悩されているようで、社長賞などの各種表彰制度の整備も、様々な対策のうちの一つなのでしょう。

続きを読む

最近 twitter 関連の本が何冊も出版され、徐々にメジャー (?) になりつつあるように感じます。

amazon.co.jp - 和書 検索 > "twitter"

詳細は割愛しますが、twitter というのはマイクロブログサービスです。

ブログは誰でも見ることができる開かれたメディアで、情報の鮮度やまとまり具合がほどよく、コメントやトラックバックなどのしくみも充実しています。
しかしその反面、少し固いメディアでもあるので、記事をまとめるというのは、それなりに手間がかかります。
チャットや IRC は手軽に思ったことを書き込めますが、身内だけで話題が閉じてしまいがちで、情報が表に出てきません。
twitter は、その両者の間のニッチを上手く埋めるサービスだと思います。

twitter には、ハッシュタグというサービスがあります。これにより、自分が follwo している人々だけではなく、twitter 全体から共通の話題に関するポストだけを読むことができます。

この間の ET 2009 の時には、#et2009 というタグが作られ、これがけっこう便利だと個人的に感じました。今年は、どこで何を展示していて、何が面白いのか、などの情報を横断的に見ることができました。

#et2009
(現在、一時的に過去のつぶやきが見えなくなってるようで、何も表示されていませんが…)

また、さまざまな外部サービスを利用するのも便利です。例えば以下のサービスを利用すると、特定のタグを使用した人のリストを見ることができるようです。

ハッシュタグクラウド #et2009

一時的なタグの他にも、例えば #embedded_jp などの永続的なタグもあり、共通の話題を持つ人々 (twitter では、クラスタと呼ばれます。) を素早く見つけ、話題をフォローすることができて楽しいと思います。これから twitter を始めてみようという方は、まずはここらへんから攻めてみると良いかと思います。

#embedded_jp

参考: twitterでの組み込み系話題のハッシュタグ #embedded_jp ができました

ウェブ系やオープンソース系に比べると、組み込み系は (ハードウェアに近い世界では、必然的に NDA が多くなるという仕事の性質もあるのですが) なかなか情報が表に出てこなくて、技術者同士の接点も少ない印象があります。そのため、知名度も低く、なかなか新しい人が入ってこないため、業界全体の高齢化が進んでいるという現状があるのではないかと思います。(弊社もかなり平均年齢は高めだと思います。私はそろそろ 20 代も後半なので、世間的にはけして若い方ではないと思いますが、弊社では最年少です。1 つ上の佐藤さんの次は、もういきなり 10 歳以上年齢層が上がります。)

このブログも、そのような現状を変えたいという思いから続けているわけなので、この twitter のような情報共有の流れは好ましいと思い、紹介させていただきました。

健康診断の時、尿酸値が非常に高いという指摘をされたという話を以前書きました。
こちらは、当然現在も治療を継続中です。ザイロリックという尿酸の生成を抑制する薬を毎日 1 錠、そして毎日 1 時間程度の運動(ウォーキングやランニング) を続けています。人間ドックの時は 9.6 あった尿酸値も、今では 7.2 にまで下がりました。

(それでもまだ危険水域ですが。ちなみにこの検査結果は 2 ヶ月前のものなので、今ではもっと下がってるかもしれません。薬を一回に 3 ヶ月分もらえるので、病院に行くのは 3 ヶ月に一度なもので。)

実はそのとき、視神経乳頭陥凹という耳慣れない指摘もされていたのです。これは、緑内障の典型的な症状なのだそうです。
(まだ 20 代なのに、若い人には珍しい病気を二つも…)

続きを読む

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

続きを読む

いつもいつもマイナーなネタですいません。

プログラミング言語 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 の歴史は、こういうのがけっこう多いです。

山本先輩からコラムを1本いただきました。ありがとうございます。

---

元々、ミステリーが好きでよく本を読んでいたのですが、最近本の読み方が大きく変化しました。
実際には、物理的な本は読まずに、T-01A(ドコモのWindowsモバイル携帯)を使って読書しています。

続きを読む

また pre K&R C の話です。

pre K&R C の時代は、return 文が取る式を () で囲むことが文法上必須でした。その時代の習慣を引きずったためか、K&R (第1版) でも return 文の後の式を括弧で囲っていたようです。（私は第2版しか所有していないので確認できないのですが。）

そのため、今でも括弧を付ける人もいるようです。一方、括弧を付けると return を retuan のようにタイプミスした時に関数呼び出しとして解釈されてしまい、コンパイルエラーにならない（リンク時にはエラーになる）ために良くないと主張する人などもいるようです。いずれにせよここらへんの話は、IDE やエディタがキーワードをハイライトしてくれるようになった現在では、好みの問題の範囲と言えるでしょう。

http://www.math.utah.edu/computing/compilers/c/Ritchie-CReferenceManual.pdf

return ;
return ( expression );

しかし、そもそも私には、この () が pre K&R C で必須だった理由がわかりませんでした。最後に ; が必須なのですから、この括弧があることにより、特にパーシングに対して有利ということもありません。続きを読む

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 の関係が築けています。大変うれしいことです。

ベテラン技術者の 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

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

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

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

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

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

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