0x48C0 Terms and Tips for A-1 0x09
「今回もややこしい言葉いっぱいだね。デバッグだから、あんまり表に出てこない単語もあるよ」
「頑張って解説しますが、難しかったらぜひ教えてくださいっ」
『クラッシュ』（Ｃｒａｓｈ、異常終了）
「ＯＳがクラッシュするって、アプリが落ちるのとは違うんだよな？」
「違うぜ。アプリだけなら、そのプログラムの作業を止めれば済むことが多い。ＯＳまで止まると、机を管理してる先生ごと倒れるようなもんだな」
「ＯＳは、どのプログラムにどのメモリを使わせるか、危ない操作を止めるか、という管理をしているわ」
「その管理役が止まると、原因がアプリだけとは言いにくくなるのか」
「そういうことね。そもそも、ＯＳはＣＰＵが計算間違いをすることをほぼ想定していないわ。だから、ＣＰＵが計算結果や番地を間違えると、ＯＳが守っている前提そのものが崩れることがあるの」
『チューニング』（Ｔｕｎｉｎｇ、調整、最適化）
「チューニングって、速くするための調整ってことでいいのか？」
「おうよ。プログラムの並べ方、使う命令、データの置き方を、そのＣＰＵに合わせて整える作業だな」
「同じ計算でも、ＣＰＵが得意な形で渡すと速くなることがあるの。逆に不得意な形だと、せっかくの回路を使い切れないわ」
「楽器の調律みたいな名前だけど、やってることはかなり低レイヤーなんだな」
「だな。計算そのものは変えずに、ＣＰＵが走りやすいよう計算結果が狂わないように組み替えてやる、って仕事がメインだ」
「ただ、よく効くチューニングほど、普段あまり踏まない命令の組み合わせを踏むこともあるわ。検証としてはおいしいけど、バグも見つけやすくなるの」
『フラグ』（Ｆｌａｇ、状態の印）
「エラーのフラグって、旗のことか？」
「もともとはそこから来ている言葉だね。ＣＰＵや装置の中で、今こういう状態ですよ、と一ビットで立てる印のことだよっ」
「一ビット？」
「そう、オンかオフかだけの小さな印なの。実際の機械で、ランプが点いているか消えているか、くらいに考えるとわかりやすいかな？」
「致命的なエラーの印が立っていれば、調べる側も異常に気づきやすいわ。厄介なのは、間違っているのに本人が間違いだと気づいていない場合よ」
「旗が立ってないのに、実際には道を間違えてることがあるわけか。そりゃ怖いな」
「あとは、確かにエラーのフラグは立ってるけど、大元を辿ってみると全然別のところが原因だったりすることもあるわ。特に論理回路が複雑に入り混じる高速なＣＰＵでは、全然別のところに波及してようやくエラーが見えたりするのよ」
『ユーザープロセス』（Ｕｓｅｒ Ｐｒｏｃｅｓｓ）
「ユーザープロセスって、普通のアプリのことか？」
「ざっくり言えばそうだな。ＯＳから見ると、動いているプログラム一つ一つがプロセスとして管理される」
「管理されるっていうのは？」
「使っていいメモリ、持っている権限、今どこまで進んだか、そういう情報をＯＳが持つんだよ。学校で机と名札を割り当てられてる感じだな」
「信頼性とセキュリティーを保つための仕組みね。ユーザープロセスはＯＳ本体より権限が弱い設定になっているの。変な場所に触ろうとしたら、普通はＯＳがそのプロセスだけ止めるようになっているわ」
「確かに、メモリ上のほかのプログラムのデータを壊すとか、そういうことをするのはウイルスとかだもんな」
「だから、ただの計算プログラムなのにＯＳまで巻き込んで落ちるなら、もっと下の層を疑う理由になるわけだ」
『デバッガ』（Ｄｅｂｕｇｇｅｒ、デバッグ装置、調査用ツール）
「デバッガって、止まったＣＰＵの中をのぞく機械なのか？」
「まあそんなとこだな。普通はＯＳやログを使って調べるけど、ＯＳが役に立たない時は裏口からＣＰＵに入る」
「その裏口って、具体的にどんなのを使うんだ？」
「検証用に用意してある端子や経路だよ。普段のプログラム実行とは別に、外からレジスタやＣＰＵの状態を読むための入口がある」
「故障した車を、運転席からじゃなく整備用の端子につないで見る感じだよっ。普通のＯＳから読む必要はないけど、こういう変な挙動をしたときに必要なデータを取れる口を準備してあるの」
「ただし、デバッガは原因を自動で言い当ててくれる道具じゃないわ。取れるのは手がかりだけで、何が悪いかを読み取るのは人間の仕事よ」
『ダンプ』（Ｄｕｍｐ）
「レジスタダンプ、メモリダンプ、ステートダンプって、まとめて何なんだ？」
「ダンプは、その瞬間の中身をまとめて吐き出した控えだね。写真を撮るのに近いかな」
「レジスタダンプはＣＰＵの作業用メモにあたるレジスタの内容を吸い出すよ。このレジスタの値が期待と違ってたら、本当にＣＰＵが何かおかしい動きをしてないかを疑う手がかりになるのっ」
「メモリダンプは大きい作業机全体、メモリ全体や該当するプログラムが使ってるメモリの一部のデータをそのまま引っこ抜くよ。メモリの値がおかしいのか、それともＣＰＵに持ってきてから壊してるのか、壊してるならどのあたりからおかしくなってるかとかが見れるかな」
「ステートダンプは処理の進み具合の記録ね。レジスタダンプと合わせてみると、どの命令を、どんな状況で実行して、どう壊れたかを調べられるわ」
「写真だけで原因がわかるのか？」
「一枚だけだと厳しいわね。でも、正常な時と壊れた時、手前と後ろを比べると、どのあたりで値が変になったか見えてくるの」
「巨大な迷路を最初から全部歩く代わりに、途中の監視カメラ映像を集めて手がかりを集める感じだねっ」
『物理レジスタ』（Ｐｈｙｓｉｃａｌ Ｒｅｇｉｓｔｅｒ）
『レジスタ・リネーミング』（Ｒｅｇｉｓｔｅｒ Ｒｅｎａｍｉｎｇ）
「レジスタはＣＰＵの小さい作業場所、だったよな。物理って付くと何が違うんだ？」
「プログラムから見えるレジスタ名と、ＣＰＵの中に実際にある保存場所を分けて考える時の言葉よ」
「名前と実物が違うのか？」
「そうね。名札は同じでも、内部では別の引き出しを使わせることがあるわ。前の計算と後の計算を混ぜないためね」
「高速化のために、ＣＰＵは見かけよりずっと多くの引き出しを持ってるんだよね。例えばｘ６４で指示できるレジスタは十六本だけど、実際のＣＰＵだともっと多く持つんだよ」
「プログラムから指示できないんだろ？ じゃあ宝の持ち腐れになるんじゃないのか？」
「そもそも、現代の大きなプログラムを扱う上では、レジスタの十六本ってとても少ないの。だから、結構な割合でレジスタの再利用をするわ。Ａ＋Ｂ＝Ｃ、Ｃ＋Ｄ＝Ｅって計算をした後、Ｃはもう使わないから別の計算結果、例えばＦ＋Ｇの値をＣに保存する、みたいな感じね」
「その時、Ｆ＋Ｇは前に使うデータは一切使わない、つまりデータ依存性が無いから、Ｃってレジスタにこだわる必要はないでしょ？ だから、こういうときに物理レジスタの使ってないところを割り当てるんだよっ。この技術を、『レジスタ・リネーミング』って呼ぶの」
「このレジスタ・リネーミングのおかげで、プログラム上で指示されてるよりももっと大量のレジスタを使えるんだよね。もっとも、コンパイラの時点ではこの挙動を完全に最適化できないから、直接コンパイラが触れるレジスタが多い方が性能は上がりやすい、ってのも確かなんだけど」
「レジスタ・リネーミングは命令セットに手を入れずに高速化できるメリットはあるんだけど、その分ＣＰＵ側の制御は複雑になるわ。書き出し先の物理レジスタがずれたり、どこに割り当てたかを忘れて別のレジスタから持ってきちゃったら大惨事になるでしょ？」
『コミット』（Ｃｏｍｍｉｔ）
「コミットは、命令の実行結果を正式な結果として採用する段階を指すわ」
「計算が終わったら、そのまま採用じゃ駄目なのか？」
「高速なＣＰＵは、命令を見かけの順番どおりに一個ずつ終わらせるとは限らないでしょ？」
「アウトオブオーダー、って奴だったな」
「だから、先に終わった下書きがあっても、外に見せる順番は守らなければいけないの」
「下書きを清書に移すタイミング、って感じか」
「そうね。ここで早まったり、別の命令の結果を採用したりすると、ＣＰＵの中では小さなズレでも、外から見ると大事故になるわ」
『リタイア』（Ｒｅｔｉｒｅ）
「リタイアはコミットと同じ意味なのか？」
「近いけれど、命令がもう巻き戻されず、プログラム上でも完了したものとして扱われる段階、と思えばいいわ」
「巻き戻しってあるのか？」
「それが結構あるのよ。途中で例外が起きて実行が割り込まれたり、分岐予測を使って先に着手してた処理があって、その予測が外れてることがわかったら、なかったことにしないといけないでしょ？」
「だから、内部で先に進んだ命令も、最後は順番をそろえて卒業させる必要があるわけだな」
「その卒業判定がリタイアね。ここで間違うと、まだ確定してない命令の結果が混ざることに繋がるわ。当然、変なところでデータが壊れたり、プログラムがクラッシュしたりするの」
『マイクロコード』（Ｍｉｃｒｏｃｏｄｅ）
「マイクロコードって、ＣＰＵのファームウェアみたいなものなのか？」
「ざっくり言うならそれでいいぜ。ＣＰＵの中で、一部の命令や機能をどう動かすか決める手順書みたいなもんだ」
「回路そのものを後から直せるわけじゃないんだよな？」
「そう、配線を生やしたり、ＦＰＧＡみたいに全部を組み替えることはできない。でも、使う手順を変えたり、怪しい機能を切ったりできる場合はある。そのために回路側に小さな仕込みをしておくわけだ」
「壊れた道を直すんじゃなく、通行止めにして別の道を使わせる感じか」
「いい例えね。ただし遠回りになることも多いから、本命は設計を直すことよ。マイクロコードは、間に合わせるための逃げ道にもなる、という位置づけね」
「商用ＣＰＵだとこの仕込みがいろんなところにしてあって、シリコンができた後でも回路の挙動を変えられたりするな。マイクロコード・パッチとかって呼ばれるのは、この仕込みをいじってＣＰＵの動きを変えてるわけだ」
『真理値表』（Ｔｒｕｔｈ Ｔａｂｌｅ）
「真理値表は、入力の組み合わせと出力を全部並べた表よ」
「全部って、どれくらい全部なんだ？」
「たとえば入力が二つなら、〇〇、〇一、一〇、一一の四通り。入力が三つなら八通り。スイッチの数が増えるほど一気に増えるわ」
「だからＣＰＵ全部を表にするのは無理、ってことか」
「ええ。だから疑わしい小さなブロックに絞ってからじゃないと使えないわ。紙に出して赤ペンで追うのは泥臭いけれど、条件の抜けを見つけようと思うとこれに行きつく場合も少なくないわね」
「自動ツールだけじゃなくて、人間の目で表を追う場面もあるんだな」
「最近はツールがかしこくなったりシミュレーションが発達して、さすがに登板機会は減ってるけどね」
『アービタ』（Ａｒｂｉｔｅｒ、調停回路）
「そもそもアービタって何だ？ ついにまったく耳なじみのない単語なんだが」
「複数の要求が同じ場所に来た時、どれを先に通すか決める回路のことよ」
「道路の合流で、こっちの車を先、次はあっち、ってやる感じだねっ。交通整理の仕事、って感じ」
「ＣＰＵの中にも、複数から同時に使いたい場所があるわ。レジスタへ書き戻す入口、バス、キャッシュへの通路、そういう場所ね」
「全部一緒に通せないから、順番を決める回路が要るわけか」
「そういうことよ。アービタが間違うと、待たせるべき要求まで通したり、通すべき要求を落としちゃったりして、致命的なエラーに繋がったりするわ」
『レースコンディション』（Ｒａｃｅ Ｃｏｎｄｉｔｉｏｎ、競合状態）
「レースコンディションって、競争でもするのか？」
「驚くかもしれないけど、その通りよ。二つ以上の処理や信号が、どっちが先に目的地に届くかで結果が変わってしまう状態ね」
「同じ回路なのに、タイミングで結果が変わるなんてことがあるんだな」
「そうなの。ほんの少し早い、遅いことでどっちのデータを使うかが変わったりすると、結果がズレたりするわ」
「毎回必ず起きないから、検証で見落としやすいのか」
「そうなんだよねえ。この遅延って、プロセスももちろんだけど温度でも変わってくるから、特定の温度以上で起きるとか、そういうこともあるんだよ。しかも回路自体は結果が違っても動いてはいるから、もし値が「結果として出てきてもおかしくはないけど、実は条件的には間違ってる」みたいなのを取るとほんとわかりづらいんだ」
『ＯＲ』（ＯＲ、論理和）
「信号がＯＲされる、ってどういうことだ？」
「ＯＲは、いくつかの入力のうち、どちらか一方でも一なら一になる論理演算よ。日本語だと論理和とも言うわ」
「一かゼロかを混ぜるルールの一つ、ってことか」
「あたりっ。ただ、本来は片方だけ選ぶべき信号が、両方通ってＯＲされると危ないの」
「足し算みたいに合計が出るわけじゃないのか？」
「本来なら、ちゃんとＯＲ回路を使って行うべき処理だね。ただ繋いだだけだと、信号の状態によっては不定、つまりゼロとイチの間くらいの出力になったり、電流が逆流してトランジスタを壊しちゃったりするから」
『ブート』（Ｂｏｏｔ、起動）
「ブートは、電源を入れてからコンピュータが使える状態になるまでの立ち上げ作業だな」
「いきなりＯＳが動くわけじゃないのか」
「石の塊にそんな高度なことを求めるなって。具体的には、ＣＰＵの初期化、メモリの確認、周辺機器の確認、起動するプログラムの読み込み、なんかがあるな。基本はＢＩＯＳが担う仕事だな」
「ブート・シーケンスは、その順番に並んだ手順全体のことね」
「なるほどな。だからログを読むと、どこまで進んだかがわかるのか」
「そういうこと。途中で止まった場所がわかれば、電源、ＣＰＵ、メモリ、周辺機器のどこを疑うか決めやすくなるのっ」
『ＴＸＥＱ』（Ｔｒａｎｓｍｉｔ Ｅｑｕａｌｉｚａｔｉｏｎ）
「ＴＸＥＱって、ログに出てきても読み飛ばしそうなやつだな」
「ＴＸは送信、ＥＱはイコライゼーションのことだよっ。 高速信号を送る時の調整をしてる、って感じかな」
「高速信号って、普通に一とゼロを送るだけじゃ駄目なのか？」
「速くなるほど、基板の配線を通る間に波形が丸まったり、前の信号の影響を受けたりしやすいの。だから送る側で少し形を整えるんだけど、それがＴＸＥＱ」
「オートネゴシエーションは、相手と相談して設定を合わせるってことよ。どの強さ、どの補正なら安定するかをお互いに確認しながら決めるの」
「つまり、完了していれば高速な通信まわりの初期化が一つ通った、と見ればいいわけか」
「そういうこと！ たまーに自分で設定してあげないといけないときがあるけど、基本は回路がいい感じにしてくれるよう組んであることが多いよっ」
『ＣＥ』（Ｃｏｒｒｅｃｔａｂｌｅ Ｅｒｒｏｒ、訂正可能エラー）
「ＣＥは、壊れたけれど直せたエラー、という意味ね」
「直せたなら問題なしでいいのか？」
「単発なら、すぐ致命傷とは限らないからいったん問題なしとしてもいいわ。でも、頻繁に出るならメモリ、信号、電源、温度のどこかが怪しいサインになるわね」
「答案の一文字がかすれても、前後から読めて直せた、みたいな感じか」
「近いわね。直せた記録を残しておけば、あとから不安定さの兆候を追えるわ。どこのバスでＣＥが多いかがわかれば、そこが調査のきっかけになったりね」
『ＵＥ』（Ｕｎｃｏｒｒｅｃｔａｂｌｅ Ｅｒｒｏｒ、訂正不能エラー）
「ＵＥは、直せなかったエラーのことよ。ほかのデータを巻き込まないように、このエラーが出たら大体のＣＰＵは動作を止めるようになってるわ」
「検出はできたけど、正しい値に戻せないってことか」
「そう。値が信じられないなら、そのまま計算や保存に使うのは危ないでしょ？ 例えばだけど、もしかしたらストレージのデータを全部無意味なものに書き換えちゃうかもしれない、とか」
「それは確かにまずいな」
「だから、ＣＥもＵＥもなし、ってログは一旦の安心材料になるわね。もっとも、負荷を掛けた時だけ不安定になることも往々にしてあるから鵜呑みにはできないのだけど」
『ジャンパ』（Ｊｕｍｐｅｒ、設定ピン）
「ジャンパって、基板から生えてる小さいピンみたいなやつか？」
「はいっ。ピン同士を小さな部品でつないだり外したりして、基板の設定を切り替える場所です」
「設定って、たとえば？」
「起動モード、デバッグモード、電源を有効にするかどうか、クロックの選び方とか色々だよっ。今は大体ソフトで設定できるようになったから、あんまり設定変更では見なくなったね」
「でも道香が作ったみたいな開発用ボードだと、ソフトに実装するのも大変だし、設定変えてからいちいち再起動するのも大変でしょ？ だからジャンパで設定できるようにしてることもあるんだよね」
「小さい部品なのに、間違えると電源すら入らないのか」
「そうだねっ。だからなんか起動しないなー、ってときは、チップ自体を疑う前に、電源ケーブル、スイッチ、ジャンパみたいに単純な物理の状態から見てくことが多いの」
