思考の整理学 (1)

電車通勤をやめてからすっかり本を読まなくなりました。
積まれていた本の中から１冊だけ鞄に入れてたんですが、今日は少しだけ読む機会があったので、読んだところを少しだけメモ（続き読むが先になるかもだし）。

という事で、表題の通り、外山滋比古さんの思考の整理学。
整理学とかいうタイトルだけど、特に考える事に関して体系化した書物というわけではないですね。「思考」に関する様々な角度からのエッセイを、どちらかと言えばごちゃっとまとめた感じ？

「グライダー」：グライダーと飛行機。詰め込み型教育の産物、自力で前へ進む事のできない人たちをグライダーに例えて批評。「自分で翔べない人間はコンピューターに仕事をうばわれる。」1986にまとめられた本にしては刺激的な台詞で締めくくられているけど、2010年になった今日、状況はどんなもんだろう？　就職難と人材不足の共存状態は、予言が的中した結果とも思えるけど、実際には大企業はまだまだグライダー人間に支配されている気はするなぁ。
続く「不幸な逆説」で述べられている、教える事を渋る事による飛行機人間の育成、という考え方は面白い。伝統芸能などで見られる教えない文化。師の業を盗もうと努力するところから学ぶ姿勢、意欲、独創性などが生まれるのではないか、という仮説。

「朝飯前」：まさに自分が修論の時期に実践していた事。一日のうち頭が働くのは起きた直後の数時間。ここまでは大学の仲間うちでも周知の事実だった。なので、一日を12時間ずつにわければ、頭が働く時間も二倍になるだろう、と。3時間寝て9時間作業〜みたいな生活だったと思う。普通に仕事して、論文も書いて、さらにバンド活動・・・となると、こうでもして時間を稼ぐほかなかった。凄い勢いで時間が過ぎていくようで、カレンダーは半分しか進まないという不思議な感覚で、実際に生産性もかなり上がった気がしました。
自分がやってた事と同じ事を筆者がしていると知って嬉しくなり、それがblogに書き留めようと思ったきっかけでもあるわけですが。さらに筆者は、朝飯を抜けば、さらにこの朝飯前の時間を長くとれる・・・と、なんだか子供じみた事まで（笑。偉い先生がこういう事を実践している、というのは生々しく、結局は努力なんだ、と思うと、なんだか救われた気持ちになります。努力でどうにでもなる世界、つまるところそれが究極の平等社会なんですけどね。民主党政権しかり、どうも日本は変な方向に向かいつつあります。

アマゾンでも誰かがレビューに書いてましたが、アイデアについてのエッセイでのべている事はジェームス W.ヤングの本に書かれている事と同じですね。学生の頃に読んで意識、実践してきたけど、アイデアが生まれるプロセスに関してこの本の解析はかなり正しい。色々な人が共感している事からも万人にとって真なんだと思う。うまくやれば凡人でも非凡のフリができる。。。はず。



＃そういえば、内閣府調査の一環で面接がありました。大学院教育はどうあるべきか、というテーマで議論したのですが、つまるところ調査の趣旨は「ゆとり教育は失策だった。その分、大学院教育でフォローして、なんとか社会で使える人間に仕上げる体制を作りたい。」という事だそうです。大学、大学院の進学率が伸びていますが、今まで12年で身になっていた事を16年、18年じっくりかけて教えているだけ。こういう状況にあって、自分の子供にどう学ぶ事を教えていくべきか、非常にむずかしい問題だと感じています。未だ脳の衰えを感じる事はありませんが、知識に関しては若ければ若いほど吸収が早く、使える技術になり易いのは事実でしょう。

ファミ・コンパーチブル（改）

あきばお〜で買い物ついでに。。。
600円弱とちょーお安かったのでw

背面についてる端子は写真の通り。
コンポジット端子なのでその辺のモニタに気楽にさせるわけですが、ちょっと配置が変（笑。付属のケーブルも赤／黄だったりして、なんじゃ？　って感じ。

答えから言うと、白と赤にはまったく同じ信号が配線されてます。日本ではステレオに繋ぐ時にもL（白）だけ繋げれば自動で左右に展開されるのが一般的ですが、大陸では違うのでしょうか。。。謎は深まります。

