Tworzenie własnego kompilatora

Co do plików zawierających obiekty nie mam problemu i tworzenie pliku pas. Mam przygotowany interfejs do tego. Chodzi mi o przełożenie pliku pas na hex. Ktoś pomoże?

Chyba się odrobinkę z tym przełomowym pomysłem spóźniłeś. Poszukaj chętnych tutaj:
https://forum.lazarus.freepascal.org/index.php?action=forum

hex nie jest żadnym szczególnym rodzajem pliku (podobnie jak na przykład .txt czy .data), więc to trochę pytanie w stylu chodzi mi o przełożenie norweskiego na alfabet :-)

Generalnie na sam początek warto byłoby wybrać docelową platformę - czy chcesz mieć kompilator na Windowsa, Linuksa, Maczka, Androida, (...) - oraz docelową architekturę - x86, x86_64, ARM, AVR, (...). Mając to za sobą, pozostanie kwestia szukania informacji w stylu x86 instruction set, linux generate executable itd; jest to satysfakcjonująca zabawa od kilku miesięcy na całe życie.

Od siebie polecam zainteresowanie się projektem LLVM - to taki trochę "pół kompilator" do którego wrzucasz specjalny bajtkod LLVM, a on wypluwa binarki kompatybilne z masą architektur oraz systemów; mają nawet poradnik właśnie o tym, jak za pomocą LLVM napisać własny język od zera:

https://llvm.org/docs/tutorial/

(o LLVM jest oparty np. kompilator Rusta oraz clang.)

Najłatwiej będzie stworzyć własny interpreter, który by wykonywał skrypty własnego jezyka. Trudniej jest stworzyć coś, co będzie kompilowane do kodu pośredniego dla już istniejącej maszyny wirtualnej, a chyba najtrudniej po prostu kompilator, który na podstawie kodu źródłowego stworzy plik wykonywalny w znanym formacie, czyli np. plik exe dla Windows.

Wymaga to sporo wiedzy i czasu, więc najpierw zastanów się, czy w ogóle chcesz się tego podjąć.

Jeśli choć obsłużę buttona w moim pliku exe. Typu showmessage('radosc'); to resztę również :-)

Reszta to pikuś sprawdzanie składni czy zmienne czy procedury są wykorzystywane.w unitach. Gorzej z błędami typu errors. Wpierw pierwsze buttona obsłużenie. To moje wyzwanie na rok 22. Już stworzyłem w moim exe specjalną nazwę, która odróżnia Delphi i wszystkie środowiska. Wszystkie exe.

Po co służą pliki dcu w Delphi :-) To piony unitów gdzie kompilator łączy je po sekcji uses. Nawet są programy w Delphi, gdzie potrafią zamienić plik pas do dcu bez wymagania Delphi :-) i w RC_DATA umieścić w pliku exe.

Po co służą pliki dcu w Delphi

Hmm, DCU to są już skompilowane źródła, prawda? PAS -> DCU to jest właśnie najtrudniejsza część :-) Ale być może nie rozumiem co chciałbyś osiągnąć.

Mało tego zauważyłem że lazarus przyzwala tworzyć cegiełki przydatne do tworzenia pliku exe.delphi też kod pochodzi ze strony swisster.

Największe firmy komercyjne wysyłające na rynek programy, które nadają dana aplikacje nie są wstanie wyciągnąć zmiennych z danej aplikacji. Ja potrafię nawet dana funkcje zaporzyczyc? Z danego programu. Tutaj kłania się umiejętność hakierstea. A nie tylko pisania kodu.

Mariusz Bruniewski napisał(a):

Jeśli choć obsłużę buttona w moim pliku exe. Typu showmessage('radosc'); to resztę również :-)

Wątpię, abyś cokolwiek obsłużył, bo póki co sprawiasz wrażenie, jakbyś nie miał zielonego pojęcia o tym jak wygląda proces kompilacji do kodu maszynowego i jak zbudowane są pliki wykonywalne. I nie, pliki wykonywalne to nie są archiwa na pliki .dcu i śmieci pokroju RT_RCDATA.

