コンパイラの費用はいくらですか？

コンパイルツールチェーンは、あらゆるシステムの最大かつ最も複雑なコンポーネントの1つであり、原則として、GCCまたはLLVMのいずれかのオープンソースコードに基づいています。 Linuxシステムでは、オペレーティングシステムとブラウザーのカーネルのみがより多くのコード行を持ちます。 商用システムの場合、コンパイラはソースコードがどうであれ、信頼性が高く高性能なバイナリコードを生成する必要があり、絶対に信頼性がなければなりません。



システムのこのような大きく、複雑で重要なコンポーネントはいくらですか？ オープンソースのおかげで、思ったほどではありません。 この投稿では、新しい商用コンパイルツールチェーンの構築が莫大なコストなしで可能であることを示す実際の例を示します。

どのくらいのコードが必要ですか？

（ SLOCCount 、著者David A Wheeler）による分析では、GCCには500万行以上が含まれていることが示されています。 LLVMはより小さく、わずか160万行ですが、より若く、デフォルトでCとC ++のみをサポートし、ターゲットアーキテクチャが3倍少なくなっています。 ただし、便利なツールチェーンにはさらに多くのコンポーネントがあります。

• デバッガー：GDB（800K行）またはLLDB（600K行）
• リンカー：GNU ld（160K行）、gold（140K行）、またはlld（60K行）
• アセンブラー/逆アセンブラー：GNUガス（850K行）、またはLLVMアセンブラー
• バイナリユーティリティ：GNU（90K行）および/またはLLVM（LLVMソースに含まれています）
• エミュレーションライブラリ：libgcc（GCCソースに含まれています）またはCompilerRT（340K行）
• C標準ライブラリ：newlib（850K行）、glibc（1.2M行）、musl（82K行）、またはuClibC-ng（251K行）

さらに、ツールチェーンをテストする必要があります。 ほとんどのGNUツールでは、回帰テストがソースに組み込まれています。 LLVMでは、回帰テストには50万行の個別のコードベースがあります。 さらに、組み込みシステムでは、テスト中にデバッガと対話するためにデバッグサーバーが必要です。

コンパイラを移植するには何が必要ですか？

商用利用のためにツールチェーンを移植する必要があります。 世界中の多くの大学院生が研究の過程でコンパイラを移植していますが、彼らの努力はこの研究の狭い領域に集中しています。 その結果、コンパイラは迅速に移植されますが、これは研究プログラムの目的ではないため、完全でも信頼性もありません。



この記事は、あらゆるソースコードに対して正確かつ効率的なバイナリを確実に生成するツールキットの作成に関するものであり、商用および産業用を対象としています。



幸いなことに、巨大なコードベースのほとんどは汎用です。 すべてのメインコンパイラの開発では、ターゲットプラットフォームに応じてコードを適切に分離するためにかなりの努力が払われており、コンパイラツールチェーンを新しいアーキテクチャに移植することは実行可能なタスクです。 このタスクには5つのステージが含まれます。



1.プロトタイピング

最初に、すべてのコンポーネントを含むポートが作成されます。 プロトタイプを作成することは、フルポーティングで最も問題のある場所を特定するために重要であり、数か月かかります。 この段階の最後に、すべてのコンポーネントが期待どおりに連携することを実証するプログラムをコンパイルできなければなりません。



2.完全な機能の実装

すべてのコンパイラー機能およびその他のツールの完了。 属性、組み込み/組み込み関数、および欠落している機能のエミュレーションを完了する必要があります。 リンカは動作し、BSPによって記述され、必要に応じてカスタムオプションを追加する必要があります。 このプロセスの最後に、ユーザーは完全に機能するツールチェーンを受け取ります。 最も重要なのは、回帰テストの完全なセットに合格する必要があることです。



3.テスト。

プロジェクトの最大の部分。 テストは3つの領域をカバーする必要があります。



-回帰テスト。ツールチェーンが壊れておらず、さまざまなアーキテクチャで機能することを示しています。

