13日目〜。



ほうほう！

いろいろとチューニングが入ってきましたねぇ。



同じ構造なら一個にまとめてパラメータ？で管理・判断させる

わけかぁ。なるほどなぁ。





P262

・・・ここ！　ここだよここ！

いっやぁ〜。これがわからなかったんだよなぁ。今はまあ少なくとも

理屈の上では理解できるので、やーっとコードをふむふむと読むこと

ができる。

以前理解した時の記録〜。ご参考に。





ふむ〜？

一巡目にここが分からなくて猛烈にお勉強したせいか！？

なんかツルツルと解り過ぎて書くことがないぞ！？

（えっへん！！）



そんなわけで、13日目終了〜

12日目2〜



P239

ふむ。これはいつものパターン（もしくはKタンのクセ？）ですね。

　・タイマーを複数用意する

　・おのおのは構造体として定義される

　・構造体内に「マーク」用変数を置き、これにより確保開放をする

　・確保（alloc）はマークを付け、ポインタとして返してくる

　・確保し（alloc）あらためてセッティングをする



大雑把にいってこういう感じですなぁ。





P243

うーむ。1巡目もそうだったけど、このチューンは目からウロコですよねぇ？。こうやってC言語でOKの状態になり、アセンブラとご無沙汰していると忘れがちなことですねぇ。





P244

あはははは！　某OSの不具合〜（＾＾





そんなわけで、12日目終了〜

12日目〜。



タイマーですな。

ふむ・・・こういっちゃぁ生意気ですが、本に書いてあるとおり、

これまでの経験（特にGDTや画面高速描画）を踏まえると、確かに

ここは簡単ですねぇ〜。





ちょっと思い出：

1巡目の時、P235のタイマ構造体を見たとき、「ん？なんでこんなのを

構造体にするんだ？。たかだか一個の要素しかないのに？」と思い、

すぐに「あぁ！そうか！すぐに要素を増やすことがもうわかりきって

いるからかぁ」と独り言を言ったのを思い出しました。（＾＾

11日目〜



チョンチョンと進んで・・・



P216。

なる〜。どうせ絶対に受け渡す変数（構造体）なんだから、あらかじめまとめちゃう（というか、内蔵しちゃう）わけですね。



ふむふむ〜

なるほどぉ！

マップの発想はおもしろいですよね？。単純な上下関係だけの値だから計算もいらないし画面の描画をしないので早い。で、作業や計算が全部終わった後で変更箇所だけを選定して一気に書き換える。



これなら確かに早いですよね！？



・・・うーむ。しかし・・・

なんか、もっとなんかいい方法があるような気がする〜。

なにか・・・

（まあそれはとりあえずは後で自分で工夫するか！）



そんなわけで、11日目終了〜







超余談だが、そろそろ本の綴じ部がヤバくなってきた・・・（汗



オイラの場合はP224とP225の間に、糊が見えてきている。やべー！

うーむ・・・



P207のチューンの部分。プログラムは読めるんだけど、

なんだかピンとこない・・・

うまくいえないけど、もうちょっとシンプルでいい方法がなーんか

あるような気がしてならない・・・



↑

生意気盛り



そんなわけで、10日目とりあえず終了〜

む！？　メモメモ・・・



P201

sizeof (変数型）とすると、その変数（もちろん構造体も変数型の一種）が使うバイト数を自動計算してくれる





同じくメモメモ・・・（これは知っているけど）



P202

&xxx　とすると、変数xxxが使用しているメモリの番地を返してくれる

これはちょうどポインタと逆の発想だよね？





P203

はい！つらいです！　まだまだ・・・　＜ヘタレ



とはいえ、我ながらずいぶん上達したなぁとは感じます。

つらいけど読めますし、なんと生意気に「こんなベタな並べ替えじゃ数が増えたら無駄だなぁ・・・FIFOみたいなうまい方法あるはずだ」なーんて発想まで出てきますた！　（＾＾；





P207



おぉっと！　オイラ風情が考えることは当然のごとく予測済みとは！

そんなわけで、ベタな手法からチューニングへ！

10日目〜



ふむふむ。P195付近の切り上げ切捨てはおもしろいなぁ。

こういうのを「アルゴリズム」っていうのかな。

原点に立ち返れば、「CPUは計算なんか出来ない！」わけで、

「結果が常に同じになればそれでいい」という考えを先に

もっていないと、思いつくことはできないかもな部分。





ここでちょっと脱線。可読性。読みにくいより読みやすいほうがいい

のは当然だよね？。でも、この処理をパッと見た瞬間にこれが

切り上げ切り捨てだとわかる？。あるいは、アナタは慣れている

ので解るだろうけど、可読性という目で見た場合、これはどう？



少々乱暴で独断と偏見に満ちたド素人の発言ということでご容赦

頂きたいんだけど、「わかりやすい」ってのは結局は幻想なの

ではないだろうか。もちろんわかりやすくしようという努力を

否定するものではないけど、「わかりやすい」に凝り固まり過ぎて

いると、それによって失われるものが見えなくなってしまうと思う。

同時に、「オレが解るものは解りやすいもので、オレがよくわからないものは

可読性が悪くて解りにくいもの」っという偏った考えを本当にして

いないのかな？と、時々自分自身でチェックすることも大切なような

気がしてならない。

9日目〜。



うーん・・・特に記することなくスルスルっと終了。

（2巡目の強み？？）　（＾＾

8日目2〜



・・・って言っても、実は2ではなかったり。

いやね、ちょっと間が空いてしまったので復習〜。



えっと、まず、前回わかんなくなっちゃった部分。





棚上げ点だが：

GDT。GDTは0番〜8129番まで用意されている。各セグメントの設定はこの8000個あるGDTに好きに設定できると。ただし、0番だけはヌルセレクタといい、どういうわけか設定が出来ない特別なものらしい。

GDT0番の位置はメモリのどこでもよいが、8の倍数になる番地でないと遅くなってしまうと。





こういうことでいいのかな？？？





また前回ちょっと混乱してしまった「LGDT命令」だけど、これはなんのことはない、アセンブラ（CPU）にそういう名前の命令があるというだけですた・・・（見落としもいいとこ）



LGDTは、なんのことはない、「今後はこの番地をGDTの先頭にするよ！」という設定をCPUに行うと。ただそれだけでした〜



そんなわけで、8日目終了〜

8日目〜。



この、「マウスの信号は3バイトで一組。でも万が一取りこぼし等があった場合の対処」ってのが面白い。こういう考え方のパターンはたぶん他の部分でもいろいろ使えるのだろう。



うにゃ〜！！！

P170付近。やっていることの理屈は十分理解できるんだけど、セグメントやらと絶対番地の照らし合わせがややこしい！。





ALIGNB命令：キリがよくなるまでDB 0を代入せよ！（便利な命令があるなぁ）



P173

ん？ん？ん？？？？

GDT0はセグメントを定義できないと。

GDTR0はLGDT命令？？　なんだこれ？？？　え〜？　わからん？？