アカウント名:
パスワード:
10 年以上前、組み込みでほとんど自分一人で作っておきながらどうしても取れなかったバグが一つだけあります。x86 系列の組み込み用 CPU で、確か MS-C(≠VC++) を使って書いていました。
どのくらいの頻度/再現性だったかは忘れましたが、そのバグとは
あるサブルーチンから帰ってくると BP レジスタが奇数番地を指している(下位一ビットが立っている)
というものです。return 直前の値を examine しても偶数だし、return 後すぐに(他の割り込みが入る前に)確認したスタック上の値も偶数。なのに制御が返ってくると BP レジスタは奇数。C でこんなバグ作り込む方が難しいと思うんですが。
出先の上司を含めた会議で「どうしてもわからない」ということで return 後に BP レジスタの下位一ビットをマスクするコードを入れて試験通しました…。
# 未だに謎。
CPUというかFPUだけど、68881の計算で見事にハマった覚えがある。当時のギリギリの速度の画像処理の為には、アセンブラでガリガリ書くしか無かった。でもって、それまでは「高級言語と違い、アセンブラはウソをつかない」と信じていた。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
ごめんなさい (スコア:2)
10 年以上前、組み込みでほとんど自分一人で作っておきながらどうしても取れなかったバグが一つだけあります。x86 系列の組み込み用 CPU で、確か MS-C(≠VC++) を使って書いていました。
どのくらいの頻度/再現性だったかは忘れましたが、そのバグとは
あるサブルーチンから帰ってくると BP レジスタが奇数番地を指している(下位一ビットが立っている)
というものです。return 直前の値を examine しても偶数だし、return 後すぐに(他の割り込みが入る前に)確認したスタック上の値も偶数。なのに制御が返ってくると BP レジスタは奇数。C でこんなバグ作り込む方が難しいと思うんですが。
出先の上司を含めた会議で「どうしてもわからない」ということで return 後に BP レジスタの下位一ビットをマスクするコードを入れて試験通しました…。
# 未だに謎。
Re:ごめんなさい (スコア:0)
あと、アセンブルコードによってはCPUのバグにはまることもある。
アセンブルコードとしては大局的には同じ意味なのだが2通りの表現方法があるとして、
片方は正常、別の方は異常値が返るという経験はありました。(8086系)
Re: (スコア:0)
CPUというかFPUだけど、68881の計算で見事にハマった覚えがある。
当時のギリギリの速度の画像処理の為には、アセンブラでガリガリ書くしか無かった。
でもって、それまでは「高級言語と違い、アセンブラはウソをつかない」と信じていた。
Re: (スコア:0)
>でもって、それまでは「高級言語と違い、アセンブラはウソをつかない」と信じていた。
#1575175の時は2種類のアセンブラを使ってました。
んでもって、解釈の違いから生成される機械語が違ってて、それがバグを生んでいたという。
アセンブルソースとしてはどちらも同じだったから、分かり難かった‥。
(ビットフラグの「未定」の扱いを0にしておくか1にするかの違い)
ICEでデバッグして原因がやっと分かったという。(泣)