Kompilator źródła do źródła — Source-to-source compiler

Źródła do źródła tłumacz , kompilator źródła do źródła ( S2S kompilator ), transcompiler lub transpiler jest rodzajem tłumacza , który wykonuje kod źródłowy programu napisanego w języku programowania jako jego wejście i zapewnia równoważny kod źródłowy w tym samym lub innym języku programowania. Źródło-źródło nawróceni tłumacz między języków programowania, które działają na zbliżonym poziomie abstrakcji , podczas gdy tradycyjna kompilator tłumaczy z języka programowania wyższego poziomu do języka programowania na poziomie niższym . Na przykład tłumacz źródła do źródła może wykonać tłumaczenie programu z Pythona na JavaScript , podczas gdy tradycyjny kompilator tłumaczy z języka takiego jak C na assembler lub Java na kod bajtowy . Automatyczny parallelizing kompilator często podejmują w ramach programu w języku wysokiego poziomu jako dane wejściowe, a następnie przekształcić kod i opisywanie go z równoległych adnotacji kodowych (np OpenMP ) lub konstrukcjami językowymi (np Fortran „s forallwypowiedzi).

Innym celem kompilacji źródła do źródła jest tłumaczenie starszego kodu w celu użycia następnej wersji bazowego języka programowania lub interfejsu API, który łamie kompatybilność wsteczną. Przeprowadzi automatyczną refaktoryzację kodu, która jest przydatna, gdy programy do refaktoryzacji są poza kontrolą oryginalnego realizatora (na przykład konwertowanie programów z Pythona 2 na Python 3 lub konwertowanie programów ze starego API do nowego API) lub gdy rozmiar programu sprawia, że ​​ręczna refaktoryzacja jest niepraktyczna lub czasochłonna.

Transkompilatory mogą albo utrzymywać strukturę przetłumaczonego kodu jak najbliżej kodu źródłowego, aby ułatwić rozwój i debugowanie oryginalnego kodu źródłowego, lub mogą zmienić strukturę oryginalnego kodu tak bardzo, że przetłumaczony kod nie będzie wyglądał jak kod źródłowy. Istnieją również narzędzia do debugowania, które mapują transkompilowany kod źródłowy z powrotem do oryginalnego kodu; na przykład standard JavaScript Source Map umożliwia mapowanie kodu JavaScript wykonanego przez przeglądarkę internetową z powrotem do oryginalnego źródła, gdy kod JavaScript został, na przykład, zminimalizowany lub utworzony przez język transkompilowany do języka JavaScript.

Przykłady obejmują Closure Compiler , CoffeeScript , Dart , Haxe , TypeScript i Emscripten .

Tłumacze języka asemblera

Intel CONV86

Firma Intel wprowadziła na rynek swój 16-bitowy procesor 8086 jako źródło kompatybilności z 8080 , procesorem 8-bitowym. Aby to obsłużyć, Intel miał oparty na ISIS-II translator kodu źródłowego 8080 na 8086 o nazwie CONV86 (określany również jako CONV-86 i CONVERT 86) dostępny dla klientów OEM od 1978 roku, prawdopodobnie najwcześniejszy program tego rodzaju. Obsługuje wiele poziomów translacji i pracuje z częstotliwością 2 MHz na Intel Microprocessor Development System MDS-800 z 8-calowymi napędami dyskietek . Według raportów użytkowników nie działało to bardzo niezawodnie.

SCP TRANS86

