なつたん

コンパイラの本充になったので、ようやくLRなパーサの勉強をする。ざっくり読んで、雰囲気は分かった。実際手を動かしてみると、予想以上の難易度で驚く。

ありがちな数式の定義（http://kaiunix.cs.shinshu-u.ac.jp/Lesson/ProgLangT/2008/SyntaxAndSemantics.htmlとか）を考えたとき、(1 + 2) * (3 + 4)　なら簡単にできるんだけど、1 + 1 + 1 + 1 + 1 になると、難しかったりする。1 + 1 + ・・・の段階では、どの＋も右側が確定しないから、何にもできない。一番最後の式の終わりで、初めてこれtermじゃんって事がわかって、右から順番に、俺もterm、実は俺もterm・・・という感じでパースが終わる。アルゴリズム分かったけど、どうプログラムに落とすのかが、想像もつかない。

もう一度本に戻ると、状態遷移の表を作るらしい。表を追って、ひとりでああなるほどと納得する。じゃあ、この表をどうやってつくるんだとう当たり前の疑問。ここで、yaccの出番か！

目標のはてぶ10個を突破したので、はてなの方でちょこちょこと書き始めようと思います。

ドラゴンブックも始めてしまったので、当面は週に一回の更新を目標にしています。

テーマはgomi_boxさんが作った物が、シンプルながらも力強さを感じる素晴らしいデザインなので、使わせていただくことにしました。

４年生の卒研発表を見学してきて感じたことが素晴らしすぎるのでリンクを張ってみる。

学生時代にこんな事を1秒たりとも考えたことはありませんでした。

The Practice of Programming から

・Chap 5 Debuggingから２つ
プログラミング言語について
Each language feature that prevents some problem has a cost of its own. If a higher-level language makes the simple bug disappear automatically, the price is that it makes it easier to create higher-level bugs. No language prevents you from making mistakes.

こちらは励ましのお言葉
Every bug you can find teach you how to prevent a similar bug from happening again or to recognize it if it does.

・Chap4 User interfaces から
エラーメッセージの出し方について
Don't say that a parameter is too large: report the valid range of values

The Practice of Programming いいよ。

年末年始にかけて、東大生がボードが壊れたとか大丈夫とか言っているが気になる。
普通に使っていればそう壊れるはずが無いのだが、ボードを扱うときの注意点を適当に書いてみる。

・電源間の抵抗値を測定しておく：基板に電源を入れる前に、各電源とGND間の抵抗値を記録しておく。新しい部品をつけたときや、はずしたときは、同じように抵抗値を測る。抵抗値が異常に小さいとき(数10Ω以下)なら、何か問題が起きているので電源を入れない。回路の接続間違いや、半田くずによるショートが考えられる。
動作中にICがさわれないくらいに熱くなった場合は、電源を切って抵抗値を測る。抵抗値が小さくなっていれば、半導体が壊れている。
・各ICの発熱量を知っておく：上手く動いているときに各ICの表面に軽く触れ、だいたいの温度の感覚をつかんでおく。後でこのICが熱いと思っても、正常な状態を知っておかないと判断できない。
・作業する前に電源を落とす：コネクタの抜き差しは基板の電源を落としてから。大元の電源まで落としておくと安心。
・コネクタの接続間違いを防ぐ：逆差し防止キーがついているコネクタを使う、違う用途に同じコネクタを使わない。
・電源の投入順序に気をつける：基板に遠い方から順番に電源を入れ、近い方から順番に落とす
・電源ケーブルの色は一般常識に従う：基本的に電圧が高いほど熱い色になる。5V、3.3V、GNDなら赤、黄、黒の順。
・シャーペン厳禁：シャーペンの芯は電気を通す
・五感を働かせる：基板に向かっているときは五感をフルに働かせ、変な音や臭いがしたときはすぐに電源を落とす。

人によっては基板にさわる前に自分自身をアースする人もいます。経験に依るところが多いですが、こことここがショートしたら基板即死だなという想像力をつけるのも大事。FPGAのコンフィグコネクタも、VCCとGNDが隣り合っていてここがショートしたら基板が死ぬ。こういう所で電圧を測る時は、この2ピンがショートしたら基板終わりだよという気持ちを忘れないこと。

