if で弾かれた直後 else if を評価する間の一瞬のタイミングで a が化けたのを検出するということなのでしょうか? それが問題になるような確率で発生するのであれば この if 文全体の前後でかなり高確率で化けてるでしょうし、 それよりもはるかに大きな確率でロジック自体のバイナリがダメージを受けてる気がするのですが? 例えば a == 1 の 1 や a != 1 の 1 が化けてたり、je が jne に化けてたり
仮に a の値化けを検出するにしても a = b = 0; のように値を別の変数にも複製しておいて if (a && a == b) { ... } else if (!a && a == b { ... } else { エラー } とした方が実用的なのでは?
普通にやりませんか? (スコア:1)
制御機器のプログラムだと、物理メモリアクセスに対して常時パリティチェックをかけるような専用タスクが走らせるのは
ごく普通にありますよ。
あと、たとえば
if a==1 {
// aが1のとき
func_1();
} else if a!=1 {
// aが1以外のとき
func_2();
} else {
// 正常ならここは通らないはず
kick_NMI();
}
などというコーディングはフェイルセーフプログラミングでは常識と思っているのですが、
このくらいなら普通のプログラマでも普通にやるのでは?
#もちろん実際にはオプティマイズでコード削除されないようにしますが
このコードの意図が理解できない (スコア:2, 興味深い)
if で弾かれた直後 else if を評価する間の一瞬のタイミングで
a が化けたのを検出するということなのでしょうか?
それが問題になるような確率で発生するのであれば
この if 文全体の前後でかなり高確率で化けてるでしょうし、
それよりもはるかに大きな確率でロジック自体のバイナリがダメージを受けてる気がするのですが?
例えば a == 1 の 1 や a != 1 の 1 が化けてたり、je が jne に化けてたり
仮に a の値化けを検出するにしても
a = b = 0;
のように値を別の変数にも複製しておいて
if (a && a == b) { ... }
else if (!a && a == b { ... }
else { エラー }
とした方が実用的なのでは?
uxi
Re:このコードの意図が理解できない (スコア:1)
タレコミのツイート [twitter.com]
「宇宙線が降ってきてメモリのビットが狂う」「ハードウェアのバグでメモリのビットが狂う」というのは非常にまれな現象だけど、Chromeくらいのユーザ数規模になるとけっこう日常的に起きます。なのでChromeで走ってるGCには、それらのビット異常を検知する機構をわざわざ入れてます。
実際の仕組みは知りませんが、プログラマが意識しなくてもGCがやってくれるところがポイントなんですかね。
Re: (スコア:0)
ノードの管理情報に冗長性持たせてGCでチェックしてるとかその程度の話じゃない?
Re:このコードの意図が理解できない (スコア:1)
サンプルコードが(擬似コードで)言いたい事のわりにはしょってるのでコメントが伸びているような。
想像するに、RAMは化ける可能性があるけどROMやCPUはハード的に保護して信頼性高くしてあって、というようなシステムのようだけど、RAMから呼んだ値はレジスタに置いて if 文を通るようにコーディングするんではないかな。普通ならやれることもできない、あれこれ制約されたコーディング規約もついて。
もしCPU/ROMもずっこけるというのなら、同一構成のシステム複数で多数決するとかなんとかしてやるだろうからif文でどうこうという話にはならないだろうし。
Re: (スコア:0)
・信頼できないデータを読んですぐ分岐するというのが理解できない
・もしa==1とa!=1でaを二回読んで欲しいというのなら、オプティマイズがどうのというのが理解できない
Re: (スコア:0)
クセにしといた方がいいですね。
ステートマシンの未定義ステートで元に戻すorリセット掛ける
# ムーアマシン ミーリマシン? 昔のことは忘れた
Re: (スコア:0)
条件式がa==1とa!=1ならそんなことしませんよ
a!=1と書くこと自体がバグの元
switch文の場合、行くはずのないdefaultに行くバグはあるから、それとごっちゃになってませんか
Re:普通にやりませんか? (スコア:1)
どうしてもこう書きたいならaはvolatileにしないといけないはずですが
Re: (スコア:0)
> #もちろん実際にはオプティマイズでコード削除されないようにしますが
Re: (スコア:0)
オプティマイズの問題だと思っているところが、問題なんです
Re: (スコア:0)
何を言いたいのかわかりませんが、
aがvolatileだろうが、volatileでなかろうがそういう問題ではなく、
a==1とa!=1が同時に成立する場合があり得るので、
そういう場合には、
> // 正常ならここは通らないはず
> kick_NMI();
を実行させる。
そんな事情わからないコンパイラが、勝手にオプティマイズで消す可能性があるので、
>#もちろん実際にはオプティマイズでコード削除されないようにしますが
ってことでしょ。
>条件式がa==1とa!=1ならそんなことしませんよ
>a!=1と書くこと自体がバグの元
とか、
>どうしてもこう書きたいならaはvolatileにしないといけないはずですが
とか、論外。
ビットが安定していることが前提の世界の話ではない。
Re: (スコア:0)
> a==1とa!=1が同時に成立する場合があり得る
同時はおかしいだろ。
Re: (スコア:0)
ソースレベルだとそうだけど、バイナリレベルだとどちらかの「1」のビットが乱れればあり得る。
Re: (スコア:0)
量子コンピューターでもお使いなのでは。
Re: (スコア:0)
cmp a, #1
beq label1
bne label2
仮に上のような例で両方の条件分岐が成立するとしても、同時に判定しないので先に判定したほうが優先されるだけ。
Re: (スコア:0)
バイナリレベルだとコンパイラが2つ目の「1」を消していることがありうる。volatileを使わなければ。
Re: (スコア:0)
> aがvolatileだろうが、volatileでなかろうがそういう問題ではなく、
> a==1とa!=1が同時に成立する場合があり得るので、
RAMが化けるという話であれば、RAMをそのつど読むか一度読んだ値を使いまわすかは重要な話では?
Re: (スコア:0)
CPUのレジスタの値が信用できないとなると、ハードの設計ミスですよねえ
Re: (スコア:0)
この人はいったいvolatileをどう理解しているんだろう…
Re: (スコア:0)
メモリやレジスタに対して起きるソフトエラーを扱ってるとすると、破れるのは評価の間の値の不変性なので、その様な仮定をコンパイラに課さない方法はまさにvolatileです。
そもそも"同時"の意味が分かりません。
Re: (スコア:0)
>a==1とa!=1が同時に成立する場合があり得る
同時に成立したら func_1() が呼ばれるから、
「どちらも成立しない場合があり得る」じゃないかい?
Re: (スコア:0)
IC内のロジック設計でも同様です。
信頼性を確保する必要がある用途では、常時内部レジスタのチェックをかけてます。
Re: (スコア:0)
func_1() 等関数呼び出しを平気で行っていますが、スタックに詰まれる等する戻り番地の内容の保証はどうしてるんですか?
Re: (スコア:0)
内容の保証をしたいのではなくて、
値が壊れる可能性の存在をチェックしたい(その可能性を検知したらそこで死んで欲しい)のでは?
おそらく、 kick_NMI() からは戻ってこない。
Re: (スコア:0)
if a==1 {
が成立して func_1() が呼ばれても戻り番地が壊れれば安全に帰って来なくなるのでチェックは必要だと思いますが。
Re: (スコア:0)
そういうのは C で書いても意図が分かりにくいんで
アセンブリレベルでどういうことを意図しているのか
説明してください。
Re: (スコア:0)
if と elsif が混ざるのがいやなので
if (0) {
}
elsif (いっこめの条件) {
}
elsif (にこめの条件) {
}
else {
kick_NMI();
}
と書いています