Poza tym nie da się napisać sensownego kompilatora w taki sposób, jak przyzwyczaiłeś się pisać kod, czyli pchać logikę do zdarzeń komponentów i hura, gotowe. To bardzo skomplikowana działka, wymagająca ogromnej wiedzy i lat pracy, aby mieć choćby zalążek czegoś sensownego.

Nie chcę zniechęcać, ale jak zwykle trochę pijackich bredni, oraz trochę półprawdziwych domysłów i "wydaje mi się". Niemniej, kto pyta nie błądzi... chociaż w tym przypadku, wątpię by pytanie o drogę, faktycznie było szczere...

Pliki DCU nie są zaszyfrowane - to po prostu skompilowany kod maszynowy. Ale, żeby to po kolei zrozumieć szybko w skrócie(i uproszczeniu, każdy język ma swoje specyficzne kroki) przedstawię proces kompilacji:

1. Wykonanie makr preprocesora na plikach
2. Sparsowanie wynikowego kodu PAS do struktur
3. Analiza składniowa struktur - czy nie ma błędów w parsowaniu, a potem w strukturze instrukcji
4. Optymalizacja - rozwijanie pętel, wykrywanie iteratorów by umieścić je w rejestrze, etc.
5. Generowanie kodu maszynowego* ze sparsowanej struktury
6. Linkowanie z wcześniej skompilowanymi rzeczami jak np. biblioteka VCL czy funkcje systemowe
7. Wygenerowanie exe.

Proponuje zacząć, od napisania preprocesora zatem. Nie jest on konieczny do prostego kompilatora prostego języka, ale w przypadku Delphi/FreePascal już tak - bo to nie są proste szkoleniowe języki i używają preprocesora.

Później wypadałoby napisać parser języka Pascal. To skrót, bo sama składnia i semantyka języka jest już zdefiniowana. Normalnie trzeba by jeszcze to zaprojektować. Niemniej jak już masz definicję języka to trzeba napisać parser. To jest cholernie trudne. Proponuje zacząć od napisania parsera matematycznego z operacjami, dodawania, odejmowania, mnożenia, dzielenia wraz z obsługą nawiasów. To zobrazuje Tobie skalę trudności. Niemniej nikt dzisiaj już nie pisze sam parserów... (chyba, że ktoś jest poważnie niedouczony, lub musi zastosować specyficzne kruczki optymalizacyjne). Obecnie wykorzystuje się generatory parserów, które na podstawie definicji, generują kod parsera. Popularne to Yacc,/BISON czy lex/flex dla języka C.

Zobacz jak to robią we FreePascalu https://wiki.freepascal.org/Make_your_own_compiler,_interpreter,_parser,_or_expression_analyzer oraz https://wiki.freepascal.org/Plex_and_Pyacc

Po sparsowaniu należu przeanalizować w celu wykrycia błędów i ew. je zgłosić. Dalej musimy zmodyfikować strukturę żeby kod optymalizować. Tzn. nie musimy, ale większość kompilatorów obecnie to robi... i robi to cholernie dobrze, bo to praca tysięcy programistów, przez dekady. Po optymalizacji już generujemy kod maszynowy - albo bezpośrednio, albo generując kod ASM i potem stosując asembler. Jest też inne podejście - wygenerowanie kodu LLVM i zostawienie faktycznej kompilacji dla LLVM. Mając już taki stan musimy połączyć czyli zlinkować kod z innymi kawałkami kodu (jak dcu) już zbudowanymi. Np. jak masz w kodzie ShowMessage(..) to to wywołanie musi być zlinkowane ze skompilowaną implementacją w VCL, a ten z kolei wywołuje skompilowane funkcje systemowe WinAPI, by wygenerować okno (w Windows, ofc. inne implementacje VCL będą wołać np. X11).