プロの人が基板を壊さないのは、無意識に行っている細かいことの積み重ねだと思います。
他にもいっぱいありそうですね。

# 書いていたら、今までの基板を壊した記憶がよみがえって落ち込んできた。こういう事を怒鳴られながら覚えたんだよな～と思って、新人時代を思い出してもう一度落ち込む。

あけましておめでとうございます。
昨年の誤算は、年末の忙しさを予想できなかった事です。娘が一人と二人でこんなにも忙しさが違うとは。勉強もBlogもtwitterも全然できませんでしたよ。

遅くなったけど、2007年に読んだ本のベスト3の発表。

1.SICP
やっぱりこれが一番面白かったですね。
「計算機プログラムの構造と解釈(SICP)」を読み終えて by なつたん

2.C++ D&E
C++がなんでこんなに複雑怪奇になってしまったかが分かる本。読めば読むほどC++が好きになりますよ。
The Design and Evolution of C++

3.文学少女
ラノベ部門から一冊、文学少女が良かったです。
時間がある人は一冊目から是非。
“文学少女”と慟哭の巡礼者

2008年は、さくっと（長門の）mini pyを終わらせて、ハードよりの勉強を再開しようと思っています。

ときどきの雑記帖 i戦士篇へショートパス

パタヘネは旧版の日本語版でも十分おもしろいので、是非読んでみてください。

これからCPUを勉強しようという大学生向けなので図も多く分かりやすいです。パイプライン、キャッシュ、仮想記憶等のCPUの高速化の基礎の部分が勉強できます。あくまで基礎であって実際のCPUはもっと複雑な動きをしますが、それに入る前段階の勉強として有効です。実際のCPUとその周辺ハードの動きを説明しながら、パフォーマンスの計算方法を丁寧に説明してあります。キャッシュの所だけでも立ち読みしをお勧めします。

位置づけとしてはSICPに近いですよ。

プアーなハードで作る貧乏くさいアルゴリズムが好き

RS-232C 調歩同期のパリティ
初期値の設定と1bitの保持xorで作れる超簡単回路。この回路で、7bitだろうが、8bitだろうが、20bitだろうがどの長さにも対応できるのが凄すぎる。

CRCチェック
これもFF並べて特定のbitのxorを取るだけ。エラー検出率と使用リソースのパフォーマンスが高すぎる。これもパケット長に依存しない。

線形補完のアルゴリズム
y = 3/5 x のような直線を書くとき、順に3を足していって5を超えたところでyを1増やすと良い感じで直線が書ける。
足すのに使う変数をアキュムレータのaとして、5を超えるとオーバーフローして、超えた分だけの値を保持する。

x y a
0 0 0 aに3を足す
1 0 3 次にaに3を足すと6になってオーバーフローするので、yを1増やし、aは6-5で1になる。
2 1 1 aに3を足す
3 1 4 次にaに3を足すと7になってオーバーフローするので、yを1増やし、aは7-5で2になる
4 2 2 次にaに3を足すと5になってオーバーフローするので、yを1増やし、aは5-5で0になる
5 3 0 以下繰り返し
6 3 3
7 4 1
割り算しなくても、加算器＋レジスタで直線が引ける不思議。

TIFFフォーマット
FAXで使われるモノクロ、英文字を前提としたアルゴリズム。符号化/復号化にはラインメモリとラインプリンタだけでOK。一行前と同じラインなら数ビットで表現する優れもの。
エラーが発生しても改ページで立ち直れ！

イーサのCSMA/CD
とりあえず送信始めてみて駄目だったらお互いに適当に待ってもう一回送るだけ。この発想はなかなかできない。

ドルアーガのマップ生成
1バイトから、各フロアのマップ生成。1フロアが2画面なのはマッピー基板を使い回したから。

アルゴリズムじゃないけど、貧乏くさくて好きな物
ワイヤードORとか、モノクロのインペーダゲームにセロファンを張って色を付けるとか。

関係ないけど、調歩同期って死語じゃね？

若いころに云々から

書こう書こうと思っていたら、この写真のリア充っぷりを見て、一気に書く気が無くなって放置していた。