-アプリケーションテスト（コンプライアンステスト）。多くの場合、顧客テストを使用し、必要な機能がすべて存在することを示します。

-生成されたツールチェーンコードが、必要なコード実行速度、コードサイズ、エネルギー効率の基準を満たしていることを示すベンチマーク。



4.展開

この段階では、ユーザーが新しいコンパイラーとそれが以前のツールとどのように違うかを学ぶのを支援する必要があり、通常これには書面とビデオのチュートリアルが必要です。 新しいバグが検出され、古いコンパイラと新しいコンパイラの違いに起因する多くのバグレポートもあります。 これは、LLVMとGCCが古いプロプライエタリコンパイラを置き換えるときに発生します。これは、それらが機能性に関してはるかに開発されているという事実のためです。 ユーザーベースが大きい場合、展開フェーズは非常に重要になります。



5.エスコート

LLVMとGCCは非常に活発に開発されており、フロントエンドで新しい言語標準をサポートし、バックエンドに新しい最適化を追加するために、新しい機能が常に追加されています。 これらすべての変更を反映して、コンパイラを最新の状態に保つ必要があります。 さらに、もちろん、ターゲットアーキテクチャに固有の新しい機能と、ユーザーからのバグレポートがあります。

一般的な場合に必要な労力

一般的なケースを考えてみましょう。 大規模なユーザーベースを持つ新しいアーキテクチャは、ベアメタルとLinuxの両方でCおよびC ++をサポートする必要があります。 この場合、アーキテクチャはおそらく、ベアメタルアプリケーションや組み込みシステムのRTOSに使用される小さなプロセッサから、本格的なLinux環境を実行できる大きなプロセッサまで、さまざまな実装をサポートします。



このようなツールチェーンの完全なリリースには1〜3人年かかります。 ツールチェーンの初期バージョン（概念実証）は3か月以内に実装する必要があります。 すべての機能の実装には6〜9か月かかり、ベアメタルとLinuxのサポートが必要な場合はさらに3か月かかります。



テストには少なくとも6か月かかりますが、特定のテストが多数ある場合、最大12か月かかることがあります。 初期展開には3か月かかりますが、大規模なユーザーベースでは9か月長くかかることがあります。



サポートの取り組みは、ユーザーレポートの数と新機能の数に大きく依存しています。 これらの取り組みには、月に0.5人月から、より可能性の高い月に1人月がかかります。



コンパイラの専門家、デバッグの専門家、ライブラリ実装エンジニアなど、エンジニアのチーム全体がプロジェクトに取り組む必要があることに注意することが重要です。 コンパイラー開発は最も複雑な分野の1つであり、すべての分野を一度に経験できるエンジニアはいません。

最も単純な場合にどれだけの労力が必要か

多数のユーザーが使用するコンパイラーが常に必要なわけではありません。 単一のエンジニアで構成される小規模企業で開発された、さまざまな特定のプロセッサ、特にDSPがあります。 そのようなプロセッサーが商業的に成功したことが証明されると、進化し始め、単一のエンジニアによってアセンブラーでプログラムされた小さなカーネルの代わりに、彼らは大規模なアセンブラープログラマーのチームでより強力なプロセッサーになります。 この場合、C言語コンパイルに切り替えると、生産性が大幅に向上し、開発コストが削減されます。



このような場合、ツールチェーンはC ++なしのC、および最低限必要なライブラリCをサポートする必要があります。また、アーキテクチャには、使用可能な既製のアセンブラとリンカを含めることができます。 これにより、完全に機能するコンパイラを作成するための労力が最大1人年まで大幅に削減されます。



概念実証段階にはまだ3か月かかりますが、その後さらに3か月で完全に機能するバージョンになります。 テストは依然として最も手間がかかり、3〜6か月続きますが、ユーザーベースが小さい場合は3か月で十分です。



サポートも必要ですが、小さなユーザーベースの小さなシステムでは、1か月あたり0.25人月で十分です。