ちなみにACアダプタ端子が付いてますが、添付の紙っぺらによれば使用禁止。
・・・PSE通ってないから？　一応電池4本でも動くんですけど、電池は面倒です。
「まぁ、その辺のアダプタをさせば動くだろう・・・」
と甘い考えでその辺に転がってたアダプタをさしたら

ぷつんっ
「あっ」
・・・ぷ〜ん（異臭）・・・

やべー、やべー。
ってことでさっそく分解して調べてみたら極性が逆でした。

しかし、この電源作りが怖いです。。。
アナログ弱いんで理解が怪しいですが、トランジスタ（8550）１つで定電圧回路を作ってました。エミッタベース間に逆電圧をかけてツェナー効果で6Vを作っている模様。

ってなもんで、試しにセンターマイナスのアダプタを挿してみましたが、電圧が不安定なせいで画面がぶれまくり。

しかも、めちゃくちゃ熱くなるので要注意。。。

これじゃ使えないな、という事で例によってUSBから電源拾えるように（笑

写真の位置が空きスペース的にも固定するにもあつらえ向きでした。ここからUSB配給の電源を電池ケースの+/-に繋ぎ込めばOKです。

電圧が6Vから5Vになりますが、まぁ大丈夫でしょう。というか、むしろ5Vが本命な気はする。

で、多くの互換機と同じように拡張音源に対応してなかったので、ついでにその辺もプチ改造。カートリッジの45番ピンと46番ピンがショートしてるので、パターンカット。カートリッジから出力端子に繋がってるケーブルのA(udio)線をカットして、基板側を45番に、A(udio)線を46番に繋ぎ込めばOKなはず。

という事でためしにマダラを。

う〜ん・・・鳴るようにはなったけど、バランスがいまいちでした。FC音源側が極端に小さく鳴ります。

45番と46番の間にダイオードと抵抗挟むくらいで調整できないかな。。。
アナログ詳しい人いたら弟子入り希望（笑

という事で、ちょっと息抜きの寄り道でした。満足したのでこいつはステステ（ぇ

（注）この記事は無保証ですので、改造はAYORでお願いしますね。

浮気なぼくら

そのうちハードからOSに・・・とか言っておきながら、実は最近の休み時間活動はVNC@Haikuだったりしました（笑。

普段、設計用の端末ではUbuntuが動いてたりするんですが、そろそろ飽きてきた（かつ、ドライブの空きがなくなってきたw）かなぁ・・・と。

端末ならVNCが動けばたいていは事足りるので、ここは一つHaikuでも、と思ってBeOS用のVNCを動かしたんですが、なんでこんなに・・・ってくらいに糞重い！　なんでだろ・・・とか思ってVNCのプロトコルを調べてみたら、結構まとまった資料になって公開されている模様。それならば・・・という事で、プロトコルの調査がてらクライアントを作ってみました。

もともとVNCはアプリケーションレベルで色々組み込んでも遊べるかなぁ・・・って事で、興味は持ってたんですよ。例えばAVR上のMZ-80Kエミュレータの画面がVNC over UARTで飛んでくる、とかね（笑。

とりあえずハマったのはtwitterでも呟いてた認証の部分。標準のVNCAuthではDESを使って認証するんだけど、暗号化する時のパスフレーズ、なぜかバイト単位で上位下位を反転してやらないといけない。自分の書いたDESが間違ってるのかと思って、色々なライブラリと期待値比較しちゃったよ。。。

とまぁ、そんな感じでボチボチ動くようになったVNCクライアント。とりあえず家でも32bit rawという一番単純なプロトコルでOS Xの画面共有に接続してみたけど、LANで使ってる分には普通にサクサク動く感じ。なんで世の中のBeOS向けクライアントがこんなに重いのか・・・わけわからんちんですよ。

カーネル／VM探検隊

