アカウント名:
パスワード:
「バグありコンパイラを市場に出すな」という主張なら同意できなくもないけど、 「生成バイナリのランタイム時に問題を来すような、致命的なコンパイラ」の存在を*前提*にした議論は、意味が乏しいと思うな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
一つ判ったのは… (スコア:3, すばらしい洞察)
# コンパイラが馬鹿なら、ソースを読める権限を持っている連中が言ってくる嘘も簡単に見抜けるのに…
fjの教祖様
Re: (スコア:0)
それってもしかして、
エラーだけじゃなく、
GPL違反みたいなのを探索するのも
困難になるのかな？
Re:一つ判ったのは… (スコア:1)
最適化を目一杯かけられてしまうと、区別するのに苦労する、という可能性はあるのではないでしょうか??
# 昔の MS-C なんか if/then/else で書いたのか 三項演算子で書いたのかまで露骨に判ったものなのに。
fjの教祖様
Re: (スコア:0)
ここにある寿司が「職人が握った」ものか「ロボットが握った」ものかわかりにくくなるのは、
(寿司職人にはともかく)多くの消費者にとって歓迎できることではないでしょうか。だとすれば(ry
Re:一つ判ったのは… (スコア:1)
ただし、最適化が進むことが消費者にとってうれしい話かどうかは、そうそう簡単に結論付けられる話ではない。
最適化が進んでソースコードとの対応がとりにくいコードを吐くようになったコンパイラは、それ自体の出力コードの中にバグを内包しやすい。それをデバッガで追いかけようとした場合に、どのコードがソースコードで言うどの部分の何をどうしているのか、デバッガによる対応もつけにくくなるし、アセンブリコードを表示されて「機械はギブアップしました。頑張ってね」と言われたプログラマも同じぐらい困るでしょう。つまりデバッグもとてつもなく大変になる。
結果として、ソフトウェアの品質がトータルで見ると下がってしまう可能性はあります。これは消費者にとってマイナスですよね? しかも、その下がってしまった品質ゆえに発生する障害に対する対策は、なかなか出てこなくなるって事です。アセンブラレベルで「どこ」でおかしいのかは判っても、それが「ソースコードで言うどのロジック」なのか、きちんと一対一対応しなくなるわけですから。
ようするに 最適化も 塞翁が馬 ってことですな。
fjの教祖様
Re: (スコア:0)
これまでコンパイラが「ソースコードとの対応が取りやすいバイナリコードを生成」していたとしたら、それは「コンパイラの未熟さ」によって「不本意ながら」得られてしまっていた副作用に過ぎない、と考えるほうが健全。
ましてコンパイラは、GPLチェッカーじゃないし。
# 「3Rの意識が広がったせいで、質のいい粗大ゴミが出されなくなった」と嘆いてもしょうがない。
Re:一つ判ったのは… (スコア:1)
そんなことは誰も言うておらんが…ましてやこれが意味が乏しいという事は、想像力が著しく欠けているとしか思えん。何しろこれは、古典中の古典だ。
プログラムをソースコードだけでデバッグする事は、「機種依存性」を必ず持っているプログラミング言語においては不可能だ。CとかC++は典型的に「不可能」な例だ。端的な話、アセンブリコードとのインターフェースはコンパイラの出力依存だが、「プログラミング言語」はそんなところを規定しない。
と言うことは、プログラムは必ず「ソースコード」とコンパイル結果の「アセンブリコード」のペアでデバッグされる。gdbのようなツールは「アセンブリコード」を実行していく過程を「ソースコード」にマップしてくれているわけだが、このマッピングはコンパイラの最適化技術が未熟であるが故にこそ実現可能なわけだ。
-----
有名な話だが
「コンパイラの最適化があまりにも進歩して、バブルソートのコードを組んだら勝手にライブラリのQuickソートに置き換えられていたら、デバッガはそこを実行している間ソースコードのどこを指したらいいと思う? 特にステップ実行/インストラクションステップ実行の間」
という問いがある。
個人的には「『姉が不調法をいたしまして…』と言いながら困ったような、誇らしそうな顔をしてその部分の実行が終わるのを待つ」っていう答だが、ようするに「そういう豪快なパターンマッチ & 置き換え」をやられるとデバッガは役に立たなくなる。
これはすなわち、バグを修正するまでのサイクルが長くなってしまう事を意味し、結果として修正されたバグの量が少ないまま出荷されるコードが増大する事を意味する。
-----
この問題を考えるときによく間違えるのが「バグがあるならばそういうグローバル最適化パターンとは合致しないだろう」という勘違いだ。『既存のコードをコピペした後、一部分書き換えるべきところを失念した』というタイプのバグの事を考えていない。つまり「本来合致しないはずのグローバル最適化パターンに合致してしま」ったために最適化が大幅に進んでしまうと、ソースコードロジックの間違いをデバッガでは追跡できなくなる。
.
GPL追跡がやりにくくなる、と言うのは実はこの(古典的で面白い)『バギーなソースコードに対する究極の最適化(ただしバグを修正するなどの「最終結果を変更してしまうような最適化」は含まない)は、何をもたらすのか』というテーマの1変種だ。
fjの教祖様
Re: (スコア:0)
> 「コンパイラの最適化があまりにも進歩して、バブルソートのコードを組んだら勝手にライブラリのQuickソートに置き換えられていたら、デバッガはそこを実行している間ソースコードのどこを指したらいいと思う? 特にステップ実行/インストラクションステップ実行の間」
> という問いがある。
なあんだ。
デバッガというとステップデバッガしか知らねーでやんの。
プッ
Re:一つ判ったのは… (スコア:1)
デバッガの基本がわかってねーでやんの。
全てのデバッガは「ステップデバッガ」の上にインテリゲンチャな機能をつけたものだという事を理解してから口を開きな。
fjの教祖様
Re: (スコア:0)
Re:一つ判ったのは… (スコア:1)
特にCとかでは厳しいんじゃないのかなぁ。ソースに対応する意味のある計算木なんて作れるのかしらん？
関数型や論理型になるようにプログラムを変換するとすると結局そこでソース・コードからは離れてしまうし…。
加えてアルゴリズミック・デバッギングがうまくいったとしてソース・コードの論理的な誤りは分かるだろうけど、
コンパイル＆最適化済バイナリ・コードの誤りはわからないんじゃないの？
コンパイラが無条件で信頼できて、他言語やアセンブリ言語のコードとかが混入しない前提が成り立つなら心配はいらないんだろうけども。
仮にバイナリをデバッグすべくアルゴリズミック・でバッギングに必要な情報をソースの論理的構造ではなく
コンパイル済バイナリから取り出そうとすると結局通常のデバッガと同じ問題が発生するわけで。
今やデバッガでしんどいのは別にステップ実行する機構（昔は問題だったけど最近のプロセッサはそれを支援するメカニズムを備えてることが多い）じゃなくて
マシンの状態とソースコードを結びつけるための情報を構築したり検索したりする部分だと思うわけで…。
＃昨年実際にバイナリフォーマットも決まっていない独自プロセッサ向けにデバッグ情報の抽出作業をやったのだけど
＃コンパイラのバックエンド、アセンブラ、リンカ、デバッガの間の責任分担を調整して回る作業は本気で面倒くさかったｗ
＃行番号や変数のアドレスを一貫させるだけで大騒ぎ、時間がなくなってローカル変数の生存区間は先送りしたくらいに面倒くさかった。
＃あんまりそんなことする機会もないからいい経験にはなった気がするけどその知識が役立つ日が来るのかは謎。