トランスコンパイラ(他にトランスパイラ、ソース・トゥ・ソースコンパイラ、などとも)は、あるプログラミング言語で書かれたプログラムのソースコードを入力として受け取り、別のプログラミング言語の同等のコードを目的コードとして生成する、ある種のコンパイラである。一般に、コンパイラが「比較すると高水準な言語のソースコード」を入力とし、「比較すると低水準な言語の目的コード」を、コンパイル結果として出力するものであったのに対し、トランスコンパイラは同じ程度の(抽象化の)水準のコードをコンパイル結果として出力する。
それらの処理系における具体的なコンパイルの処理、すなわち、入力から出力への変換において実際に行われることは、それぞれの処理系によってさまざまである。字句のレキシカルな変換やsyntactic sugar(糖衣構文)の展開といったような程度の場合もあれば、高度なコンパイラ最適化を施して機械語をコード生成するような、通常のコンパイラと全く同様の処理をおこなっているものもある。
たとえば、PascalのコードをCのコードへと変換するといったものや、「自動並列化コンパイラ」のように、見た目としては逐次的なfor文などで書かれいているコードを、OpenMPのような並列化メタデータやFortranのforall文のような言語構造に変換する[1]、といったものがある。
forall
トランスコンパイルの別の目的は、基本的なプログラミング言語の次期バージョンを使う場合や、APIの後方互換性が壊れた場合などに、レガシーなコードから変換することである。プログラムの実行環境が変わる場合(例えば、Python 2からPython 3に変換する場合や古いAPIから新しいAPIに変換する場合)や、コンパイルによりプログラムのサイズが極端に大きくなったり実行速度が遅くなったりした場合はリファクタリングを行う。
トランスコンパイラは、元のソースコードの開発やデバッグを簡単に行うことができるよう、元のコードをコメントなどに残す(ことができる)ものもある。また、元のコードから変換した際に構文が大幅に変わった場合は、同等のコードには見えないようなコードに変換されることもある[2]。元のコードから変換されたソースコードにマッピングを行うデバッグツールもある。
トランスコンパイラを主たる実装として開発されている言語の例としてはClosure Compiler, Coccinelle, CoffeeScript, Dart, Haxe, TypeScript[3], Emscripten[4]がある。
ここでは1980年前後以降の例を示す。
1981年にゲイリー・キルドールによって書かれたデジタルリサーチのXLT86がある。それはIntel 8080用の.ASMソースコードからIntel 8086用の.A86ソースコードに変換した。8080のレジスターを用いた全体的なデータフロー解析を用い、出力されるコードサイズを最適化し、CP/M-80とMP/M-80(英語版)のプログラムが自動的にCP/M-86とMP/M-86に移行できるよう呼び出しを処理した。XLT86自体はPL/I-80でかかれ、CP/M-80環境のみならず、DEC VMS (for VAX 11/750 or 11/780)でも動くようになっていた[5]。
似たような、しかしもっと洗練されていないプログラムは1980年に86-DOSの一部としてティム・パターソンによって書かれたTRANS.COMがある。それは、いくつかのZ80アセンブラのソースコードを8086用の.ASMソースコードに変換した。しかし、これは制御コード、レジスタ、モードのサブセットのみをサポートしており、かなりの手動変換や手直しを必要とした。それはレジスタやジャンプの最適化を行わなかった[6][7]。
いくつかの言語実装は当初トランスコンパイラとして開発され、それらの言語実装の中には2016年現在もトランスコンパイラのものもある。以下の表に加え、CoffeeScriptのメンテナがJavaScriptに変換できる言語の一覧を提供している[8]。
開発者が、既存コードの大部分を別の言語に変換する場合、すべてを手動変換するよりもトランスコンパイラを使用するほうがよい場合が多い。「機械的」に変換が可能なのであれば、手動変換するのは単に手数を掛けるだけ無駄なばかりではなく、手作業にはミスがつきものだからである。一方で機械的な変換が不可能な場合もまたあり、ソース言語と目的の言語の組み合わせや、実際のコード次第でもあるがケースバイケースであって、一般論としては何も決定的なことは言えない。
Lokasi Pengunjung: 18.119.235.189