Firma Seattle Computer Products ' (SCP) oferowała TRANS86.COM, napisany przez Tima Patersona w 1980 roku podczas opracowywania 86-DOS . Narzędzie może tłumaczyć kod źródłowy asemblera Intel 8080 i Zilog Z80 (z mnemotechniką Zilog/ Mostek ) na kod źródłowy .ASM dla Intel 8086 (w formacie zgodnym tylko z cross-assemblerem SCP ASM86 dla CP/M-80 ), ale jest obsługiwany tylko podzbiór opkodów , rejestrów i trybów, a często nadal wymagał znacznej ręcznej korekty i późniejszych przeróbek. Ponadto, wykonując tylko zwykłą transliterację , jednoprzebiegowy translator brute-force nie przeprowadzał żadnych optymalizacji rejestrów i skoków. Zajęło to około 24 KB pamięci RAM. Wersja 1 SCP TRANS86.COM działała na systemach opartych na Z80. Po uruchomieniu 86-DOS Paterson wykorzystał TRANS86 do przekształcenia się w program działający pod 86-DOS. Numer wersji 2, zamiast tego został nazwany TRANS.COM. Później, w 1982 roku, tłumacz był najwyraźniej również dostępny w Microsoft .

Sorcim TRANS86

Nazywany również TRANS86, Sorcim oferował tłumacza 8080 na 8086 również od grudnia 1980 roku. Podobnie jak program SCP został zaprojektowany do przenoszenia kodu aplikacji CP/M-80 (w formacie asemblera ASM, MAC, RMAC lub ACT80) do MS-DOS (w format zgodny z ACT86). W formacie ACT80 obsługuje również kilka mnemoników Z80. Tłumaczenie odbywało się na zasadzie instrukcja po instrukcji z pewną optymalizacją stosowaną do skoków warunkowych. Program działał pod kontrolą CP/M-80, MP/M-80 i Cromemco DOS z minimum 24 KB pamięci RAM i nie miał ograniczeń co do rozmiaru pliku źródłowego.

Badania cyfrowe XLT86

Znacznie bardziej wyrafinowany i pierwszy, który wprowadził optymalizujące technologie kompilatora do procesu tłumaczenia kodu źródłowego, był XLT86 1.0 firmy Digital Research we wrześniu 1981 r. XLT86 1.1 był dostępny do kwietnia 1982 r. Program został napisany przez Gary'ego Kildalla i przetłumaczony kod źródłowy .ASM dla Procesor Intel 8080 (w formacie zgodnym z asemblerami ASM, MAC lub RMAC) na kod źródłowy .A86 dla 8086 (kompatybilny z ASM86). Wykorzystując globalną analizę przepływu danych przy użyciu rejestru 8080, pięciofazowy wieloprzebiegowy translator zoptymalizowałby również wyjście pod kątem rozmiaru kodu i zadbał o konwencje wywoływania (wywołania CP/M-80 BDOS zostały odwzorowane na wywołania BDOS dla CP/M- 86 ), aby programy CP/M-80 i MP/M-80 mogły być automatycznie przenoszone na platformy CP/M-86 i MP/M-86 . Sam XLT86.COM został napisany w PL/I-80 dla platform CP/M-80. Program zajmował dla siebie 30 KB pamięci RAM plus dodatkowa pamięć na wykres programu . W systemie pamięci 64 KB maksymalny obsługiwany rozmiar pliku źródłowego wynosił około 6 KB, więc większe pliki musiały zostać odpowiednio podzielone przed tłumaczeniem. Alternatywnie, XLT86 był również dostępny dla DEC VAX/VMS (dla VAX 11/750 lub 11/780 ). Chociaż wejście i wyjście XLT86 działało na poziomie kodu źródłowego, reprezentacja programu w pamięci tłumacza i zastosowane technologie optymalizacji kodu stanowią podstawę rekompilacji binarnej .

Inni

Oprogramowanie 2500 AD oferowało translator kodu źródłowego 8080 na 8086 jako część swojego pakietu XASM dla maszyn CP/M-80 z Z80, a także dla systemów Zilog ZEUS i Olivetti PCOS .

Od 1979 roku firma Zilog oferowała translator Z80 na Z8000 jako część swojego systemu rozwoju PDS 8000. Zaawansowane mikrokomputery (AMC) i oprogramowanie 2500 AD oferowały również translatory Z80 do Z8000. Ten ostatni został nazwany TRANS i był dostępny dla Z80 CP/M, CP/M-86, MS-DOS i PCOS.

Implementacje języka programowania

