faq/c08-15
の編集
http://hrb.osask.jp/wiki/?faq/c08-15
[
リロード
|
差分
|
単語検索
|
一覧
] [
編集
|
バックアップ
|
添付
]
-- 雛形とするページ --
A
Akkie
Athlon64X2
Clover
DAsoran
Falcon
FormatRule
FrontPage
Genesis
Help
I
InterWikiName
InterWikiSandBox
InterWikiテクニカル
Jormungand
K
Kebo
Kor_Lee_Hee_Rak
Leaf
Linux
Linux/wako_memo
MOIZ99
MW
MenuBar
OSC
PG_MANA
ReadersOS
RecentDeleted
SKYDASH
SandBox
Sero
Sigle
Source
Triangle_Ld.
Zxcvbnm
advance
advance/CPU
advance/FDC
advance/FPU
advance/NotHariMain
advance/QEMUVGA
advance/RTC
advance/blike
advance/cpu_reset
advance/driver
advance/driver/01
advance/driver/02
advance/families
advance/filesystem
advance/fwrite
advance/hddboot
advance/he86
advance/hints
advance/ipl
advance/kernel
advance/keycode
advance/osselect
advance/smaller1
advance/startup
advnace/smaller2
anzy
aotatsu
banbi-
bluedwarf
bo
bugs
challengers
cybozulabsyouth11
deskmanta
esb02b
faq
faq/advance
faq/asm
faq/c00-03
faq/c04-07
faq/c08-15
faq/c16-23
faq/c24-31
faq/make
faq/others
faq/qemu
guide
guide03
guide05
guide07
hikarupsp
imp_log/0000
imp_log/0001
imp_log/0002
imp_log/0003
impressions
index
k
killer_elf
kota
lea
lea/10_memory
lea/4_color
lea/idea
lea/terms
links
logs
logs/osa_hrb/comments0000
logs/osa_hrb/rumors0000
masa
members
message
mistakes
moge32
moppoi5168
notice
osdevjp
populars
prog_index
projects
q_and_a
q_and_a_2
qa_log/0000
qa_log/0001
qa_log/0002
qa_log/0003
qa_log/0004
qa_log/0005
qa_log/0006
qa_log/0007
qa_log/0008
qa_log/0009
quark
rankings
rule
sakamoto
sasaki
spc09
spcc_30min_os
tatsu
tools
tools/bim2hrb
tools/bin2obj
tools/cc1
tools/edimg
tools/gas2nask
tools/makefont
tools/nask
tools/obj2bim
tools/sjisconv
uchan
uho
updates
violations
wako
white
win64-bit
x
ytakano
ヘルプ
リックス
質問します
整形ルール
本は買ったぞ!持ってるぞ!
練習用ページ
* 8章〜15章にまつわるQ&Aのまとめ -(by [[K]], 2006.03.28) -いろいろQ&Aが集まったと思うので、ここにまとめておこうと思います。 -ここで答えが見つからなければ、[[q_and_a]]へ! *** 質問と答え -COLOR(#0000ff){[p.167(8-5)] プロテクトモード移行に関して、MOV CR0,EAXの時点ではCSやDSは0のままだけど、これでいいのか? GDTの0番のセグメント設定を見ると、これはよくないように見えるが・・・。} --はい。実はCR0を切り替えただけでは、CPUはGDTを参照しません。セグメントは16bitモードのときのまま解釈されます。GDTを参照するのは、DSやESなどへ値を代入するときです。もしくはfar-JMPやfar-RETなどでCSに値を代入するときです。逆にいうと、それまではGDTの準備が完了していなくてもいいくらいなのです。 -COLOR(#0000ff){[p.179(9-2)] memtest_subのnot_memory:のところで、 *p = old; という処理は必要ないのではないか?だってメモリがつながっていないところに値を書き込んでもどうせ記憶されないんだから。} --大変鋭い指摘です。確かに番地につながっているのが、RAMやROMだけしかないのであれば、oldの書き戻しは完全に不要な処理といえます。しかし実際はRAMでもROMでもないものがつながっている場合もたまにあります。よくあるのがメモリ接続型I/Oで、これはつまり、IN命令やOUT命令ではなくMOVで制御するタイプの装置です(そういう装置もたまにあるんです)。こういうものがつながっている場合は、それぞれのビットに意味があって、でも一部のビットだけが"1"に固定されているとか、そういうことがよくあります。そういうものであれば、memtest_subはメモリではないと気が付くことができます。このようなものの場合、勝手に反転した値を書いたままではなにか副作用を起こしてしまうかもしれないので、元の値に戻したほうがいいと思います。・・・とまあそんなわけで、たぶん多くの場合ではこのような復元処理は不要であろうとは思いますが、場合によっては役に立つので入れています。入れてもそれほど処理が遅くなるわけではありませんしね。 -COLOR(#0000ff){[p.180(9-2)] メモリ容量チェックにおいて、チェックを3GBまでとしているのはなぜですか?} --PentiumなどのCPUは最大で4GBのメモリを認識できますが、この4GBのすべてが普通のメモリになるわけではなく、たいていは後ろのほうがVRAMなどになっています。こういう普通じゃないメモリを全部足しても1GB程度で済むかなと思って、3GBまでのチェックにしました。・・・もちろん3.5GBとか3.9GBまでのチェックにしてもいいのですが、実際問題としてメモリスロットの数を考えると、そういう半端な容量は実現しないような気がします。合計4GBのメモリをつけたときには普通のメモリとVRAMがつながってしまうかもしれません。その場合、どこまでが普通のメモリか分からなくなるので、とりあえず安全策として3GBで打ち切ることになります(最近のグラフィックカードのVRAM容量は512MBくらいあり、さらに他のメモリ入出力型装置も使うかもしれないことを考えると、やっぱり3.0GBを越えてチェックするのは少々怖い気がします)。 -COLOR(#0000ff){[p.184(9-3)] memtest_subをわざわざアセンブラで書き直さなくても、pをvolatile属性にすればいいのでは?} --実はそのとおりです。でもvolatile属性をつけて終わりにしてしまう方法で解決してしまうと、いざというときはアセンブラで書き直す(たとえばコンパイラのバグに悩まされた場合など)みたいな場合に応用がきかないのです。さらに、どっちが説明がわかりやすくて話が面白いかなーと考えて、結局本文はアセンブラで解決する話にしました。実はコラムでvolatileのことを少し紹介しようと思っていたのですが、締め切りに追われているうちに書き忘れてしまいました。そんなわけで、volatileについて一言も書いてなくてどうもすみません。 * こめんと欄 -本文に間違いを発見しました。&br;「締め切りに終われているうちに」=>「締め切りに追われているうちに」 -- [[Triangle Ld.>Triangle_Ld.]] SIZE(10){2010-04-07 (水) 20:17:24} -どうもありがとうございます、なおしました。 -- [[K]] SIZE(10){2010-08-08 (日) 09:18:28} #comment
タイムスタンプを変更しない
* 8章〜15章にまつわるQ&Aのまとめ -(by [[K]], 2006.03.28) -いろいろQ&Aが集まったと思うので、ここにまとめておこうと思います。 -ここで答えが見つからなければ、[[q_and_a]]へ! *** 質問と答え -COLOR(#0000ff){[p.167(8-5)] プロテクトモード移行に関して、MOV CR0,EAXの時点ではCSやDSは0のままだけど、これでいいのか? GDTの0番のセグメント設定を見ると、これはよくないように見えるが・・・。} --はい。実はCR0を切り替えただけでは、CPUはGDTを参照しません。セグメントは16bitモードのときのまま解釈されます。GDTを参照するのは、DSやESなどへ値を代入するときです。もしくはfar-JMPやfar-RETなどでCSに値を代入するときです。逆にいうと、それまではGDTの準備が完了していなくてもいいくらいなのです。 -COLOR(#0000ff){[p.179(9-2)] memtest_subのnot_memory:のところで、 *p = old; という処理は必要ないのではないか?だってメモリがつながっていないところに値を書き込んでもどうせ記憶されないんだから。} --大変鋭い指摘です。確かに番地につながっているのが、RAMやROMだけしかないのであれば、oldの書き戻しは完全に不要な処理といえます。しかし実際はRAMでもROMでもないものがつながっている場合もたまにあります。よくあるのがメモリ接続型I/Oで、これはつまり、IN命令やOUT命令ではなくMOVで制御するタイプの装置です(そういう装置もたまにあるんです)。こういうものがつながっている場合は、それぞれのビットに意味があって、でも一部のビットだけが"1"に固定されているとか、そういうことがよくあります。そういうものであれば、memtest_subはメモリではないと気が付くことができます。このようなものの場合、勝手に反転した値を書いたままではなにか副作用を起こしてしまうかもしれないので、元の値に戻したほうがいいと思います。・・・とまあそんなわけで、たぶん多くの場合ではこのような復元処理は不要であろうとは思いますが、場合によっては役に立つので入れています。入れてもそれほど処理が遅くなるわけではありませんしね。 -COLOR(#0000ff){[p.180(9-2)] メモリ容量チェックにおいて、チェックを3GBまでとしているのはなぜですか?} --PentiumなどのCPUは最大で4GBのメモリを認識できますが、この4GBのすべてが普通のメモリになるわけではなく、たいていは後ろのほうがVRAMなどになっています。こういう普通じゃないメモリを全部足しても1GB程度で済むかなと思って、3GBまでのチェックにしました。・・・もちろん3.5GBとか3.9GBまでのチェックにしてもいいのですが、実際問題としてメモリスロットの数を考えると、そういう半端な容量は実現しないような気がします。合計4GBのメモリをつけたときには普通のメモリとVRAMがつながってしまうかもしれません。その場合、どこまでが普通のメモリか分からなくなるので、とりあえず安全策として3GBで打ち切ることになります(最近のグラフィックカードのVRAM容量は512MBくらいあり、さらに他のメモリ入出力型装置も使うかもしれないことを考えると、やっぱり3.0GBを越えてチェックするのは少々怖い気がします)。 -COLOR(#0000ff){[p.184(9-3)] memtest_subをわざわざアセンブラで書き直さなくても、pをvolatile属性にすればいいのでは?} --実はそのとおりです。でもvolatile属性をつけて終わりにしてしまう方法で解決してしまうと、いざというときはアセンブラで書き直す(たとえばコンパイラのバグに悩まされた場合など)みたいな場合に応用がきかないのです。さらに、どっちが説明がわかりやすくて話が面白いかなーと考えて、結局本文はアセンブラで解決する話にしました。実はコラムでvolatileのことを少し紹介しようと思っていたのですが、締め切りに追われているうちに書き忘れてしまいました。そんなわけで、volatileについて一言も書いてなくてどうもすみません。 * こめんと欄 -本文に間違いを発見しました。&br;「締め切りに終われているうちに」=>「締め切りに追われているうちに」 -- [[Triangle Ld.>Triangle_Ld.]] SIZE(10){2010-04-07 (水) 20:17:24} -どうもありがとうございます、なおしました。 -- [[K]] SIZE(10){2010-08-08 (日) 09:18:28} #comment
テキスト整形のルールを表示する