64bit版のDelphi/C++Builderは2010年半ば頃?

う〜ん、よく判らん
とりあえず、翻訳ソフトに突っ込んでみた。


Introduction
この論文はすべてあなた Delphi ユーザーに我々が働いて、そして Delphi コンパイラに関して考えていることへの若干の洞察を与えるように意図されます。 我々はここ、 Embarcadero の世界的な本部であなたたちみんながあなたの Delphi コンパイラが好きである方法をすべてあまりにもよく知っています、そしてなぜならR&D研究室に若干のクールな言葉とコンパイラ技術醸造があります、そして我々はあなたがあなたの大好きなコンパイラの未来に関して最新であったことを確認することを望みましたから。
Some History
けれども最初に、私にコンパイラについてあなたに少しの歴史を与えさせてください。 これの大部分があなたたちみんなにおそらくニュースではありません、しかしそれを覚えていることは重要です。 最初に、 Delphi コンパイラはかなりの間(今まで)存在していました。 それは何度も何度もそれ自身が速い、近代的なツールであることを証明しました、そしてそれはあなたにノーブランド、インライン化している匿名の方法とさらに多くのようなたくさんのクールな、そして近代的な特徴を持っている人々を提供しました。 どんなに、その豊かな遺産のために、その中にまだ若干のコードが実際にあるとしても、古い Turbo Pascal から日々とそれらの日々は、十分に、ずっと前に銀河で遠くて、はるか遠くにありました。 まだ言語特徴があります、そしてあなたたちの多くがおそらく知りさえしなかったぶらぶらしているコード概念が存在しました。 例えば、あなたの何(個・人)が(* ... *)であなたがまだコメントを作ることができることを知っていますか? あるいはあなたたちの多くがこれがまだコンパイルすることを知っている方法:

var
  WeirdLookingArray: array(.1..10.) of string;