Pierwsze implementacje niektórych języków programowania rozpoczęły się jako transkompilatory, a domyślną implementacją dla niektórych z tych języków są nadal transkompilatory. Oprócz poniższej tabeli opiekun CoffeeScript udostępnia listę języków, które kompilują się do JavaScript.

Lista transkompilatorów
Nazwa Język źródłowy Język docelowy
Cfront C++ C
HipHop PHP (HPHPc) PHP C++
Babel ES6+ ( JS ) ES5
ClojureScript Clojure JavaScript
JSweet Jawa Maszynopis
Swiftyfikuj Cel C Szybki
J2ObjC Jawa Cel C
Haxe Haxe ActionScript 3 , JavaScript , Java , C++ , C# , PHP , Python , Lua
Maia Maia Verilog
Cerber X Cerber JavaScript , Java , C++ , C#

Przenoszenie bazy kodu

Kiedy programiści chcą przełączyć się na inny język, zachowując większość istniejącego kodu, może być lepiej użyć transkompilatora w porównaniu do ręcznego przepisywania całego oprogramowania. W zależności od jakości transkompilatora kod może, ale nie musi wymagać ręcznej interwencji, aby działał poprawnie. Różni się to od „języków transkompilowanych”, w których specyfikacje wymagają, aby wyjściowy kod źródłowy zawsze działał bez modyfikacji. Wszystkie transkompilatory używane do przenoszenia bazy kodu będą oczekiwać ręcznej korekty wyjściowego kodu źródłowego, jeśli istnieje potrzeba osiągnięcia maksymalnej jakości kodu pod względem czytelności i konwencji platformy.

Potoki transkompilatora

Potok transkompilatora jest wynikiem rekurencyjnej transkompilacji . Łącząc ze sobą wiele warstw technologii, z krokiem transkompilacji między każdą warstwą, technologia może być wielokrotnie przekształcana, skutecznie tworząc rozproszoną specyfikację niezależną od języka .

XSLT to narzędzie do transformacji ogólnego przeznaczenia, które może być używane między wieloma różnymi technologiami w celu stworzenia takiego potoku kodu pochodnego .

Transkompilacja rekurencyjna

Transpilacja rekursywna (lub transkompilacja rekurencyjna ) to proces stosowania pojęcia transpilacji rekurencyjnej w celu stworzenia potoku przekształceń (często zaczynających się od jednego źródła prawdy ), które wielokrotnie zamieniają jedną technologię w drugą.

Powtarzając ten proces, można skręcić A → B → C → D → E → F, a następnie z powrotem do A(v2). Niektóre informacje zostaną zachowane przez ten potok, od A → A(v2), i ta informacja (na abstrakcyjnym poziomie) pokazuje, z czym zgadzają się poszczególne komponenty A–F.

W każdej z różnych wersji generowanych przez potok transkompilatora informacje te są zachowywane. Może przybierać różne kształty i rozmiary, ale zanim powróci do A (v2), po sześciokrotnej transkompilacji w powyższym potoku, informacje wracają do swojego pierwotnego stanu.

Ta informacja, która przetrwa transformację w każdym formacie, od A–F–A(v2), jest (z definicji) treścią pochodną lub kodem pochodnym .

Transpilacja rekursywna wykorzystuje fakt, że transpilery mogą albo trzymać przetłumaczony kod jak najbliżej kodu źródłowego, aby ułatwić rozwój i debugowanie oryginalnego kodu źródłowego, albo mogą zmienić strukturę oryginalnego kodu tak bardzo, że przetłumaczony kod nie wygląda jak kod źródłowy. Istnieją również narzędzia do debugowania, które mapują transpilowany kod źródłowy z powrotem do oryginalnego kodu; na przykład mapy źródłowe JavaScript umożliwiają mapowanie kodu JavaScript wykonanego przez przeglądarkę internetową z powrotem do oryginalnego źródła w języku transpilowanym do JavaScript.

Zobacz też

Uwagi

Bibliografia

Dalsza lektura

Zewnętrzne linki