No więc co z tym generowaniem kodu... Można jak pisałem generować kod od razu, ale to będzie trudne. Obecnie nikt tak nie robi. Nie ma sensu. Trzeba pisać generator/kompilator pod każdą architekturę uruchomieniową. Po co się męczyć? Można wygenerować kod maszyny pośredniej i to jej zostawić dalszą kompilacje/interpretacje. Wszyscy duzi gracze tak robią. Istnieją 3 popularne maszyny jak CLR (używane w produktach MS jak C#), JVM (Java i spółka) oraz LLVM. Ten ostatni buduje do n docelowych platform kod i dodatkowo jeszcze optymalizuje kod LLVM przed kompilacją do kodu maszynowego. Obecnie jest tendencja do pisania kompilatora do kodu LLVM -wtedy piszemy jeden kompilator, a LLVM załatwia uruchomienie na n środowiskach i platformach. Część przygotowująca kod LLVM to tzw. frontent kompilatora. Sam LLVM to backend kompilatora. Dla przykładu CLang to tylko front kompilatora C++ do struktur LLVM, a potem LLVM generuje kod maszynowy. Ba, nawet Delphi jest obecnie jedynie frontem do struktur LLVM.

Znów - jedynie przez niewiedzę, dla celów szkoleniowych lub mając specyficzne cele optymalizacyjne dla jednej platformy - to jedyne powody by nie pisać frontu pod LLVM, To ostatnie mając na względzie One Man Project- raczej nie występuje, więc jeśli nie chcesz zgłębić tematu kompilacji do maszynowego to nie polecam nie pisać w LLVM. Pisanie w LLVM pozwoli uniknąć lat studiowania architektury x86 i zestawu instrukcji.

No ale też te nieszczęsne funkcje z VCL - po zbudowaniu kompilatora Delphi musisz użyć tych z VLC co jest nielegalne, użyć alternatywnej implementacji LCL lub napisać tony własnych implementacji. To znów lata pracy i to zespołu programistów - patrz jak powstawał Lazarus.

To jest temat ciekawy, ale skomplikowany. Pytanie jaki problem chcesz rozwiązać. Jeśli chcesz mieć zajęcie na długie zimowe wieczory, to jest to dobry pomysł. Jeśli z kolei chcesz mieć pełną kontrole nad kodem by nikt nie wykradł super algorytmów lottowych to raczej sensu nie ma i nic nigdy nie powstanie.

Na sam początek proponuję zacząć od napisania parsera matematycznego, a potem może parser jakiegos języka prostszego niż Pascal (chodzi o konstrukcje składnie a nie używanie przez programistę języka). np. coś nie do końca użytecznego - język potrafiący odczytać z systemu wejście, pisać na wyjście, wykonywać instrukcje sterujące if, potrafiący wykonywac operacje arytemtyczne (o przyda sie wcześniejszy parser!) na zmiennych typu int jedynie. Jak to osiągniesz to będzie już coś. Potem możesz podejść do Pascala i VCL.. ale ja bym sugerował jednak LLVM a nie kod maszynowy, a tak serio to bym w ogóle odradzał, patrząc jak powoli rozwija sie FreePascal. No chyba, że to forma rozrywki - jedni łowią ryby, inni piją pod sklepem - można i marnować czas na pisanie kompilatorów.

Polecam linki lepiej to opisujące https://softwareengineering.stackexchange.com/questions/165543/how-to-write-a-very-basic-compiler oraz opracowanie z prostymi przykładami https://dev.to/evantypanski/writing-a-simple-programming-language-from-scratch-part-1-54a2 Dodam, że są całe książki o samym generowaniu parserów i całosemestralne kursy na studiach z tym związane. Temat bardzo złożony - sugeruje najpierw nauczyć się dobre programować, clean code, wzorce projektowe, nauczyć się tworzyć sensowną architekturę, dzielenia programu na warstwy i odpowiedzialności. To co do tej pory pokazujesz to antywzorce programowania. Wiesz... żeby nauczyć się biegać, najpierw musisz nauczyć sie chodzić.... na nogach bo podejście przez chodzenia na rękach będzie trudne, a tak wyglądają, Twoje zmagania z programowaniem jak na razie. Nie chcę zniechęcać - wręcz przeciwnie, zachęcam do szlifowania umiejętności, nie pod względem osiągania celów jak program co robi x, ale program co robi x i jest dobrze napisany etc.

No i ja tu pisze o kompilacji i bibliotece standardowej - ale co to za język bez debuggera... a symbole debuggowania, debugger i wykonywanie krokowe to jeszcze inna para kaloszy.... Podobnie dobre IDE z podpowiedziami etc.

Nie jest też prawdą, że nie można odczytać algorytmów z plików skompilowanych. Można i jest to bardzo proste. System to robi wykonując program. Jest oprogramowanie, co kod maszynowy zamienia z powrotem na kod ASM, rysuje grafy wywołań funkcji, listuje stringi zapisane w programie, czy nagłówki wołanych innych funkcji np. systemowych. Takim programem jest np. IDA. Są też takie co generują kod C na podstawie kodu maszynowego. To proces odwrtony do kompilacji - RE czyli reverse engineering. Stosuje się to powszechnie przez:

• Działy bezpieczeństwa do analizy co taki program faktycznie robi i czy nie robi na boku czegoś jeszcze
• Analizę, czy w programie nie ma luk, jakiś furtek umożliwiających atak i wykonanie zdalne kodu
• Podgląda się konkurencje jak coś zrobiło, celem kradzieży algorytmów.

Nie da się ochronić kodu, który ma być wykonany na maszynie klienta. Jedyny 100% skuteczny sposób to SaaS. Piszesz usługę, realizującą dany algorytm. Uruchamiasz ją w sieci i dajesz do niej API + system dostępu. Wtedy program musi połączyć się z Twoją usługą i poczekać na wynik. Są minusy jak narzut czasu na komunikacje, oraz konieczność bycia online, ale można kasować abonament za usługę i masz 100% pewności, że nikt nie odkryje algorytmu. Pierwsze z brzegu - usługi do OCR dokumentów, czy do rozpoznawania tablic rejestracyjnych - niechętnie dzielą się nawet skompilowanym swoim kodem i głównie udostępniają endpointy do wywołania.

@pieczarek:
Napisales chyba najbardziej wartosciowy wg mnie zestaw informacji na temat kompilatora i programowania jaki czytalem. A jak postrzegasz pisanie przez 1 osobe transpilatora? https://en.wikipedia.org/wiki/Source-to-source_compiler ,np.

1. Java to C
2. Java to C++
3. C++ to C

Czy to jest takze praca obliczona na wiele lat - czy wiele krocej, bo nie trzeba sie zmagac z asemblerem i wieloma innymi rzeczami?
Oczywiscie nie zawsze w 100% mozna przetlumaczyc jeden jezyk na inny, ale im tlumaczenie blizsze 100% tym cenniejsze.

Trudno mi ocenić. Trzeba by przeanalizować składnie i możliwości i zidentyfikować ile rzeczy trzeba po prostu przepisać a ile trzeba np. emulować. Z tego co wiem, to w Javie dużo typów to klasy, których w C++ nie ma... więc trzeba by je zaimplementować. Podobnie takie lukry jak adnotacje etc. Sądzę, jednak, że będzie trudniej, z tego względu, że "normalnie" pisze się front pod LLVM, który jest "prosty", a tutaj trzeba odtworzyć inny złożony język docelowy. Zabawa na pewno na miesiące. Nie powiem, że nie trzeba się z czymś zmagać... nadal się zmagasz, ale zamiast sparsowana struktura -> ASM/ sparsowana struktura -> LLVM, musisz stworzyć generator sparsowana struktura -> Java/C/C++. Co więcej część kruczków z C nie zadziałąją w implementacji Javy pewnie i odwrotnie. Problemem będą też biblioteki i zewn. soft którego raczej nie przerobimy. Pytanie też po co to robić... istnieją już transpillery. Generalnie warto poznać LLVM bo to daje duże możliwości. Zresztą transpilery nie są często używane - może w JS tak - tak jest babel, ale ogólnie nie spotkałem się z transpilowaniem Javy, C#, C++, C - owszem było portowanie projektów, ale automaty dowalały zaledwie część roboty, a ludzka ingerencja była zawsze konieczna. Z doświadczenia lepiej przepisać od zera niż bawić się w tłumaczenie C++ -> Java, z mojego doświadczenie przepisywanie powoduje mniej błędów niż tłumaczenie, można odświeżyć architekturę, a dłuższy czas się wyrównuje bo mniej czasu poświęca się na bugi, które wychodzą w tłumaczonym kodzie. Ze światka Delphi -> też dostarczali narzędzia do portowania do wyższych wersji środowiska - nigdy nie skonwertowałem serio dużego projektu bez problemu i ręcznego tłumaczenia.

Każde działanie powinno mieć cel. Wy wszyscy co chcecie pisać kompilatory i transpilatory -odpowiedzcie na jedno pytanie - po co? Szczególnie alternatywne produkty, do już istniejących opensourcowych projektów. Już prędzej zrozumiał bym dołączenie do projektu OS lub sforkowanie takiego. Niemniej idąc głębiej - po co Wam własny kompilator?

@pieczarek:

pieczarek napisał(a):

Każde działanie powinno mieć cel. Wy wszyscy co chcecie pisać kompilatory i transpilatory -odpowiedzcie na jedno pytanie - po co? Szczególnie alternatywne produkty, do już istniejących opensourcowych projektów. Już prędzej zrozumiał bym dołączenie do projektu OS lub sforkowanie takiego. Niemniej idąc głębiej - po co Wam własny kompilator?

https://4programmers.net/Forum/C_i_C++/357088-kompilatory_transpilator_cfront?p=1811302#id1811302

Ok, baw się jak chcesz. Niemniej nie sądzę żebyś osiągnął cel. Nauczenie sie dobrze języków takich jak C, C++ i Java to lata nauki. Do tego nauka kompilatorów to kolejne lata i będziesz umiał... kompilatory. Obecnie jest kilkanaście do kilkudziesięciu znaczących projektów kompilatorów. Jeśli potrafisz pisać kompilator nie oznacza, że potrafisz pisać w tym języku. Twórca PHP mimo, ze tworzy PHP nie wie jak dobrze w nim programować. On jest programistą C, a inni specjalizują się w PHP (tak przedstawiał to w wywiadzie). Do tego projekty. Część sponsorowana OS. Nie sądzę, że znajdziesz w Polsce ciekawą pracę w tej dziedzinie. Podobnie z C i C++ - C to głównie teraz programowanie systemowe i systemy wbudowane - mało tego w PL. C++ to znów albo systemy wbudowane, silniki gier, lub legacy. Najwięcej ciekawych rzeczy odnoszę wrażenie, że jest w Javie i C#. W sensie najłatwiej tam znaleźć projekt gdzie spotkasz powszechne problemy informatyki. Wszystkie kolejki, drzewa, struktury, złożoność, wzorce etc. Nie ma sensu więc walczyć z technologią jak C++, a skup się na problemach informatyki, które są abstrakcyjne, niezależne od technologii. Dziadek Knuth w swoich dziele "Sztuka programowania" zaproponował nawet model abstrakcyjnego nierealnego komputera by przedstawić podstawowe problemy informatyki. Nauka w tym celu C++ jest niezasadna moim zdaniem.

@pieczarek:

pieczarek napisał(a):

Najwięcej ciekawych rzeczy odnoszę wrażenie, że jest w Javie i C#. W sensie najłatwiej tam znaleźć projekt gdzie spotkasz powszechne problemy informatyki. Wszystkie kolejki, drzewa, struktury, złożoność, wzorce etc. Nie ma sensu więc walczyć z technologią jak C++, a skup się na problemach informatyki, które są abstrakcyjne, niezależne od technologii. Dziadek Knuth w swoich dziele "Sztuka programowania" zaproponował nawet model abstrakcyjnego nierealnego komputera by przedstawić podstawowe problemy informatyki. Nauka w tym celu C++ jest niezasadna moim zdaniem.

Nauka C i C++ lepiej wyjasnila mi:

1. programowanie samo w sobie i to jak dziala komputer (w asemblerach tez troche pisalem ale mniej),
2. Jave, bo moim zdaniem, ze:

• Garbage Collector to nie magia,
• Javowe referencje to odpowiednik wskaznikow w C i C++, tylko bez recznego zarzadzania pamiecia https://en.wikipedia.org/wiki/Manual_memory_management

Ale zdaje sobie sprawe, ze podstawowe problemy informatyki (np. algorytmy, struktury danych, wzorce projektowe, paradygmaty programowania: obiektowy, strukturalny, funkcyjny, generyczne, itd.) to abstrakcja i nie trzeba znac asemblera, C i C++ (implementacji kompilatora, architektury komputera, systemu operacyjnego), aby je poznac i stosowac. Dodatkowo C i C++ (a o wiele bardziej asemblery) wymagaja skupienia uwagi na niskopoziomych szczegolach, ktore np. w programowaniu webowym sa zwykle pomijane.
Jednak gdybym nie uczyl sie C i C++ to moim zdaniem stracilbym wiele - ale z drugiej strony - nie znam tego co moglbym zyskac kiedy programowalbym np. aplikacje webowe w PHP, HTML, Python, Ruby, itd. lub funkcyjnie w Haskell, Scala. Czyli nie moge wyrokowac o tym o czym nie mam pojecia, ale na chwile obecna mimo to jestem zdania, ze czas przeznaczony na C i C++ nie jest czasem straconym.

Na pewno to nie jest czas stracony - ale uczyć się pisać kompilatory to nie pomoże w dobrym nauczeniu się programowania w danym języku... bo to jest specyficzny problem. Jak najbardziej polecam naukę Javy oraz czystej architektury jak pisać duże systemu oparte na mikroserwisach, wydzielanie warstw dostępu do danych, providerów, testy jednostkowe, modularność etc. Samo C ma sens - to mały i elegancki język do pisania embended, oprogramowania systemowego, sterowników etc. Prędzej dostaniesz prace przy tego typu projektach niż przy tworzeniu kompilatora. Powtarzam - pisanie kompilatora języka X nie sprawi, że będziesz dobrze potrafił programować w X. Żeby dobrze pisać w X trzeba realizować różne projekty w technologii X.

Masz racje GC to nie magia - w .NET na pewno, a w javie pewnie też (nie zajmuje się javą, poza półrocznym kursem na studiach) istnieją pewnie różne strategie czyszczenia, klasyfikacji obiektów do odpowiednich generacji, finalizatory, destruktory (pewnie, że istnieją nawet w językach z GC) czy IDIsposable. Też trzeba mieć o tym pojęcie. GC chroni przed naruszeniem pamięci więc raczej AccesViolation nie poleci z powodu pomazania pamięci gdzieś i odwołanie się do zwolnionej pamięci, natomiast Null Referencje możemy trafić. Tak samo powszechne są wycieki pamięci zalewające pamięć, lub terminujące procesy (32bitowe) czy blokujące interfejsy komputera jak RS232 etc. Zatem nawet posiadając GC trzeba wiedzieć co się robi i jak co działa.

Nie zgodzę się tylko, że referencja to wskaźnik... nie, nie jest to to samo. Zresztą w C++ też są zarówno referencje jak i pointery.

Niemniej chyba to już zdrowy offtop. Jak masz jakieś wątpliwości co do nauki Javy czy C++ sugeruje nowy temat.

Dlaczego programiści ograniczają się, że coś jest trudne? Bo wolą pisać w czyimś środowisku? I wtedy mówią ja to napisałem. Ale co kto napisał? Tylko skompilowałeś tylko kod. Żaden wysiłek.

Dlaczego programiści ograniczają się, że coś jest trudne? Bo wolą pisać w czyimś środowisku? I wtedy mówią ja to napisałem. Ale co kto napisał? Tylko skompilowałeś tylko kod. Żaden wysiłek.

Dlaczego ludzie ograniczają się do stawiania domów z gotowych materiałów? Bo trudno jest samemu stworzyć cegły, beton i okna, więc wygodniej skorzystać z czyichś produktów? I wtedy mówią "ja postawiłem dom". Ale kto go postawił? Tylko postawiłeś cegły jedna na drugiej i wsadziłeś okna. Żaden wysiłek.

A tak poza tym - może skup się na kwestiach technicznych, bo filozofowanie raczej nie jest Twoją mocną stroną. A zresztą - niezależnie od mojej opinii na temat takich bezsensownych rozważań, to jest forum programistyczne a nie filozoficzne, więc proszę - daruj sobie i nam.

cerrato napisał(a):

Dlaczego programiści ograniczają się, że coś jest trudne? Bo wolą pisać w czyimś środowisku? I wtedy mówią ja to napisałem. Ale co kto napisał? Tylko skompilowałeś tylko kod. Żaden wysiłek.

Dlaczego ludzie ograniczają się do stawiania domów z gotowych materiałów?

Jak już tu jestem to napiszę coś nie na temat. Jak szukałem domu w Markach przy warszawie to widziałem były dom developera budującego domy. Miał też własną cegieglnię więc budował domy z własnej cegły. Swoją drogą strasznie nierówna była ta cegła

Jeszcze nie przeczytałem całego wątku, ale tworzenie własnego kompilatora zawsze ciekawe :P

@Mariusz Bruniewski:

Mariusz Bruniewski napisał(a):

Dlaczego programiści ograniczają się, że coś jest trudne? Bo wolą pisać w czyimś środowisku? I wtedy mówią ja to napisałem. Ale co kto napisał? Tylko skompilowałeś tylko kod. Żaden wysiłek.

Nie. Programista pisze kod (a najlepiej, żeby nie pisał), który ma rozwiązać dany problem. Jaki problem rozwiązuje napisanie własnego kompilatora? Moim zdaniem żaden. Kompilowanie we swoim kompilatorze nie daje żadnych korzyści. Co więcej twierdze, że jakościowo jest gorsze, bo narażasz się na problemy, które sam musisz wspierać, błędy, któych w domu nie jesteś wstanie wytestować (bo potrzeba tysięcy roboczo godzin by zrobić to dobrze). Każdy ma ograniczoną ilość czasu na tym padole idąc w transcendencje. Od nas zależy, czy będziemy wynajdywać koło od nowa, czy zrobimy coś pożytecznego. Jakby każdy wyprowadza od początku wzór na sumę granic Riemanna to inżynieria była by co najwyżej na takim poziomie, że co dziesiąty kowal potrafił by wykuć nie pękającą podkowę bo 9/10 nie potrafiła by sama odkryć procesu poprawnego hartowania skoro w ich ambicji nie chcieli korzystać z wiedzy przodków. Obecne kompilatory to dorobek życia wielu programistów i głupotą jest nie skorzystać z tego, żeby nie wspominać o szacunku do ich pracy - co nie każdy musi respektować, ale powinno sie szanować swój czas i potrafić ocenić swoje możliwości.

Nie mówię też jako tylko programista, ale i przedsiębiorca. Szlag mnie trafia jak ktoś wymyśla koło od nowa. Praca to nie test na maturze - to praca zespołowa i tracony czas to tracony hajs. Przedsiębiorca musi wiedzieć co może wykonać sam a co może wydelegować. Przedsiębiorca wie co powinien wydelegować bo sam nie dostarczy takiej jakości w czasie i budżecie. Wreszcie przedsiębiorca musi wiedzieć jaka jakość jest dostateczna do wygenerowania przychodu i kiedy dalsze inwestycje nie przekonwertują się w zwiększony przychód.

Można też majaczyć losowymi połączonymi pseudo technicznymi zwrotami, wierząc w swoją nieomylność i przewidywalność gier losowych... kto jak woli.

To, że coś jest bardzo trudne, nie jest problemem jeśli szukasz hobby - tak samo jak malowanie na ziarenku ryżu czy wykonywanie replik kościołów z runa leśnego i dachówek z łusek szyszek (tak, jest w Polsce człowiek co wytwarza bejcowane dachówki z szyszek...). Jeśli z kolei ma to prowadzić do jakiegoś celu - czyli projektu, który robi X, ale budowanym moim kompilatorem to jest to skrajnie nietrafione.

Zbudowanie projektu obcym kompilatorem jest nadal zbudowaniem unikatowej architektury i kodu. To jest moje dzieło, które stworzyłem, bo jeszcze kompilatory nie budują systemów na podstawie słowno-muzycznego opisu PO co chce uzyskać.

Zresztą nie ograniczyłem się do tego, że to jest trudne - dostałeś gotowe how-to - co po kolei odkrywać, gdzie zaglądać i poszczególne kroki do zbudowania własnego kompilatora. Niestety nie ma czegoś takiego jak TCustomCompiler.

Niedawno wspominałem sobie jak to z Borlandem było (i moimi początkami programowania przy okazji) pod wpływem tego: https://news.ycombinator.com/item?id=29512963
Natrafiłem na taką informację:

Hejlsberg [...] studied Electrical Engineering at the Technical University of Denmark.[5] While at the university in 1980, he began writing programs for the Nascom microcomputer, including a Pascal compiler [...] Later the product was licensed to Borland, and integrated into an IDE to become the Turbo Pascal system. [...] The compiler itself was largely inspired by the "Tiny Pascal" compiler in Niklaus Wirth's "Algorithms + Data Structures = Programs"

Już zdążyłem zapomnieć, że coś takiego było w tej książce. Może to jest jakiś trop do takich zabaw, ale bez podejścia bardzo na serio, które zostało tu wcześniej przedstawione.

@xy: Wirth popełnił http://c9x.me/compile/bib/wirthcc.pdf (Compiler Construction, Niklaus Wirth).

Ciekawi to Was prawda jak kod maszynowy przetwarza Wasze programy :-) ale żaden z Was nie przyzna się do tego.

