page0010
の編集
http://osecpu.osask.jp/wiki/?page0010
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
単語検索
|
最終更新
|
ヘルプ
]
-- 雛形とするページ --
BracketName
FormattingRules
FrontPage
Fulyn
Fulyn-v2
Fulyn_Samples
Help
InterWiki
InterWikiName
InterWikiSandBox
K
KOR_PIT8254
KWVM.NET
Liva
MANA
MenuBar
OSECPU_FPGA
PG_MANA
PHP
PukiWiki
PukiWiki/1.4
PukiWiki/1.4/Manual
PukiWiki/1.4/Manual/Plugin
PukiWiki/1.4/Manual/Plugin/A-D
PukiWiki/1.4/Manual/Plugin/E-G
PukiWiki/1.4/Manual/Plugin/H-K
PukiWiki/1.4/Manual/Plugin/L-N
PukiWiki/1.4/Manual/Plugin/O-R
PukiWiki/1.4/Manual/Plugin/S-U
PukiWiki/1.4/Manual/Plugin/V-Z
RecentDeleted
SandBox
WikiEngines
WikiName
WikiWikiWeb
YukiWiki
hikalium
hikarupsp
hikarupsp_ELCHNOS
hikarupsp_ELCHNOS_IDE
hikarupsp_FrontEndCode
hikarupsp_WebCPU-VM
hikarupsp_WebCPU-VM_internal
hikarupsp_study_hh4
impressions
impressions0000
jpag0000
jpag0001
jpag0002
jpag0003
jpag0004
jpag0005
lambdalice
mandel59
members
memo0000
memo0001
memo0002
memo0003
memo0004
memo0005
memo0006
memo0007
memo0008
memo0009
memo0010
osask
osecpu4android
page0000
page0001
page0002
page0003
page0004
page0005
page0006
page0007
page0008
page0009
page0010
page0011
page0012
page0013
page0014
page0015
page0016
page0017
page0018
page0019
page0020
page0021
page0022
page0023
page0024
page0025
page0026
page0027
page0028
page0029
page0030
page0031
page0032
page0033
page0034
page0035
page0036
page0037
page0038
page0039
page0040
page0041
page0042
page0043
page0044
page0045
page0046
page0047
page0048
page0049
page0050
page0051
page0052
page0053
page0054
page0055
page0056
page0057
page0058
page0059
page0060
page0061
page0062
page0063
page0064
page0065
page0066
page0067
page0068
page0069
page0070
page0071
page0072
page0073
page0074
page0075
page0076
page0077
page0078
page0079
page0080
page0081
page0082
page0083
page0084
page0085
page0086
page0087
page0088
page0089
page0090
page0091
page0092
page0093
page0094
page0095
page0096
page0097
page0098
page0099
page0100
page0101
page0102
page0103
page0104
page0105
page0106
page0107
page0108
page0109
pagenames
populars
seccamp2013
seccamp2014
seccamp2017
ttwilb
ttwilb-asmi
yao
* エラーの話題 -(by [[K]], 2013.03.21) ** エラーの分類 -[[page0009]]の(9)や(13)で、エラー処理の話を書いた。エラーと言ってもいろいろ種類があって、これを同列に議論するのはいけないと思う。 ---- -(1-1) 事前に簡単にチェックできそうなもの -(1-2) 事前の予知が難しいもの(環境や自分以外の要因によるもの) ** エラーはどのように処理するべきか -(2-1) たとえばx86では、シフト命令でシフト回数にCLレジスタを指定することができる。しかしCLが32を上回った時どうなるのかというと、なんとCLを「32で割った余りの回数」だけシフトするということになっている。 -この仕様は自然ではない。たとえばシフトしすぎで結果が0になるとかならまだわかる。 -まあCPU設計者の気持ちとしてはこういう仕様にしておけばCLのうちの5ビットだけを見ればよいということなのだろう。問題はハードウェアの複雑さにも影響するのでこれはやむを得ないのかもしれない。 -しかしなんにせよ、こういう感じの仕様はOSECPUでは許されない。・・・OSECPUなら、32以上が指定されたらエラーである。その方がずっと親切だ。もし32で割った余りで処理してほしいのなら、呼び出し元がそうすればいいだけのことなんだから。 -(2-2) 他にも、たとえば表示域が20文字しかない状況で、100文字の表示を要求されて、その場合ははみ出した部分は適当に切り詰めて画面外に出ないようにするという仕様があったとする。これもよくない。これも20文字以上だったらエラーにするべきだ。 -(2-3) 勝手に丸めてエラーが起きないような状況にするというのは、気が利いているようで実は気が利いていない。エラーはもっと積極的におこすべきだ。丸めてほしいのなら呼び出し元が明示的に丸めればよい。 -なぜこんなことを言うのかというと、もしかしたらそれは不具合やバグのきっかけかもしれないからだ。それを「勝手に」気を利かせて、ごまかしてしまえば、不具合に気付くのが遅れる懸念がある。これはOSECPUの考え方に合わない。だからダメなのである。 ---- -(2-4) エラーを検出した場合、とにかく止まってしまうのが一番いいように思う。不具合なのだから継続はできない。たとえばログに残して適当に丸めて実行を継続したりすると、気づけないかもしれない。なんというかそういう扱いにするとC言語の警告みたいに扱われて、結局は無視されてしまうだろう。 -エラーで止まる場合、メモリ上の内容が破棄されて復元不能になっているのはいただけない。これはOSで何とかする必要がある。逆に考えて、もしエラーで止まってもデータが何も失われないのであれば、エラーで実行を止めてしまうことは怖くなくなる。そうすれば容赦なく止めてしまえと思うようになるだろう。だから失わない方法を検討したい。エラー時のデータが残っていれば、エラー原因を探るのも容易だ。 ** こめんと欄 -このページにこめんと欄はありません。このページの内容にコメントしたいときは[[impressions]]にお願いします。
タイムスタンプを変更しない
* エラーの話題 -(by [[K]], 2013.03.21) ** エラーの分類 -[[page0009]]の(9)や(13)で、エラー処理の話を書いた。エラーと言ってもいろいろ種類があって、これを同列に議論するのはいけないと思う。 ---- -(1-1) 事前に簡単にチェックできそうなもの -(1-2) 事前の予知が難しいもの(環境や自分以外の要因によるもの) ** エラーはどのように処理するべきか -(2-1) たとえばx86では、シフト命令でシフト回数にCLレジスタを指定することができる。しかしCLが32を上回った時どうなるのかというと、なんとCLを「32で割った余りの回数」だけシフトするということになっている。 -この仕様は自然ではない。たとえばシフトしすぎで結果が0になるとかならまだわかる。 -まあCPU設計者の気持ちとしてはこういう仕様にしておけばCLのうちの5ビットだけを見ればよいということなのだろう。問題はハードウェアの複雑さにも影響するのでこれはやむを得ないのかもしれない。 -しかしなんにせよ、こういう感じの仕様はOSECPUでは許されない。・・・OSECPUなら、32以上が指定されたらエラーである。その方がずっと親切だ。もし32で割った余りで処理してほしいのなら、呼び出し元がそうすればいいだけのことなんだから。 -(2-2) 他にも、たとえば表示域が20文字しかない状況で、100文字の表示を要求されて、その場合ははみ出した部分は適当に切り詰めて画面外に出ないようにするという仕様があったとする。これもよくない。これも20文字以上だったらエラーにするべきだ。 -(2-3) 勝手に丸めてエラーが起きないような状況にするというのは、気が利いているようで実は気が利いていない。エラーはもっと積極的におこすべきだ。丸めてほしいのなら呼び出し元が明示的に丸めればよい。 -なぜこんなことを言うのかというと、もしかしたらそれは不具合やバグのきっかけかもしれないからだ。それを「勝手に」気を利かせて、ごまかしてしまえば、不具合に気付くのが遅れる懸念がある。これはOSECPUの考え方に合わない。だからダメなのである。 ---- -(2-4) エラーを検出した場合、とにかく止まってしまうのが一番いいように思う。不具合なのだから継続はできない。たとえばログに残して適当に丸めて実行を継続したりすると、気づけないかもしれない。なんというかそういう扱いにするとC言語の警告みたいに扱われて、結局は無視されてしまうだろう。 -エラーで止まる場合、メモリ上の内容が破棄されて復元不能になっているのはいただけない。これはOSで何とかする必要がある。逆に考えて、もしエラーで止まってもデータが何も失われないのであれば、エラーで実行を止めてしまうことは怖くなくなる。そうすれば容赦なく止めてしまえと思うようになるだろう。だから失わない方法を検討したい。エラー時のデータが残っていれば、エラー原因を探るのも容易だ。 ** こめんと欄 -このページにこめんと欄はありません。このページの内容にコメントしたいときは[[impressions]]にお願いします。
テキスト整形のルールを表示する