トップ «前の日記(2010-12-27) 最新 次の日記(2010-12-29)» 編集

ヨタの日々

2001|08|09|10|11|12|
2002|01|02|03|04|05|06|07|08|09|10|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|12|
2024|01|02|03|

2010-12-28 :-)

_ 0510 起床

0830 出勤

0900 身辺整理

_ 午後

1400 身辺整理

1700 退勤

_

1720 アニメイト川崎

1800 飯支度

1900 翻訳

2200 飯

2300 MONOMUSIK on USTREAM: 作曲家浜渦正志の番組を配信します/Masashi Hamauzu on USTREAM.

_ 買い物

アニメイト川崎

B00499CTNE

_ [翻訳][NetBSD][GCC][PCC][コンパイラ]hubertf's NetBSD blog - Article: Competition Among Open Source Compilers

オープンソースコンパイラの競争

Not exactly related to NetBSD, but definitely relevant: David Chisnall's article Competition Among Open Source Compilers talks about some alternatives to the GNU C Compiler (GCC), and why they are of interest to the operating system community (and thus NetBSD, too). Mentioned candidates include TenDRA, the Portable C Compiler (PCC), the Low Level Virtual Machine (LLVM), clang. The summary:

NetBSD 限定ではないのだが、いくらか関連する話題として David Chisnall の オープンソースコンパイラの競争 という記事がある。これは GNU C Compiler (GCC) の代替としてのいくつかの実装と、なぜオペレーティングシステムコミュニティ( もちろん NetBSD も含む )に採用されているのかを話題にしている。TenDRA { TenDRA Compiler - Wikipedia, the free encyclopedia } 、the Portable C Compiler (PCC)、the Low Level Virtual Machine (LLVM)、clang についても触れている。概要はこう:

