10日目　[2]



うーむ。なるほどぉ。下じき、そしてそれらを重ね合わせると。で、各下じきにどんな管理が必要か。そして重ね合わせ順の管理と並べ替え。なるほどぉ。言われるとよく理解できるなぁ。たしかにこれらの方法が必要になるよね。



・・・でも、これは理屈が簡単で理解ができるんだけど、俗に「ベタ」と言われる方法。一回一回こんなことしてメモリコピーしてたんじゃ遅くなっちゃうってのもよくわかる。

（たとえばだけど、下敷きが10枚あるとして、一番上の下敷きが大きくて、下の9枚の下敷きが見えないなんて状態だとする。そうなると、見えないにも関わらず9枚の下敷きを書き直しているんだから、そりゃ遅くて非効率的だよね）



（余談ですが、ウチのPCでは、本に書いたある「モッサリ遅くてチラチラする」が再現できません。（汗　高速なパソコンも考え物だなぁと思う今日このごろ）

10日目　[1]　終了〜。



ええと。これはちょっとした補足だね。

ここはまあ、ツルっと・・・



（ところで、ここのコラムに出ている割り算とかの計算法。こういうのをアルゴリズムっていうのかな？。私も以前、 SHR CX,1　なんてことすると、CX÷2と同じになるなんてのを見つけたことがあります。思えばそもそも、CPUは割り算はおろか、足し算すらできないんですよね。元来。ある処理をしたら、結果的にそれが足し算や割り算と同じことになったってだけ。こういう手のアルゴリズム集みたいのって、なんかないのかな。たしか、奥村先生がそんな本出してたような・・・）

九日目 [4]　終了〜。



なーるほどなぁ。メモリ管理。思えばこんなのは、OSならではの考えかただよね。



これは究極だけど、OSが特定のソフトをたった一個だけしか動かさない、なにか専用だったら話は簡単だよね？



0x00000000〜0x100000000はOSが使う。あとは好きにしてくれ！



なんてことも可能だしね。

ところで妄想だけど、この管理部分がもし私の想像通りに使われるのだとしたら、たとえば「メモリデフラグ」みたいなのを実装できないかなぁ。ほら、たとえば「メモ帳」みたいなソフトを動かしていて、こいつが現在 0x00001000 〜 0x00002000 を使っているとするじゃない？。で、急に「画像編集ソフト」を使いたくて、どうしても連続して 0x00000500 〜 0x00030000 を使いたいなんてことが起きた場合、ソフトの使われ方や頻度を判断して、一瞬メモ帳を凍結させておいて、メモ帳が使っている範囲を0x00031000 〜 にメモリコピーして再び動作を再開させるとか。

九日目 [3]



え”〜？？？

なにこれ？　最適化？　それによって、やってほしい処理がすっ飛ばされることがある？。

ひえー。そんなことがあるの？　知らなかった。

九日目 [1]〜[2]　



メモリ管理かぁ。ええと？　自前の「メモリ総容量チェック」とな？

へー。そんなこと、考えもしなかった。なぜこんな処理を？



例えば、16bit時はBIOSが使える。OS-WikiのBIOSのページを見るとそれらしいものもあるしなぁ。これじゃ不十分なのかな？？

