Bootstrapping nadal wymaga wsparcia z zewnątrz

Wyjaśnienie, które przeczytałeś jest poprawne. Jest dyskusja na ten temat w Kompilatory: zasady, techniki i Narzędzia (Księga Smoka):

• napisz kompilator C1 dla języka X w języku Y
• użyj kompilatora C1, aby napisać kompilator C2 dla języka X w języku x
• Teraz C2 jest w pełni samodzielnym środowiskiem hostingowym.

Bardzo ciekawą dyskusją o tymjest wykład współtwórcy Uniksa Ken Thompson'S Turing Award.

Zaczyna się od:

To, co zamierzam opisać, to jeden z wielu" kur i jaj " problemów, które pojawiają się, gdy Kompilatory są napisane w ich własnym języku. W tym prostocie użyję konkretnego przykładu z kompilatora C.

I pokazuje, jak napisał wersję kompilatora Unix C, która zawsze pozwalała mu Zaloguj się bez hasła, ponieważ kompilator C rozpoznałby program logowania i dodał specjalny kod.

Drugi wzorzec jest skierowany do kompilatora C. Kod zastępczy jest samodzielnym programem etapu I, który wstawia oba konie trojańskie do kompilatora. Wymaga to fazy uczenia się, jak w przykładzie Etapu II. Najpierw skompilujemy zmodyfikowane Źródło za pomocą zwykłego kompilatora C, aby wytworzyć podsłuch binarny. Instalujemy ten binarny jako oficjalny C. możemy teraz usunąć błędy ze źródła kompilatora i nowego pliku binarnego będą ponownie dodawane podczas kompilacji. Oczywiście Komenda logowania pozostanie na podsłuchu bez śladu w źródle.

Słyszałem o tym, jak napisać bardzo ograniczony kompilator w innym języku, a następnie użyć go do skompilowania bardziej skomplikowanej wersji, napisanej w nowym języku. Ta druga wersja może być następnie używana do kompilacji samej, a następna wersja. Za każdym razem, gdy jest kompilowany, używana jest ostatnia wersja.

Oto definicja bootstrapping:

Proces prostego systemu aktywującego bardziej skomplikowany system, który służy tym samym cel.

EDIT: Artykuł Wikipedii na temat bootstrapowania kompilatora obejmuje pojęcie lepiej niż ja.

Sprawdź podcast Software Engineering Radio episode 61 (2007-07-06), który omawia wewnętrzne Kompilatory GCC, a także proces bootstrapowania GCC.

Donald E. Knuth faktycznie zbudował WEB pisząc w nim kompilator, a następnie ręcznie skompilował go do asemblera lub kodu maszynowego.

Jak rozumiem, pierwszy interpreter Lisp został uruchomiony przez ręczne kompilowanie funkcji konstruktora i czytnika tokenów. Reszta tłumacza została następnie odczytana ze źródła.

Możesz sam sprawdzić czytając oryginalną pracę, rekurencyjne funkcje wyrażeń symbolicznych i ich obliczanie przez maszynę, Część I.

Inną alternatywą jest utworzenie maszyny kodu bajtowego dla Twojego języka (lub użycie istniejącego, jeśli jego funkcje nie są zbyt niezwykłe) i napisanie kompilatora do kodu bajtowego, albo w kodzie bajtowym, albo w żądanym języku przy użyciu innego pośredniego - takiego jak zestaw narzędzi parsera, który wyświetla AST jako XML, a następnie skompilowanie XML do kodu bajtowego za pomocą XSLT (lub innego języka dopasowującego wzorce i reprezentacji opartej na drzewie). Nie usuwa zależności od innego języka, ale może oznaczać, że więcej pracy bootstrapping kończy się w systemie końcowym.

To informatyczna wersja paradoksu z kurczakiem i jajkiem. Nie mogę wymyślić sposobu, aby nie napisać początkowego kompilatora w asemblerze lub innym języku. Gdyby można było to zrobić, powinienem to zrobić.

Właściwie, myślę, że Lisp prawie się kwalifikuje. Zobacz jego wpis w Wikipedii . Zgodnie z artykułem, funkcja Lisp eval może być zaimplementowana na IBM 704 w kodzie maszynowym, z kompletnym kompilatorem (napisanym w samym Lispie) wchodzącym w być w 1962 roku na MIT .

Każdy przykład bootstrapowania języka, który przychodzi mi do głowy (C, PyPy ) zostało wykonane po tym, jak powstał działający kompilator. Od czegoś trzeba zacząć, a reimplementacja języka sama w sobie wymaga napisania kompilatora w innym języku.

Jak inaczej by to działało? Nie wydaje mi się, żeby nawet koncepcyjnie można było zrobić inaczej.

Niektóre bootstrapowane Kompilatory lub systemy przechowują zarówno formę źródłową, jak i obiektową w swoim repozytorium:

• Ocaml jest językiem, który ma zarówno interpreter kodu bajtowego (tj. kompilator do kodu bajtowego Ocaml), jak i kompilator natywny (do x86-64 lub ARM, itd... asembler). Jego repozytorium svn zawiera zarówno kod źródłowy (pliki */*.{ml,mli}), jak i kod bajtowy (plik boot/ocamlc) postaci kompilatora. Więc podczas budowania najpierw używa swojego bajtowego kodu (poprzedniej wersji kompilator), aby skompilować się samodzielnie. Później świeżo skompilowany bajt jest w stanie skompilować natywny kompilator. Tak więc repozytorium Ocaml svn zawiera zarówno pliki źródłowe *.ml[i], jak i plik boot/ocamlc.

• Kompilator Rust pobiera (używając wget, więc potrzebujesz działającego połączenia z Internetem) poprzednią wersję swojego pliku binarnego, aby się skompilować.

• MELT jest językiem podobnym do Lispu do dostosowywania i rozszerzania GCC. Jest przetłumaczony na język C++ Kod przez bootstrapped Tłumacz. Wygenerowany kod C++ tłumacza jest dystrybuowany, więc repozytorium svn zawiera zarówno pliki źródłowe *.melt, jak i pliki "obiektowe" tłumacza.

• System sztucznej inteligencji J. Pitrata CAIA jest całkowicie samo-generujący się. Jest on dostępny jako zbiór tysięcy [A-Z]*.c wygenerowanych plików (również z wygenerowanym dx.h plikiem nagłówkowym) z kolekcją tysięcy _[0-9]* plików danych.

• Kilka Kompilatory Scheme są również uruchamiane. Scheme48, Chicken Scheme, ...