いいかげんにしてください、正直であってください。 あなたのあまりに多くではなくがそのことを知っていました。
いずれにしても、コンパイラは、後ろ向きの互換性のために、これらの概念と多くの他のものを保守します。 後ろ向きの互換性は、本当に、本当にあなたに重要です、そしてそれは、本当に、本当に我々に重要です。 私にそれを繰り返させてください:後ろ向きの互換性は、本当に、本当にあなたに重要です、そしてそれは、本当に、本当に我々に重要です。 (望むらくはイタリックはポイントを強調するのに役立ちます。 オーケー、今我々は前進することができます。) しかしながら、これらの特徴の多くがもうあなたの大部分によって使われません。 にもかかわらず、我々はまだ(彼・それ)らを維持して、(彼・それ)らをテストして、そしてコンパイラのそれぞれのリリースのために(彼・それ)らを証明します。 それは多くの仕事です。 けれどもあなたからすべてはおそらくあそこ(に・で・は)あるすべての物を使っていません。 (いいかげんにしてください、私にあなたがその「カッコとピリオド」についてことを知っていたと言おうとしさえしないでください...)、それはあなたたちの大部分が気にかけない仕事であることになります。 それほど中古でない言語特性を支持することは我々が新しい能力に取り組んで過ごすことができた時間の費用がかかります。
上記の例はただそれ、例です。 これらの多く以外コード意味論は実際に我々が変更をするのを阻止することができる特集記事であって、そして言葉を近代化しています。 私が先に進む前に、私に明確であるようにさせておいてください:私は特徴を排除することについて話しているつもりではありません;私はただ言語が現在持っている問題について話をしています。 我々はどんな言語特徴でも取り去るか、あるいはあなたのコードを解く計画を持っていません。 アゲイン:我々はそれをする計画を持っていません。 けれども、我々は若干の面白い新しい計画を持っています。
Therefore....
そのために、我々は(今まで)長い間、そして一生懸命これについて考えていました。 特に: 我々はどのようにそれに最新の、強力な、コンパイラがするすべてのことをし続けることができるようにするために我々のコンパイラを前へ動かすことができますか? 我々は、同時にあなたの既存のコードを維持している間に、どのようにクールな新しい物を加えてコンパイラを前へ動かしますか?
まあ、その質問への答えは短くも、そして容易でもありません。 我々が軽く受けとめるのは同じく何かではありません。 我々は我々が欲することをする、そしてそれからそこ(に・で)あなたたちみんなが持っているコードの多くを捨てる新しい Delphi 言語を作成するためにただコンパイラフロントエンド全体にリライトすることができました。 けれどもそれは良くないでしょう。 本当に良くありません。 我々は確かにそれをすることを望みません。 私にそれを繰り返させてください:我々は計画を持っていません、意図ともうあなたの既存のコードを作らない理由がうまくいきません。
我々が、けれども、することを望むことはそれに土着のコード開発(そしてそのことならやはり撮影、一般的な開発、)の時代の先端を続けさせるために Delphi を前へ動かし続けることが可能であるはずです。 けれども時々、前に進むことは過去からぶらぶらしているもののために難しいです。 Delphi は非常にタイプにとって安全な言語である、しかし完全にタイプにとって安全ではありません。 あなたはまだ電話 GetMem のようなことをするか、あるいは無限の配列(array[0..0] of integer) を作成して、そして、生の記憶がこのような言及を使うという状態で、あらゆる種類のばかげたことをすることができます。 それはすることが可能であるべき強力なものです、しかしそれは、あなたが何をしているかについて、同じくあなたがずっと記述的であり得ないことを意味します、それでコンパイラはあなたにあなたの陽気な方法を続けさせます。 多くの場合、これは正確にあなたが欲するものであるかもしれません、しかし、あなたが「あなた自身の足を撃つ」ことができるように、これはことを開始することについての主要な例です。 Delphi はあなたにシートベルトなしで乗らせます、しかし Delphi にものがあるというあなたがその手段をすることができるという事実それ自身はすることができません。 それは、もしあなたがまだあなたのクールな自動車を運転することができたなら、しかしすてきなスリーポイントの馬具とエアバッグの完全なセットですてきではないでしょうか。 それでコンパイラが、それから、何をするはずですか?
The Compiler Front End
コンパイラが一般に一般に「フロントエンド」と呼ばれるものを持っています。 フロントエンドはつきます、コード、がそれを解析して、そしてプログラムの意味の意図を表すツリー構造を作ります。 それは言語構文論を理解して、そして究極的に言語が何であるか定義する部分です。Delphi において、フロントエンドは ユニットの読み込み、ループ、begin...endのペア、変数定義、汎用クラス、これら全てが 「Delphiの要素」です。現在コンパイラに特定されているのは同じく DCU ファイルを作るフロントエンドです。 上のすべての歴史の構文論を扱うのは同じく部分です。 それで質問は似合います:まだあなたの貴重な規約がうまくいくことを保証する一方で、新しく可能にするべき Delphi 前部と現代語特性を修正する方法?
もし我々があなたに新しい、旧式でない構文論とコーディングのもっと古い方法の間の選択を与える新しいコンパイラフロントエンドを作ったならどうでしょう? (私に再び明確であるようにさせておいてください:我々は言語特徴を取り除くことについて話していません。 もしあなたが「それで、あなたはどんなコード概念をけなすつもりですか?」と尋ねるコメントを鼓舞しているなら、私は、‘ゼロ年を言うことによって、今それに答えます。 あなたがコード化するすべてはまだ機能するでしょう。」 我々は今までにそれについてかなりはっきりするべきです、そうではありませんか?) あるいはさらによいことには、(彼・それ)らが、あなたの古いコードを、それが常に持っているように、うまくいかせておいている間に、あなたに新しいモジュールに新しいコードを入れることを許して、一緒に働くことができるように、既存の暗号と「新しい」暗号を見る新しい方法はどうですか? 既存のコードはすべてまだことをする新しい方法に注入されることが可能でしょう、しかしもしあなたが「新しい、そして改善された」物を使うことを望んだなら、あなたは新しいタイプのコードモジュールでそれをしなければならないでしょうか? そしてもし我々がそれをしている間に、我々が終わるなら DCU (あるいは DCUs が今日そうであるものに類似の何か)をコンパイラバージョンに特定されていないフォーマットに列してはどうですか。 あのすべての音はどのようにそうしますか?
それは私にかなりクールに聞こえます、しかしもちろん、そのような何かをすることは些細ではありません、そして重大な量の手間を必要とするでしょう。 けれどもそのような何かがそれ、ノーの価値を持つでしょうか?
けれども初期段階は戦いのたった2分の1です。 同じくコンパイラのバックエンドがあります。
The Compiler Back End
あなた非コンパイラの通のために、コンパイラの「バックエンド」の終わりはフロントエンドが何を産み出すかについて読んで、そしてどこか(に・で)ランタイムの若干のタイプに有用な有用なバイナリか何かを作り出すために実際に機械コードを書き上げる部分です。 我々の DelphiC++ コンパイラのバックエンドは現在 Windows のために32ビットのバイナリを作り出します。 けれどももちろん、バックエンドが、今、32ビットと Windows をすることに限定されていなくてもよいですね?。
我々がバックエンドがすることを望む新しいことの1つが64ビットのバイナリを生産することです。 そしてそれで64ビットのバイナリを生産することは新しいバックエンドを必要とするでしょう。 我々はただ我々の既存の32ビットのバックエンドをとって、そして64ビットのバックエンドであって、そしてフェンスを越えて君たちにそれを投げるためにそれの周りに不法アクセスすることができました。 けれどもそれは、特に我々の C++Delphi コンパイラが現在異なったバックエンドを持っていると思って、それをする正しい方法ではないでしょう。 なぜ、あなたが、よく、1度それをすることができるとき、2度仕事をしますか? そしてもちろん、64ビットのプロジェクトがコンパイラよりもっと遠いです。 我々はデバッガ、エディタ、ファイルシステム、再ファクタリング、モデリング、文書化が − すべて − 正しくて、そしてあなたに限界なしで64ビットのアプリケーションを開発させることが可能であるまったく準備ができていてされることを確認することを望みます。 それはしばらくを要するでしょう。
その代わりに、それをする正しい方法は新しいバックエンドを書くことでしょう。 そしてもしあなたが新しいバックエンドを書こうとしているなら、するべき正しいことは DelphiC++Builder の両方 のために使われることができる一つのバックエンドを書くことでしょう。 そしてもしあなたがそれをしようとしているなら、それが実際にどんなアーキテクチャに目標を定めるかに関して、それがもう少しフレキシブルであり得るように、あなたはそれがこのような方法で設計されるバックエンドであることを望むでしょう。 面白い考え、ね?
それで DelphiC++Builder両方のためにうまくいくであろう新しい、統一されたバックエンド全体をすることは意味をなします。 けれどもそれをすることは時間を要します。 我々が、率直に、欲しいより多くの時間、しかしこれらのものは急いで運ばれることができません。 結果として、正しくそれをすること、それにそれがそうするべきである方法を操作させることと、利益 DelphiC++Builder 両方の に適切なコンパイラアーキテクチャを作成することは些細でない努力でしょう。 正しくそれをすることは我々に重要です、そして私はそれが同様にあなたに重要であると思います。
興味深いことに、この新しいバックエンドを作って、そして64ビットのプロダクトを構築するために必要な時は我々が新しい Delphi フロントエンドをする機会の窓を作成します。 それで、我々は、我々に同様に面白い前部内容をすることを許して、必要とされるすべての バックエンドの仕事をするのに時間をかける決断をしました。 我々は一緒に何かを切って、そしてフェンスを越えてそれを投げるつもりではありません。 我々は本当にクールであるであろう新しいコンパイラを作成することを望みます。 同じく、我々はあなたがそうすると想定します。
Delphi コンパイラは語形変化ポイントです。 そしてこの語形変化ポイントが我々(そして、究極的に、あなた)にその語形変化ポイントに本当に何かを意味させる機会を与えるように思われます。
Bottom Line
何が、それから、ここで肝心な点ですか? まあ − 若干の主要なコンパイラの仕事が新しい backend と64ビットのコンパイラの上にされるという状態で、ポイントをついて(最終的に!)正しくなるために、これは「動きをして」、そしてこの新しいコンパイラアーキテクチャに移行する良い時間のように思われます。 我々は Delphi の64ビットのバージョンが2010年半ばに用意ができていることを予想します。 コンパイラが完全な64ビットのプロダクトで最初のステップであるから、64ビットの Delphi の容器を見ることを極めて熱心に望んでいるあなたのそれらが早く始めるように、我々は2009年半ばに64ビットのコンパイラの予告を発表することを計画しています。
我々はこれが変化であることを知っています、しかし我々は信じます − そして我々はあなたが同意して − それを正しくとること、そして最先端の言語技術の上に Delphi を引き留めるであろう非常にクールな変更をすることが時間を要する価値を持っていることを希望します。 我々が新しいコンパイラを作るのに時間をかける途端に、我々がそこから加えることができる多くの冷たい、そして新しい物があるべきです。 そしてあなたたちはクールな、そして新しい物が好きですね?
Conclusion
Delphi は前に進まなければなりません。 C++Builderは前に進まなければなりません。 我々のコンパイラ前進しなければなりません。 前に進むために、コンパイラは近代的なデベロッパーが要求する機能の新しいセットを受け入れなければなりません。 両方の言語があなたが今、そして将来探している解決を提供しなければなりません。 生産するために、我々が、格言が言うように、少数の卵を壊さなければならないであろうこれらの新しい特徴はオムレツを作ります。
けれども君たちがそこ(に・で)あなたが働くために続けることを望むおよそ10の bazillion コード行を持っています。 我々はまったくそれを手に入れます。 それで、我々は「新しい Delphi を作成するために働いています」、そして、あなたの既存のコードをうまくいかせておくために、 DelphiC++Builderの 両方 を使って64ビットのバイナリを生成する新しいコンパイラアーキテクチャ、そして多分少数バイナリの他の種類我々がそれをしている間に。 そして、すべてそれがあなたのために働くように、すべてそれはきちんとされなければなりません。
そしてあなたは何を知っていますか? それは正確に我々がすることを計画することです。

要するに、64bit版の為にC++コンパイラDelphiコンパイラを統合したのを1から作るから、プレビュー版を今年の半ばに発表して、正式リリースは2010年の中頃まで待ってねってことでいいのかな?
まぁ、C++0x完全対応とかも考えると、フルスクラッチで書き直した方が楽という判断なのかな・・・。C++0xは現行のC++と「別言語」と言ってもおかしくないくらいの変更点があるし。
とりあえず正式な日本語訳待ちだけど、今年中に64bitコンパイラをいじれると思っていた人間としてはちと残念。

1/30 追記:
日本語版が出ました。