同じ会社にしばらくいると、少し外の空気を吸わないと・・・という気分になります。
Lionsもその一環なのですが、しばらく前にngcomで「最近は勉強会が流行っている」
という話を聞いたので、なにか面白そうなものがあれば参加したいな・・・と思い
目をつけていたのがカーネル／VM探検隊。ちょうど仕事にも余裕が出てきたところなので、
平日開催という敷居の高さを乗り越えて（午後からエスケープしたとも言う）参加して
きました。

まったく知った顔がいない、という状況は凄く久しぶりで、言葉通じるのにまるで
海外出張みたいにドキドキしてしまいました（笑。そうは言っても、実は大学の同期も
いたのですが、すいません人を覚えるのがトコトン苦手な私。。。うっすらと記憶に
あるものの、よく覚えていませんでした（汗。一応、だんだんと記憶は戻ってきて
最後にはなんとなく思い出してたんですよ。。。とフォローはしておきます（笑。

本業の面では畑違いなんですが、Plan 9とか、SheevaPlugとか、プライベートな嗜好では
思いっきりストライクゾーンで、人見知りとは別の意味でドキドキワクワクな時間でした。

LTのタイマー割り込みの話とか妙に盛り上がって（一部の？）参加者のハイレベルっぷりに
ときめいたりしてました。自分はv6のclock.c callouts近辺のコードしか頭になくて、
どこまで話についていけてたかわかりませんが。。。
先日の社内でのsignal話もそうなんですが、今まで身近にkernel hackerがいるって状況に
なかなか巡り会えなかったので、最近のこの体験はちょっとした感動です。

そのうちLTネタくらいは出したいなぁ。

P.S.
スライドがド派手な人が多くて驚いた。最近はこれが普通なのか。。。あと、OS Xを
使って長いくせに、画面の一部を拡大したり・・・って機能をまったく知らなかったorz

脈々と続くV6の血

仕事で、Linux kernel担当者のところへsignal周りの処理を質問にいった。
コードを見ながら色々と説明してもらった。

ところどころSMPを意識したコードが入ってはいるが、
基本的な処理の流れはV6のそれとまったく同じだという事に驚いた。

計算機に携わる以上、Lionsは一通り読んでおいて損はなかったな、と思った。

。
。
。

と言いつつ、ちょっと昼休みのコード読解は止まってまして、
しばらく思いつきで始めたこんなことをやってました。

CP/Mの次はMZ-80K、700、その次はApple II・・・と少しずつ
複雑なハードを再現したいなぁ・・・とか思ったりしてるのですが、
適度なところで飽きて、またOSに戻ってくると思います。

要素技術は身につけたので、AVR上でV6相当のOSを・・・とか
思ってたりするのですが、壊れたLANTANKを、とか玄柴さんを・・・とか
遊ぶネタは盛りだくさんです。LANTANKを会社に持ち込んで遊ぶのは
ちょっとアレかもしれませんねぇ。。。

Lions' Commentary (8) - lshift -

なんかまた色々と忙しくなってきちゃって進みが悪いんだけど、read / write 周りのsystem callが一通り追いかけられた感じなのでブログにエントリしてみようかと。

readi / writei は今までに読んだbio.c周りのバッファを使ってブロック単位に読み書きしてます。inodeから論理ブロック番号に変換して、最終的に物理ブロック番号を求める当たりもこの辺に。ファイルのオフセットからブロック番号とブロック内オフセット位置を求めるところでlshiftというアセンブラルーチンを呼んでまして、普通に書けば簡単な関数なんですが、アセンブラで良くわからん命令があって、ちょっと読解に苦戦しました。これは後述します。

ファイルの読み書きは基本512バイトのブロック単位で行うので、書き出しの際に1ブロック丸々上書きにならないような場合にはread modify writeの処理が入ります。また書き出し時には512バイト境界をまたぐごとに非同期書き込み要求を出し、境界に達しない半端な書き込みはバッファブロックにDIRTYと印を付けておき、バッファがLRU制御で追い出される際に遅延書き込みで吐き出されるようになってます。ブロック番号が直前に読み出したブロック番号+1になっていると、シーケンシャルプリフェッチが働くようになっており、古典的とは言えI/O処理の基礎は一通り完成している感じです。

