7日目終了〜。

バッファの仕組みといい、マウス回路の開放といい、ここもまたかなり濃い内容ですよね？。

(ちなみに妄想。バッファは無限ではないし、基本的には大きさを動的に変化させることはできないですよね？。なので理屈の上では「あふれ」を完全になくすことは不可能。さてそうなった場合の補助バッファみたいな仕組みってあるのかなぁ。あるいは、今使っているこのFIFOバッファはあくまでも基礎であって、なんかまた別の方法で「あふれ」が絶対に起きないようなやり方があるのかなぁ・・・）

7日目〜。

FIFOバッファの概念。
もしかしたらこれを見て、「なんだよこんな小さなバッファをイジクリまわして。ややこしいことしてるなぁ」なんて思う人もいるかもしれませんね。
でもそれは逆なのです。
バッファをこの先ずーっと32バイトや128バイトもままにする。そういう程度の反応しかしないOSと限定するなら、ここは間違っています。たかだか32回のメモリずらしのためにいろいろ工夫しているわけですからね。
バッファはかならず足りなくなります。じゃあ64バイトに。128バイトに、いやいや2MBくらい！なんてことになるんですよ。いずれ絶対に！
ここの工夫のすごいところは、「この仕組みならたとえ32バイトだろうと1GBだろうと、速度変化が起こらない」ということです。
ずらしが喰う時間をケチッているんではなく、むしろかなり巨大なバッファが将来必要になることが予測できるからこその工夫といえるのです。

P132。
いよいよバッファの説明。これはもう一度よーく理解しておかないとなぁ。





P134
むむ！！。これ重要！
前に、「アセンブラで関数を作ってCから利用」ってのがあったけど、ここではさらに、「アセンブラ内からCの関数を呼ぶ」という技を使ってる！。
これも「できる」ことだし本に現に例があるけど、この「C言語の思い込み」を知っていないとうまくいかないだけでなく、なんでおかしくなるのかがわからないんだろうなぁ。



そんなわけで6日目終了〜

P126。

うーむ。やっぱしセグメントの属性がよくわからん。
本の例ではセグメント1は全てのメモリ空間をカバーしている。
先の「重複」も疑問だけど、その全てのメモリ空間に対して
0x92という属性を当てている。読み書き可能で実行ができないセグメント。
・・・これ、今現在動いているプログラムに対して効いてしまわないのか？

棚上げにメモメモ・・・


P130
うーん！何度読んでもこの割り込みの裏技？の仕組みはすごいなぁ。なんていうんだろう？知ってしまえば「へぇ〜なるほど」程度なんでしょうけど、これを考え出して作ってしまった人はどういう頭してるんでしょうね？

6日目〜。

ふむ。makeの説明はトントンと進んで・・・

P124のdsctbl.cの部分。なんと！中ボスだ！！！


ここは、難しくはないんですよねぇ。ややこしくて煩雑なだけ。なので、初めて読まれる人は、「とにもかくにもいくつかあるGDT設定用のパラメータ(10バイト必要）を、むりやり8バイトに押し込んでいるだけ」っていう理解にして進めちゃうのがいいかも。（意外と、後でもう一回読んだりするとツルツルっと解るものですよ(^^　）

5日目終了〜

・・・さてここで、ちょっとした疑問。
P116で、セグメント1とセグメント2の設定をしてる。で、セグメント1は、0x0〜0xffffffffまで。すなわち、i386がアクセスできる全てのメモリを設定してるよね？

・・・ということは、たとえばそれ以降、どんなセグメントを宣言しても、それは「セグメント1と重複している」わけだけど、これはいいのかな？？？

セグメントはメモリを好きな大きさに仕切り、先頭を0番地扱いできる便利な機能だけど、これがなんのためにあるのかって言えば、それは「メモリのダブルブッキング」を起こしてシステムがおかしくならないようにするため。

たとえばその後は、セグメント3は0x0100〜0x0200、セグメント4は0x0201〜0x0300という設定をしたとする。プログラムAをセグメント3で。プログラムBをセグメント4で実行させれば、AとBがメモリの重複を起こすことはない。

で、ここで、プログラムしているオイラがバカなので、セグメント5を、うっかり0x0150〜0x0250に設定しちゃった。さらにそこを使って、プログラムCを動かしちゃった！

結果は当然のごとく、システムすっ飛び。まあ、それはいい。<良くないが・・・

その場合、たとえば設定時に、CPUから「バカたれ！重複してるぞ！」というようなエラーや警告が出ることはないって理解でいいのかな？（そうなんだろうなぁ。現に重複しているわけだし）

つまり、
・セグメントでちゃんと分けておけば、重複は起きない！
・「ちゃんと分ける」のはプログラマの仕事
・「ちゃんと分け」をミスれば32bitだろうとプロテクトモードだろうと逝ってしまう！

ってことでOKなのかな？？？？

わーい。あった！これこれ！

P102。下のソース。これが面白いよね。p[3]とかやってるけど、このソース内には、どっこにもp[7]なんて宣言はない！。でも使える。使えるだけじゃなくて、ちゃんと問題なく動作もしちゃう！！

これがなによりも、p[x]は配列でもなんでもないっていう証拠。
また、p[3]なんてのは、単に char *p;p=p+3;*p を、面倒なので短く書いただけに過ぎないってことが解る！


おぉ〜っと！これ重要。メモメモ・・・

　externはソース以外で準備したデータだという宣言

（これ利用して、ボタンだのタイトルバーだののデータを一まとめにしたら見た目のカスタムやりやすそうだな・・・）


むむむ！セグメンテーション！
これ、幸いオイラは1巡目で理屈の理解だけはできたんだけど、確かに今みてもむずかしいよね？
自分の理解というより、「人に説明する・教える場合、なんて言えばいいんだろう？」って考え込んじゃう。

5日目〜。

P100の付近。うんうん。思い出すなぁ。この、「構造体をポインタ化しちゃえばまるでデータベースのごとくメモリ内部を参照できる」という手法。（まさかこれが後にFDのFATの読み込み処理に活躍するとは）

おっと！。ここ重要だね。（ちょっと忘れてたのでメモメモ・・・）

・構造体をポインタ化すると当然参照は*が必要（*pが値になるのと同じ）
・ポインタ化していない構造体の内部を覗くには、構造体名.内部変数　となると。
・で、今回はポインタ化したので構造体名に*が付いて、*構造体名.内部変数の形になると。（たーんじゅん！）
・でもC言語ってバカだから、これだと勘違いするらしい
・なので、(*構造体名）.変数名って書いてやらないといけない（オバカな言語だ〜）
・基本的には、これだけ知ってればじゅーぶん！！！！
・・・・ただし、この*を使うパターンは書くのが面倒なので
・なので、構造体名->変数名という、「省略書き」がある

と・・・

積み残しの「桁指定」。だいたいまとめることができた。

たぶんこれで合っているはず！

4日目終了〜！

・・・しかしこうして改めて見ると、4日目、なかなかのボリュームだなぁ。（重要な基礎やテクニックもかなり入っていると思う）

逆に言えば、「たかだか画面に四角を三つ書く」ことがどれほど大変なことなのかってことだよね？