openbsdの新しいコンパイラー

メッセージosnews.com/story.php/18771/More-on-OpenBSDs-New-Compilerに基づく



数週間前、OpenBSDプロジェクトは、ポータブルCコンパイラがOpenBSDソースツリーに追加されたことを発表しました。 そして、開発者はそれをGCCの完全な代替品にしようとします。 なんで?



Mark Espie undeadly.org/cgi?action=article&sid=20070915195203&pid=52によると、その理由はGCC開発者がOpenBSD開発者とは異なる目標を追求するためです。 彼は次の点で違いを示しています。



(1)GCCは現在、ほとんど商業的に開発されています。 商用LinuxおよびAppleディストリビューションのディストリビューターによって処理されます。 コンパイラは、高速のi386およびPowerPCプロセッサのみを対象としています。 同時に、彼はSPECの一連の高いポイントの下で研ぎ澄まされています。 (私から)ご存知のように、特定のプログラム用のコンパイラーの研ぎ澄ましは昔ながらの方法で行われます-テンプレートのベースは単純に増加し、コンパイラーはそれを人が書いたコードを認識して発行する必要があります。 したがって... (マークより)しかし、コンパイラはどんどん大きくなり、どんどん遅くなっていきます。 (私から)過去数年で後悔したGentooユーザー



(2)GCC警告は役に立ちません。 -Wallを使用してコンパイルすると、多くの本当のことと、少数の誤ったものが報告されます。



(3)GCC設計全体が非常に歪んでいるため、誰もコンパイラのフロントエンドとバックエンドを隔離することさえできません(私からの真実:私は、非レジスタアーキテクチャの理解を教えるためにgccをどのように愛したかを覚えています) 。 GPLの人々は、商業組織がバックエンドまたはフロントエンドを盗み、それらを閉じた言語またはコードジェネレーターにアタッチできることを恐れているため、デザイン(デザインによって破損)から始めると不器用です( ただし、奇妙な結論です 。 おそらくこれは本当です。 しかし、これでは、ミドルウェアアナライザーなどの興味深いツールを作成できません。 また、新しいコンパイラで古いアーキテクチャのバックエンドを使用することもできません。



(4)その結果、古い興味深い機能を失うことなく、GCCの新しいバージョンの興味深い新しい機能を取得することは不可能です(私から:QEMUをコンパイルするには、GCC 3を持ち歩く必要があります)... GCCの各更新はエンジニアリングの悪夢です。簡単な選択はありません。チャンスはありますが、重要な機能は失われます。 (私から)さて、実際、これはめったに現れませんが、もし現れたら、それは本当にhemoです。



(5)GCCの開発も非常に困難です。 彼らの分岐システムにより、重要な作業がクラックとクラックの間に消滅する可能性が非常に高くなります(そして、これは常に起こります)。 GCC用のコードを開発している場合、最新のブランチでこれを行う必要がありますが、プラットフォームが現在ダウンしている場合は非常に困難です(Linux / i386を使用していない場合は常に発生します) (私から:おそらくgccの意味-i686-pc-bsd新しいバージョンは機能しません) 。 適応したとしても、GNUコーディング標準に従ってコードを書くことは困難です。GNUコーディング標準は、おそらくCで読むのが最も難しいでしょう。 明らかに、それらはLispプログラマーによって発明されました。 その結果、私(マーク)は、いくつかのコードを書き直してGCCリポジトリに送信することに興味を失いました。



(6)いくつかの最近の拡張機能は、OpenBSDで動作する機会がありません。たとえば、固定アドレスのmmap()に依存する逆アセンブルされたインクルージョン(私から:GCC開発者による奇妙な決定。mmapによって返されたアドレスを使用することははるかに困難でしたか? )?)



(7)GCCおよびG ++には、glibcアナログなしでは完全な機能を取得できない場所がいくつかあります(私から:もちろん、偏執的なOpenBSDには多くのバグがあるため、そのようなアナログはありません)



(8)いくつかの最適化方法は、私たちにとって間違いなく危険で間違っています(たとえば、暗号化キーを処理する場合でも、最適化中にメモリ充填をスローします) (私から:まあ、はい、あなたのmemset(0、256、およびrsakey )rsakeyへの呼び出しがなくなるため、コンパイラはコードから除外されます。悪いのは、別のプロセスが同じ物理メモリページを取得できるためです)



(9)そして、autoconf / libtool / automakeに関連する悪夢を忘れないでください(私から:ああ、赤ちゃん)。 地獄は、GCC自身にとっても、最新のオートメークとの互換性のためにインフラストラクチャを更新するのに数年かかりました。 同時に、GCCは、実際に内部libtool実装を使用するportsツリーの唯一のプログラムです。 libtoolシステムを使用しようとすると、その構成と再構成は完全に失敗します。



私(マーク)は、実際にさらに数ページ続けることができます。 私はOpenBSDでGCCのメンテナーを数年間務めてきましたが、GCCでの方法は非常に残念でしたので、別のコンパイラーに切り替えることができます。



(私から)ここに彼は、GCCです。 ソースレベルでGCCを使用した経験がありますが、これは本当に静かな恐怖です。 最近のバージョンでは、コードはより構造化されつつありますが、依然として多くの混乱があります。 また、特定のプログラムに常に適しているため、小さくなることはほとんどありません。 GCCを他のコンパイラと比較し、GCCが実際にどれほど複雑で、知的最適化ではなくテンプレート分析でどれだけ過負荷になっているかを確認できます。 少なくとも同じTCCまたはPCCを使用してください。 さらに良いことに、Plan9のリアクティブコンパイラを見てください。



そのため、Linuxにはまだ多くの開発と努力が必要です。



All Articles