プロセス管理やメモリ管理はLions'のみで一通り理解できてきた感じですが、I/O周りとなるとソース読解だけではなかなか理解が進みませんね。この辺はBach本の併読が遠回りなようで近道かも。

で、問題のlshift。例によってconf/m40.sです。

.global _lshift
_lshift:
    mov    2(sp),r1
    mov    (r1)+,r0
    mov    (r1),r1
    ashc   4(sp),r0
    mov    r1,r0
    rts    pc

「ashc」の使い方が良くわからなくて悩んだんですが、右オペランドがデスティネーションで、偶数レジスタを上位、奇数レジスタを下位としたペアレジスタに対して算術シフトを施す、という事ですね。この場合、r0が指定されているので、(r0 << 16) | r1 が操作対象というわけです。で、左オペランドがまた4(sp)なんて書かれているもんだから意味がわからなかったんですが、これがシフト量ですね。すっかりRISCが染み込んでしまっていたので、シフト演算の入力がオフセット付きレジスタ間接アドレッシングというのは、ちょっと斜め上をいく感じでした。結局、2(sp)が第一引数、4(sp)が第二引数なので、C言語で書けば

u16 lshift(u16 *vptr, s16 n)
{
    u32 v = (vptr[0] << 16) | vptr[1];
    if (n >= 0) v <<= n;
    else v >>= -n;
    return v & 0xffff;
}

これだけの処理。というか、やりたい事はu32値をブロックサイズ512で割りたいだけなんですが、なんとも面倒な話です。同様にdpcmpなんて関数もありまして、こいつも長々と書かれてますが32bitでcompareとるだけのアセンブラ関数でした。実際には減算結果を返し、結果は-512〜512に丸められます（という概要だけでも知ってればだいぶ読みやすいはず）。

PDP-11の命令フォーマットはオペランドに関しては基本的に6bitがアサインされており、3bitでレジスタ番号、残り3bitでアドレッシングモードが指定できるんですね。 CISCという意味では直行性があり洗練されてたのかもしれません。
＃レジスタ間接アドレッシングってPDP-1のINDビット以前は存在したんだろうか。。。ディレイスロットもそうだけど、プロセッサの歴史の中で誤った方向へ進んでしまった最初の一歩の１つのような気がする。

Lions' Commentary (7) - closeとunlink -

I/Oバッファから、i-node関連の処理、あるいはファイルデスクリプタの実体操作、ファイル処理などの関数に取りかかってきました。パイプ用の処理が分岐で書かれているのがちょっと気になります。キャラクタでバイスやブロックデバイスはそれぞれの特殊処理はドライバ側あるいはその上位層で処理しているのですが、パイプだけは各処理の中で直接分岐して書かれています。この頃アドホックにインプリされた物が後継版で整理されていくのでしょうか。。。名前付きパイプなんて出てくる頃には綺麗に書き直されている気がしますね。System IIIで実装済みなのは知ってるので、どんな実装か確認しようと思えばできるのですが、ちょっと後回しかな。しかし、正確に発明されたタイミングはどの時点だろう？

あと、UNIXでは伝統的な挙動、ファイルは消しても誰かがオープンしている間は実体が消えない、というやつ。自分は大学の先輩（mick'n）から教えてもらった気がする。これもcloseのsystem callを追いかけていると見つかります。fork時に実体の参照カウントはインクリメントされるので、close時に参照カウンタが1の時のみファイルデスクリプタの実体を閉じます。んで、この時にi-nodeのlink数を調べて0以下だったらtruncateしてi-nodeを解放する、つまり実体を削除する、という処理になっていました。

Lionsを読むと、このあたりの実装はテンポラリファイルの運用を簡便にするための物のようですね。プロセス生存中はpidがシステムでユニークである事をOSが保証しているので、そのpidを交えた名前はプロセス内で衝突しない限りはシステムでユニーク。で、プロセス内では生成直後にunlinkしちゃえば、他からは触れないし、上書きされる心配もない。で、使い終わったら明示的にcloseすれば削除されるし、segvで落ちちゃった場合なんかでもOSがプロセスの解放処理をする際に全ファイルをcloseしてくれるので自然に実体も削除されるという。simple is bestな実にUNIXらしい考え方です。