小規模なお客様の場合、すべての機能を実装した後に停止することが重要な場合があります。 少数の標準プログラムがコンパイルされる場合、これはテストの完全なセットを通過することなく、コンパイラの有効性を実証するのに十分かもしれません。

トピック研究

2016年、マイクロエレクトロニクス企業はEmbecosmに連絡しました。Embecosmは長年、狭いフィールド用に特別に設計された16ビットアドレス空間を持つ独自のDSPを使用していました。 彼らは、アセンブリ言語プログラミングにあまりにも多くの労力を費やしていることに気付いたときに、第3世代のプロセッサを使用しました。 使用した標準コーデックにCのリファレンス実装があったため、状況は悪化しました。コンパイラーはありましたが、非常に古く、新世代のDSPにコードを移植することは不可能でした。



EmbecosmはLLVMベースのツールチェーンによって注文されており、LLVMコーデックをコンパイルして高品質のコードを生成できます。 必要に応じて、コードを手動で変更すると想定されていました。 顧客には既製のアセンブラーとリンカーがあり、すべてのアセンブラーファイルを1つに結合し、すべてのリンクをリンクし、DSPに読み込まれたバイナリファイルを生成しました。 また、顧客はコンパイラの構築の経験を得たいと考えていたため、顧客のエンジニアの1人がEmbecosmチームに加わり、プロジェクトの完了時にコンパイラのサポートに関与していました。



最初の3か月で、既存のアセンブラーと逆アセンブラーに基づいたツールチェーンを開発しました。 newlibを使用するために、必要なファイルをアセンブラーソースの形式でnewlibから抽出し、テストプログラムと結合する擬似リンカーを作成しました。 なぜなら シリコンプロセッサが利用できなかったため、チップのVerilatorモデルでテストしました。 これを行うために、GDBがモデルと対話できるようにするgdbサーバーを作成しました。 ELFがない場合、ソースレベルでのデバッグは不可能ですが、GDBはプログラムをロードして結果を取得できます。これはテストに十分です。



これにより、テストプログラムをコンパイルし、コンパイルツールチェーンが機能していることを実証できました。 完全な機能を実現するには2つの障害があることが明らかになりました。1）バイナリELFファイルのサポートの欠如、2）16ビット文字のサポートの欠如。



第2フェーズでは、CGENを使用してGNUアセンブラー/逆アセンブラーを実装しました。約10日かかりました。 この投稿で説明されているように、LLVMで16ビット文字のサポートも実装しました。 これら2つのことにより、フル機能のツールチェーンの完成が容易になり、ツールチェーンの標準LLVM点灯テストとGCC回帰テストを実行できました。そのほとんどは成功しました。 DSPには、いくつかの特別な固定小数点演算サポートモードがあります。 それらをサポートするために、特別な組み込み関数と組み込み関数を実装しました。



この段階では、お客様のコードを正しくコンパイルするコンパイラーがあります。 ELFサポートにより、リンク時最適化（LTO）やセクションのガベージコレクションなどの手法が可能になり、コードの最適化に成功し、これは限られたメモリ量で顧客の要件を満たします。 120人日というコストで、新しいDSP用にCコードをコンパイルするという目標が達成されました。



顧客は、この段階で機能が自分に合っていると判断し、作業の継続は必要ありません。 コンパイラが幅広い消費者に利用可能であると判断した場合、彼らはツールチェーンの完全なテストを続けて作業することができます。

結論

2つの要因により、120人日で完全に機能するコンパイルツールチェーンを構築できました。



オープンソースのコンパイラを使用する

このプロジェクトで使用されているツールは、過去30年間にコンパイラコミュニティが数千人年を費やした結果です。 お客様はこの利点を活用して、最新のツールチェーンを取得することができました。



専門家チーム

120日間のプロジェクトでしたが、5人のチームがそれに取り組み、それぞれが長年の経験を持っています。 エミュレーション、GDB、CGENアセンブラー、GNUリンカー、LLVMコンパイラーについてすべてを知ることはできません。