このまま10年前に戻れるなら、もう少しゲームの時間を減らして勉強に回したい。
10年前の自分へのアドバイス→ SICP読め、VHDLよりもVerilog、C++とPython今のうちに勉強しておけ
この日本語力もなんとかしたいな。とりあえずワインバーグの本買ってきた。
あとは、社会的常識っていうか、服装とか、身だしなみとか、そういうのも気にするようになれば良かった。

子供が生まれてから、みるみる時間を取られるようになってきた。昨日も夜中2時間くらい娘をあやし続けた。昼間は嫁が頑張るから、深夜だけでも頑張らないと。

大学に入学後に戻れるなら、おそらく同じ会社入って、同じ人と結婚して、同じように転職して、同じように娘に来て欲しいと思っているので、今までの人生は満足度高め。人生やり直して、娘に会えなくなるのは辛い。
大学が選べるなら、東大にいって凄い人たちと勉強するか、京大行ってKMC入りたいな。

2007年はビジネスマナーが駄目だったので、2008年は日本語とマナー向上を目指す。
今年の成長：掃除は人のためにする！

ちょっとひらさんっぽい話。

そんなこんなで私物を整理していたら、昔の勉強ノートがでてきたわけです。中を見てみるとなつかしい事が書いてあってうれしい。Blogも良いけど紙のノートにまとめるのも思い出がよみがえってきて良い。新人～2年目くらいに書いたんだろうけど、ハードのことを必死で勉強しているのが分かる。トラ技を3年くらい続けて読んでいたり、情報処理検定の勉強と絡めていたりしている。デバッグルームで、RS-232Cのピン配置とかアスキーコードを知りたいとき、このノートにお世話になった。今じゃGoogleだけどね。

そんななか、ノートが昔勉強したMINIXの所に来て驚く。ノートにソースコード貼り付けて、それにコメント入れて勉強している！そうだ、昔はノートに切り貼りしながら勉強するスタイルだった。これは勉強に時間がかかるはずだ。必死でMINIXを勉強した事実は覚えているんだが、いまいち自分の血肉になっていない気がする。MINIXのシステムコールの一覧やら、inodeのフォーマットなんてまとめてもしょうがないだろと今の自分なら思うけど、当時はこれが大事だと思っていたんだよな。

MINIXの後は、仕事で使ったμITRONのマニュアルから丁寧にシステムコールが順にまとめられている。マニュアルそのまま持ち運んだ方が絶対によいと思うんだが、まとめたかったんだろうな。続いてコードコンプリートとパタヘネか。パタヘネは図を書いた方が良いよ。これだけは正解。状態遷移図とかノートに写してうんうん言っていた。

ふと思い立って、コンピュータアーキテクチャをパラパラと読んでみる。あれ、買ったときこんな難しい本絶対無理と思ったけど、意外に簡単じゃね？と思った。見ている視点が、パタヘネとは違うけど普通に面白いと思う。

ちょっと脱線。
コンピュータアーキテクチャ（日本語版）を流し読みした感想は、「良い本だけど、ちょっと内容が古いかな」って感じ。原書が書かれたのが1990年で、17年前なのにちょっと古いという表現が思いついたのは凄いと思う。勉強するならパタヘネの方がよいと思いますよ。コンピュータアーキテクチャは性能をどう評価するかを重点的に書いてあるのに対し、パタヘネは一つ一つの説明が丁寧でどう動くかを中心に書いてあります。コンピュータアーキテクチャの方が図や式がやや抽象的で、パタヘネは実際のハードウェア近くまで書いてある。正直、パタヘネじゃなくてコンピュータアーキテクチャ（ヘネパタ）の方を薦める人って、本当に読んだのかと問いつめたい。両方読めとかどんなけCPU設計するんだよって思う。コンピュータアーキテクチャ（ヘネパタ）は、SHマイコン萌えな人が読む本だよ。

整理を続けていると、こんどはコンパイラ構成法がでてきた。これも最初の方がさっぱり分からなかったけど、今読むとHOPと同じような事がかいてあって少しは分かる。

勉強の記録をつけるのは大事で、勉強し続けるとそれなりに成長はしているんだなと思った。