Czytam z zainteresowaniem ten wątek i cały czas mam pytanie do autora pomysłu "Po co?".
W czym ten nowy, super nowy kompilator pomoże, co usprawni ?
Z miłą chęcią poznam założenia tego projektu. Może nam wszystkim coś umyka ?

Mariusz Bruniewski napisał(a):

Ciekawi to Was prawda jak kod maszynowy przetwarza Wasze programy :-) ale żaden z Was nie przyzna się do tego.

Mnie nie ciekawi bo ja już to wiem. Tak jak większość studentów co nie przebimbało porządnych kierunków informatycznych na uczelniach technicznych i uniwersytetach. Tylko, żeby się dowiedzieć i zrozumieć, nie ma potrzeby odkrywać samemu teorii parserów ani pisać kompletny kompilator tak skomplikowanego języka jak Delphi. Starczy zrobić prosty języczek z elementarnymi zasadami jak wspominałem. Można też inaczej - można analizować ASM co generuje GCC bez optymalizacji i obserwować wyniki np. przy rozwijaniu pętli, wypełniając tym cache procesora, poznać architekturę komputerów i arytmetykę - to podstawy i od tego powinno się zacząć, a nie replikacja kompilatora Delphi.

Ponieważ nikt jeszcze tego nie zrobił to ja to zrobię. Wrzucę link do ksiązki ze smokiem i samą okładkę też:

Książka mnie oczywiście rozczarowała bo jest bardzo mało o kompilowaniu języków funkcyjnych :(

Mariusz Bruniewski napisał(a):

Ciekawi to Was prawda jak kod maszynowy przetwarza Wasze programy :-) ale żaden z Was nie przyzna się do tego.

Jak kogoś ciekawi jak komputer przetwarza kod maszynowy to trzeba się uczyć asemblera i asemblacji oraz budowy procesora a nie budowy kompilatorów

Fajnie że od czasu do czasu pojawiają się na forum tematy typu wyderos czy takie jak ten. Dziwi trochę że od usera zarejestrowanego 16 lat temu ale jak widać na coming out nigdy nie jest za późno

Ok. Rozumiem, że ten projekt to taka forma zbadania jak to wszystko działa. Trzymam zatem kciuki !

@pieczarek:

Niemniej nikt dzisiaj już nie pisze sam parserów... (chyba, że ktoś jest poważnie niedouczony, lub musi zastosować specyficzne kruczki optymalizacyjne). Obecnie wykorzystuje się generatory parserów, które na podstawie definicji, generują kod parsera. Popularne to Yacc,/BISON czy lex/flex dla języka C.

taa, tylko 8/10 poważnych projektów :D

https://notes.eatonphil.com/parser-generators-vs-handwritten-parsers-survey-2021.html

Of the 2021 Redmonk top 10 languages, 8 of them have a handwritten parser. Ruby and Python use parser generators.

Wymyśliłem coś jeszcze łatwiejszego. Na spokojnie.:-) bez kompilacji exe.

Tutaj masz tutorial od PMa z MS od 0 do debuggera (z visual studio)

Pewnie znajdziesz tu wiele wskazówek/doświadczeń z projektu kompilatora C#