`Not having to rely on GCC is likely to benefit the BSD family quite a lot. GCC is designed fairly closely with GNU libc in mind, so the project is hesitant to accept improvements that don?t work with glibc (and, by extension, with most Linux systems).

「多くの BSD 系 OS が GCC を利用していると思う。GCC は GNU libc 環境で使われることを前提として設計されているので、glibc が動かない環境での改良には二の足を踏んでいる。( 多くの Linux システムの拡張然り )。

Competition is usually a good thing; in open source projects, where ideas (and, ideally, code) can flow freely between the projects, everybody wins in the end. The more advanced architecture of LLVM makes it a good long-term bet for future systems, and the simple codebase of PCC makes it a good systems compiler. Both are likely to carve out a significant portion of market share in the next few years, giving developers more of choices for compiling their code.''

オープンソースプロジェクトにおいて、競争は普通 良い方向に働く。アイデアとコードはプロジェクト間を自由に行き来できるので、結局はみんなが幸せになれる。LLVM のより進んだアーキテクチャは長い目で見れば将来のシステムに有益であり、シンプルなコードをもとにした PCC は良いシステムコンパイラとなる。これらは今後数年の市場で重要な位置を占め、開発者たちがコードをコンパイルする選択肢はもっと増えるだろう。」

Those interested in trying PCC with pkgsrc can set "PKGSRC_COMPILER=pcc", see Jeremy Reed's blog entry and the the CVS commit log for more information. Also, see (hear :) bsdtalk interview with Anders "Ragge" Magnusson

pkgsrc では "PKGSRC_COMPILER=pcc" とすると PCC を使えるようになる。詳細は Jeremy Reed のブログ記事CVS コミットログ を参照。もちろん bsdtalk interview with Anders "Ragge" Magnusson もよろしく :)

_ [GCC][PCC][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > The BSD Issue (1)

オープンソースコンパイラの競争 (1)

Since its creation, the C language has been tightly tied to UNIX. C was designed as a portable assembly language for reimplementing UNIX, to make it easier to port to different platforms.

プログラミング言語 C は UNIX のために作られた。C は、 UNIX を再実装するための可搬性のあるアセンブリ言語であり、これにより異なるプラットフォームへの移植を容易にした。

In 1984, Richard Stallman began the GNU (GNU's Not UNIX) Project to provide a clone of the UNIX operating system using entirely Free Software. Because a C compiler is a core component of any UNIX-like operating system, he wrote one: the GNU C Compiler (GCC).

1984 年 Richard Stallman はフリーソフトウェアのみを使った UNIX オペレーティングシステムのクローンを作るために GNU (GNU's Not UNIX) プロジェクトを開始した。C コンパイラはあらゆる UNIX ライクオペレーティングシステムのコア部分であり、それを GNU C コンパイラ( GCC )と呼んだ。

Over the years, GCC was rewritten a few times, and support for various languages was added. When it began to support more languages than just C, the name was changed to the GNU Compiler Collection, keeping the same GCC abbreviation. As with other parts of the GNU Project, GCC uses the GNU General Public License, although it has a special exception for any parts of the compiler that are embedded in the compiled output.

数年間で GCC は何度か書き直され、いくつかの言語サポートを追加した。もはやサポートする言語は C だけではないので、GNU コンパイラコレクションと名前を変更した。GCC という略称はそのままである。他の GNU プロジェクトと同様に GCC は GNU General Public License を使用する。ただし、GCC で生成された成果物には GPL は適用されない。

The BSD Issue ( BSD の場合 )

Although the GNU Project has GCC, and most proprietary UNIX systems have their own compilers, the BSD projects typically have none. In the base system of any BSD system, GCC is the largest piece of GPL'd code. Over the years, it periodically looked as though TenDRA might replace it. TenDRA, a BSD-licensed C compiler originally started by the Defence Evaluation and Research Agency (the institution that used to be the UK's equivalent of DARPA) focuses on correctness, and would be a good match for systems like OpenBSD, but progress has been slow.

GNU プロジェクトには GCC がある。多くのプロプライエタリな UNIX システムには独自のコンパイラがある。しかし BSD プロジェクトには無い。BSD のベースシステムにおいて、GCC は最大の GPL コード量を占める。TenDRA が数年かけてこれを置き換えた。TenDRA は防衛評価研究局 (DARPA が利用する機関) により始められた 正しく実装することを目標とした BSD ライセンスの C コンパイラである。これは OpenBSD にうまくマッチした。しかし進捗は遅かった。

Recently, another option appeared from an unexpected direction. Back in the 1970s, Stephen Johnson of Bell Labs wrote the Portable C Compiler (PCC). Unlike many earlier compilers, it had a clean separation between the parser and code-generation stages, allowing it to be ported to new architectures easily - a feature present in most newer compilers. This compiler was included with a lot of UNIX variants, including 4.3BSD-Reno.

最近 別の発展を遂げたコンパイラがある。1970 年 ベル研の Stephen Johnson が Portable C Compiler (PCC) を書いた。他の既存のコンパイラと違い、解析部とコード生成部が綺麗に分割されており(最新のコンパイラでも採用されている)、新しいアーキテクチャへの移植が容易だった。PCC は 4.3BSD-Reno を含む多くの UNIX に導入された。

PCC never underwent the same degree of growth as GCC, and remains a very small project. The source code is under 1 megabyte (compressed), and compiling it on a 1 GHz machine takes only a few seconds, whereas compiling GCC on the same machine takes most of an afternoon. PCC isn't as strong in terms of optimization as GCC, but its small size makes it much easier to verify that the output is correct.

PCC は GCC と別の発展を遂げ、いまだにプロジェクトは非常に小さいままである。ソースコードは 1メガバイト以下 (圧縮して) だし、1 GHzのマシンであっても数秒でコンパイルが終わる。それに比べて GCC で同じコードを同じマシンでコンパイルすると、午後が潰れる。PCC は GCC ほど最適化に力を注がない。その代わりにサイズが小さいので、成果物が正しいのか検証が容易だ。

In September 2007, PCC was imported into the OpenBSD source tree, with the aim of evaluating it as a GCC replacement for future releases. A simple compiler is very attractive to the BSD communities - particularly one that's portable. GCC has a habit of changing the interface to the back end, orphaning architectures. This behavior has resulted in some ports of NetBSD, for example, having to stick with old versions of GCC, since no one with the expertise to maintain the compiler port is willing to do so.

2007 年 9 月 PCC は OpenBSD のソースツリーに取り込まれた。将来のリリースで GCC を置き換えるために評価中である。シンプルなコンパイラは BSD コミュニティにとって非常に魅力的である(可搬性があればなおよい)。GCC はマイナーなアーキテクチャにたいしてはインターフェースをよく変更してくれる。NetBSD のいくつかの port ではこの影響を受けた。たとえば、port 用のコンパイラをメンテナンスできるひとが居ないときに古い GCC を持ってなければならなくなる。

It's difficult to overstate the relative complexity of GCC versus PCC. The codebase for GCC is almost 100 times the size of the PCC codebase. The OpenBSD team hopes that this difference in scale will make getting involved with PCC development a lot less daunting than getting involved with GCC.

GCC と PCC についてさらに深く掘り下げることは難しい。GCC のコード量は PCC 100 倍もあるのだ。OpenBSD チームは、このコード量の差異から、GCC を深追いするよりも PCC を開発するほうが楽になってくれることを期待している。

PCC began life on the VAX, and didn't support x86 until very recently. The port took one person less than a week, which makes supporting other architectures seem quite plausible; the total amount of x86-specific code comes to less than 4,000 lines.

PCC は VAX とともに生を受け、最近になるまで x86 をサポートしていなかった。移植はたった 1 人の人間が 1 週間もかからずに完了させた。他のアーキテクチャもすぐにサポートできるようになるだろう。x86 用のコードは 4000 行にも満たなかったのだから。

_ [BSDライセンス][GPL][ライセンス][GCC][LLVM][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > An Advanced Architecture (2)

オープンソースコンパイラの競争 (2)

An Advanced Architecture ( 先端のアーキテクチャ )

The GCC design has gradually evolved since the project's creation, and adopted some more modern design principles. Static single assignment (SSA) was one of the more recent large changes, back in 2005. The principle of SSA is that each variable should hold only one value ever. This rule is enforced in the language in something like Erlang, or in the intermediate form in a C compiler. Consider some C code of the following form:

GCC は作成されてからモダンな設計を取り入れながら徐々に発展してきた。2005 年の Static single assignment (SSA) { 静的単一代入 - Wikipedia } は最近ではかなり大きな変更である。SSA の基本思想は、各変数がたった 1 つの値を持つ、というものである。これは Erlang が似たような規則を採用しており、C コンパイラでは中間状態として使われる。以下のような C コードがあるとする:

a = b;
a += c;

This code doesn't conform to the SSA principle, so the compiler would replace it with something like this:

このコードは SSA の規則に当てはまらないので、コンパイラは以下のように置換する:

a1 = b;
a2 = c;

All future uses of a would be replaced with references to a2, until the next assignment to a. This form allows a number of optimizations to be accomplished quite easily. Describing it as "new" is somewhat misleading, however; the original paper proposing it was published in 1985. Most modern compilers, including the newer versions of PCC, use some kind of SSA form.

これ以降 a に値が代入されるまで、置換された a2 への参照を使うことになる。これにより、最適化がかなり容易になる。このアイデアは新しいように見えるが、じつは最初の論文は 1985 年に書かれている。新しいバージョンの PCC を含み、モダンなコンパイラはほとんど SSA を利用している。

While GCC has accreted design components, another compiler was written from scratch based on the latest ideas in compiler research. The Low Level Virtual Machine (LLVM) is designed to focus heavily on optimization. Like Java and .NET, it uses a virtual machine to define an intermediate form; however (as the name suggests), this machine is quite low-level, and not tied to any particular language.

GCC が巨大化していく一方で、他のコンパイラは最新のコンパイラ研究にもとづいて 1 から書かれた。Low Level Virtual Machine (LLVM) は最適化を重要視して設計された。Java や .NET のように仮想マシンを内部に持つ。しかし (名前から分かるように) LLVM は低レベルすぎて他の言語には使いづらい。

Originally, LLVM used code taken from GCC to handle parsing. This approach changed slightly with release 2.1 in September 2007. A new, Apple-developed front end was introduced, with support for C, C++, and Objective-C, under the name clang.

もともと LLVM は、解析するために GCC からコードを受け取っていた。このアプローチは 2007 年 9 月の release 2.1 で多少変更された。C、C++、そしてObjective-C をサポートするアップルの開発用フロントエンド clang に取り込まれた。

Part of the motivation for developing clang came from a criticism often leveled at GCC: that it's difficult to separate out the front-end and back-end code. When you edit code in something like Microsoft's Visual Studio, you can use the same code for parsing the code to generate syntax-highlighting information as you use for code generation. The same is true of most LISP and Smalltalk environments. This isn't the case with something like Apple's Xcode, however, which has to implement its own parser for syntax highlighting and code completion. This setup is less than ideal for developers, because parsing errors in the IDE don't necessarily correspond to code that won't compile, and vice versa.

clang を開発するモチベーションの一部は GCC への「フロントエンドとバックエンドを分離しづらい」という批判から来ている。Microsoft の Visual Studio でコードを書くとき、コードが解析され、シンタックスハイライトにより、まるであなたがコードを書いたように見えるだろう。これは LISP や Smalltalk 環境とまったく同じである。アップルの Xcode は多少違う点があるが、Xcode 独自の解析部によりシンタックスハイライトが機能し、コードを補完する。これにより、IDE で解析エラーになるので、いちいちコンパイルする手間が省け、開発者の負担が減る。コンパイラの負担も減るのである。

Extracting the front end from GCC for this purpose is difficult for two reasons. First, GCC is released under the GNU General Public License, which means that any other program built using it is required to be under the same license. Second, GCC intentionally ties the front and back ends into the rest of the code quite closely, to avoid "semi-proprietary" forks. In contrast, LLVM is BSD-licensed and has comparatively clean separation between the various layers.

GCC からフロントエンドを分離することは、2 つの理由により難しい。1 つは、GCC の最初のリリースが GNU General Public License に基づいており、GCC でビルドだれたプログラムを使うためには同じライセンスを適用しなければならないということ。{ ????? } 2 つめは、フロントエンドとバックエンドが密結合しており、準プロプライエタリとして派生させて使えないということ。対照的に、LLVM は BSD ライセンスで、いくつかの層{ フロントエンドとバックエンドのことか ? }は比較的綺麗に分離されている。

_ [VM][仮想マシン][LLVM][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > A Low-Level Virtual Machine? (3)

オープンソースコンパイラの競争 (3)

A Low-Level Virtual Machine? ( LLVM って? )

The concept of something that is both "low-level" and a "virtual machine" (VM) is slightly strange. Most virtual machines are either very abstract or consist of only very thin abstraction layers. Perhaps the lowest-level virtual machine is Xen, which has the same non-privileged instructions as x86, but different privileged ones.

「低レベル」と「仮想マシン(VM)」のコンセプトは多少違う。ほとんどの仮想マシンは、高度に抽象化されているか、または高度に抽象化された層を持っている。おそらく最も低レベルな仮想マシンは Xen で、Xen は 1 つの特権命令と x86 と同じ非特権命令を持っている。

At the opposite extreme is something like the Java virtual machine. Java bytecode runs on a virtual-stack-based machine (all of the real stack-based machines except x87 having died out a long time ago). This is very different from any real machine, although it has some passing similarities to old LISP machines. The Java VM makes a number of assumptions about the code running on it, making it difficult to run anything that's not a strongly typed language with a Java-esque system.

Java 仮想マシンとまったく違う点である。Java バイトコードは virtual-stack-based で走る ( x87 以外の real stack-based machines はだいぶ前に滅びた )。これは実際のマシンとは大きく異なる。むしろ昔の LISP マシンをシミュレートしていることに近い。Java VM は、Java-esque システムであればどのような言語でも走らせることを可能にするための基盤である。

The abstract machine presented by LLVM is somewhere between the two. It's close to an unlimited register machine (URM), which is a fairly common theoretical model for computing. A few things mark it as being different from a real computer:

LLVM による抽象マシンは 2 つ異なる点がある。レジスタマシン ( unlimited register machine (URM) ) に閉じたものであり、これは理論計算機のモデルである。{ ?????????? } 実際のコンピュータと異なる点をいくつか挙げる:

  • Each register is typed. In most computers, registers are typed to the extent that they are integer or floating-point quantities, but the LLVM type system goes far beyond this level.
  • Each register is single-assignment. As discussed earlier, this form makes it much easier to perform a number of classes of optimization.
  • 型付けされたレジスタ: ほとんどのコンピュータは、レジスタは整数か浮動小数点の幅を持った型になっている。LLVM ではこのレベルを超えている { ?????? }
  • レジスタは 1 つの値を持つ: 先にも書いたが、これにより最適化が容易になる

Compiling with LLVM is a two-stage process:

LLVM の 2 ステージプロセスでのコンパイル

1. The first step is to compile a program from source code to bytecode for the abstract machine. For some languages, this process may be two steps, going via a language-specific bytecode. After this, there are a few options.

1. 最初のステップでは、抽象マシン向けにソースコードをバイトコードへコンパイルする。いくつかの言語では language-specific バイトコードを生成するために 2 ステップかかるだろう。この処理のあといくつかオプション処理があったりする。

2. The LLVM bytecode can be interpreted directly. This is nice for debugging, since the entire state of the machine can be inspected, and none of the type information has yet been lost.

2. LLVM バイトコードはダイレクト割り込み可能である。これはデバッグ時に嬉しい。マシン全体の状態を調査でき、型情報をまったく損なわない。

The bytecode also can be compiled to native code, either as a single-step operation or as part of a profiling-directed optimization pass. This arrangement allows the optimizer to examine the runtime behavior of the code and compile it on the fly. Alternatively, of course, it can be distributed in bytecode form, which is hardware-agnostic, and then compiled at install time, or JIT-compiled as it runs with the additional profiling information.

バイトコードはネイティブコードとしてもコンパイルできる。1 ステップでプロファイルと最適化がおこなわれる。これにより最適部がコードを実行しながら評価したり、じかにコンパイルできる。{ ???????? } もちろん ハードウェア依存のバイトコードとしても配布できるし、インストール時にコンパイルしたり、{ ?????? } JIT コンパイルすればプロファイル情報を付加することもできる。

_ [GCC][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > The End of GCC?

オープンソースコンパイラの競争 (4)

The End of GCC? ( GCC の終焉? )

Before predicting the end of GCC, it's important to understand the role it fills. One big reason for using GCC is that it's portable. You can use the same compiler on a wide collection of operating systems and architectures. GCC isn't bad at optimization, either, although less-portable compilers tend to do better on the specific platforms they target. Having to support only a single compiler can reduce development costs, however.

GCC の終焉を語る前に、1 つ役割を理解しておくことが重要だ。GCC を使う大きな理由として、可搬性がある。GCC は、幅広いオペレーティングシステムとアーキテクチャ上で利用できる。GCC の最適化は、可搬性に欠けたプラットフォーム上のコンパイラと比較しても悪くない。それに 1 つのコンパイラだけを使うことにより開発のコストを下げることができる。

The main reason that GCC exists is to be Free Software. The GNU Project requires a compiler that's capable of building the GNU system. Both of the compilers I've discussed in this article are Free Software, but they're available under the permissive terms of BSD-style licenses. This fact makes them less attractive to the Free Software Foundation, because these licenses permit making proprietary forks.

GCC のおもな存在意義は、フリーソフトウェアであるということだ。GNU プロジェクトは GNU システムをビルドするために有能なコンパイラを求めている。私がここで言っているコンパイラはどれもフリーソフトウェアだが、寛容な BSD ライセンスである。これらのライセンスはプロプライエタリなものを生成できるので、はフリーソフトウェア財団からはあまり宜しく思われていない。

While the Free Software Foundation is nominally in charge of GCC, a lot of development is funded by the likes of Apple and Red Hat. Making a closed-source fork of the compiler is not in the best interest of either of these companies, since they don't sell compilers - they give them away, to encourage people to write software for their platforms. (Red Hat also gives the rest of the platform away, to encourage people to pay for Red Hat support.) Apple, on the other hand, would very much like to be able to use components of the compiler combined with other, proprietary components. This desire is what attracted Apple to LLVM as a compiler for OpenGL shaders (code which is now making its way into the open source OpenGL clone Mesa), and led do development of the clang front end for LLVM.

フリーソフトウェア財団は建前上は GCC を担当しているが、実際にはアップルやレッドハットよって大部分が開発されている。これらの会社はコンパイラを売っていないので、クローズドソースなコンパイラを作ることはこれらの会社からはよく思われない。彼らのプラットフォームでコードを書くように仕向けているのだ{ ?????? }。( レッドハットはプラットフォーム以外でコートを書く場合は Red Hat にサポート料金を支払わせるようにしている )。他方、アップルは、GCC のコンポーネントとプロプライエタリなコンパイラコンポーネントをうまく組み合わせられるようにしている。これによりアップルは、 OpenGL シェイダーコンパイラのために LLVM を作った ( このコードはオープンソースとして、OpenGL クローンの Mesa になった )。LLVM のフロントエンド clang の開発を引率するようになった。

Another strength of GCC is the languages it supports. With GCC, you can compile C, C++, Objective-C, Fortran, Java, and Ada. It also has some support for Pascal, Mercury, COBOL, Modula-2, Modula-3 VHDL, PL/1, and UPC. In contrast, PCC supports only C, with experimental support for Fortran. LLVM supports C and C++, with experimental support for Objective-C and Stacker (a stack-based language).

他にも GCC の強みとして言語サポートがある。GCC を使えば C, C++, Objective-C, Fortran, Java, そしえt Ada をコンパイルできる。また、Pascal, Mercury, COBOL, Modula-2, Modula-3 VHDL, PL/1, そして UPC もいくらかサポートしている。対称的に PCC のサポートは C のみだ。Fortran サポートはまだ実験的である。LLVM は C、C++、そして実験的であるが Objective-C と Stacker ( スタックベースの言語 ) をサポートしている。

From my perspective, one of the most interesting things about GCC at the moment is that it's the only Objective-C compiler that works with either Apple's Cocoa or GNUstep. This situation is likely to change soon, as the clang front end becomes more mature, which is likely to benefit all Objective-C developers as a result of competition between the projects.

個人的には、GCC のもっとも面白いのは、アップルの Cocoa か GNUstep では Objective-C をサポートしているのが GCC のみであるとうことだ。clang フロントエンドが熟せばこの状況は変わるだろう。Objective-C 開発者たちにとってプロジェクト間の競争となり、よい結果をもたらすだろう。

Not having to rely on GCC is likely to benefit the BSD family quite a lot. GCC is designed fairly closely with GNU libc in mind, so the project is hesitant to accept improvements that don't work with glibc (and, by extension, with most Linux systems).

多くの BSD 系 OS が GCC を利用していると思う。GCC は GNU libc 環境で使われることを前提として設計されているので、glibc が動かない環境での改良には二の足を踏んでいる。( 多くの Linux システムの拡張然り )。

Competition is usually a good thing; in open source projects, where ideas (and, ideally, code) can flow freely between the projects, everybody wins in the end. The more advanced architecture of LLVM makes it a good long-term bet for future systems, and the simple codebase of PCC makes it a good systems compiler. Both are likely to carve out a significant portion of market share in the next few years, giving developers more of choices for compiling their code.

オープンソースプロジェクトにおいて、競争は普通 良い方向に働く。アイデアとコードはプロジェクト間を自由に行き来できるので、結局はみんなが幸せになれる。LLVM のより進んだアーキテクチャは長い目で見れば将来のシステムに有益であり、シンプルなコードをもとにした PCC は良いシステムコンパイラとなる。これらは今後数年の市場で重要な位置を占め、開発者たちがコードをコンパイルする選択肢はもっと増えるだろう。」