なになに？　このBIOSコールの戻り値(つまりメモリの量）は、AXレジスタに入ると。そうするとAXレジスタは16bitだから、最大0xffffまで。（10進数では65535）さらに、単位がKBと。65535KBってことはええと・・・あれ！！　64MBくらい？



あっちゃ〜。そうかぁ。BIOS(16bit時）じゃ、64MBまでしか教えてくれないんだ。だから、もしBIOSで確認しようって場合にはなんかメーカー独自の拡張BIOS？とかでないといけないわけね。だから本では「いろいろ違うといやだから」と書いてあるのかぁ。なーるほどぉ！！！



プログラムの理屈は解ったんだけど、「なぜそれを自前でやらなくちゃいけないのか？」が解らんかった。なるほどねぇ。

八日目 [5]。



ふむふむ。ここで積み残しの解説である「32bitモードに移行」が説明されているのか。なるほど。いろいろと細かい説明があるが、32bitへの切り替えは、まず



　・全ての割り込みを一旦禁止する。

　・KBCのおまけ回路(A20GATE)に命令し、1MB以上使えないようにしてあった関所に、「開門〜」をさせると。

　・さらにCR0レジスタに値をセットすると、保護付き32bitに切り替わる



簡単に言えば、こういうことだね。

で、単に切り替えただけだとセグメントレジスタの使い方が変化してしまうので、これのつじつまを合わせるための処理をすると。



で、最後の処理。これまでは16bitなので、0x0000 〜 0xffff までしかメモリを使えなかったと。（当然これまでは、この範囲内であれこれやり繰りしてた）

しかしこのほど、めでたく32bitになったので、こんな狭い範囲よりもっと大きな範囲が使えるようになったので、そこにメモリの内容をコピーしちゃうわけね。



※

ここで四日目に生じた私の疑問は解けた。（っというか、確認できた。）

i386CPUは、16bitから32bitに切り替わっても、それまでのメモリの内容は破壊されずにそのまま残っているのか！。つまり、



　・起動初期。まだ16bit。メモリは0x0000〜0xffffまでしか使えない

　・この時に、仮に0x1000番地に「20」を代入しておいたとする。

　・上記いろいろをやって、32bitに移行完了！

　・メモリは一気に 0x00000000〜0xffffffffまで使えるようになる。（搭載されていれば）

　・で、このとき 0x00001000番地の値を見ると、やっぱりちゃんと「20」であると！



こういうことでOKのようだ。なるほどねぇ〜。



PS：

こうして見ると、下位互換が宿命とはいえ、インテルのCPUはほんとに複雑でややこしい作りになっているんだなぁと生意気な感想が。

歴史にifは禁物だけど、もしインテルが8086との互換を無視して最初から32bitのCPUを設計し、それが当たっていたら、もっとずっと解りやすくて整合性がとれたものになっていたんだろうなぁ・・・

八日目 [1]〜[4]　終了〜。



あれ〜。いまさら気が付いたが、このマウスを動かすっていうプログラムが、もうほとんど「単なるC」で完成してる！



複雑・煩雑なハードウェアの制御と、それを行うアセンブラを関数化して追い出しているからこそなんだなぁ。

私はCはあまり得意ではないけど、164Pのこのソースはなるほどなるほどと読むことができた。おもしろ〜い。



ところで、マウスがタスクバーにかかると崩してしまうというこの動作。いまさらだけど、元来コンピュータにとっては「透明色」なんてものは存在しないんですねぇ。（いろんな高級言語上では、あったりまえに使われているものだけど、あれを支える内部プログラムはどうなってるんだろ？　例の論理演算とかを使うのかな？？？）

七日目　[6]〜[7]。終了〜。



おー！　ここはなんか、比較的ツルっと読めたぞ？

なるほどなぁ。周辺機器（今回はキーボードとマウス）からやってくる信号は基本的にはこういうパターンでOS側で受け取るのかぁ。



あとはこれらやってきた信号に対してどう反応させるか？というプログラムかな。



え”もう寝ろって？

・・・いや、そういわずに八日目に・・・（＾＾；

七日目 [1]〜[5] 終了〜。



おもしろい。ここは私でもなんとかプログラムを追うことができた。

パソコンの世界ではよくこの「バッファ」というものが出てくるよね。なんに使うか、どう動作するか。その理屈はわかっていたんだけど、こうキチンと説明してもらうとよくわかる。



ところでちょっと思ったのだが、このプログラムではバッファを使ってキーボードからの「割り込み通知＆押されたキー」の情報受け取っている。そしてさらに別の関数でそのバッファをチェックして、実際の文字表示を行っている。つまり、二重に見張りをしている。なぜこんなことをするのかというと、書いてある通り文字表示は時間がかかる処理だから。



これを私なりの理解で図化するとこういうことになるのかな？

　　　　　┌　1秒に10回見張る ─┐　┌　1秒に1000回見張る ─┐


　　　　　│　　　　　　　　　　│　│　　　　　　　　　　　│


　　　　　│このくらいの頻度で　│　│これくらい見張らないと│


画面表示←│十分　　　　　　　　│←│取りこぼす可能性がある│←キーボード


　　　　　│　　　　　　　　　　│　│　　　　　　　　　　　│


　　　　　└──────────┘　└───────────┘


　　　　　　　文字表示ルーチン　　　　　　　バッファ

なるほど。この考えを拡張していけば（たとえばこの段階ももっと何重にも増やしたりとか）していけば、高速なデータや割り込みをうまく処理できる？　のかな？？？

六日目　[6]。　これで六日目は終了〜。



・・・わー。だめだ。たしかにここは難しいよぉ！



プログラムの細かい理解はちょっと置いておこう。基本的な内容だけにしておいて2巡目に期待・・・



ここの内容は、

　・IDTの各割り込み番号部に実際に動く関数のアドレスを当て込む

　・割り込み処理は文字通り「割り込み」。なので、処理が終わった元に戻す必要がある。

　・なので、各レジスタをバッファに退避させ、処理が終わったら丸ごと元に戻して終了する



こんなとこでしょうか。