Witam. Mam taką prośbę. Może ktoś pisał kiedyś własny kompilator :) ??. Wiem że troche dziwne pytanie ale musze napisać właśnie taki własny kompilator. I zna ktoś może jakieś stronki w necie które mi w tym pomogą. Wiem że nie jest łatwe zagadnienie. chcĘ wiedzieć choć troche ... przynajmniej jak to zacząć bo wiem ze to będzie baaaaaardzo długi projekt. Szukałem troche w necie ale widać albo nieumiejętnie albo umiejętnie i tego w necie nie ma za wiele po prostu. No więc może ktoś ma w tym temacie jakieś doświadczenie i może mi w jakiś sposób pomóc ??.Pozdro
0
0
Analizuj to :
http://lua.org
lub kompilator z javy -> open source ;)
1
Wlasny kompilator czego? Brainfucka? Ogolnie radze zarzucic pomysl bo widac ze nie masz wystarczajacej wiedzy. Nawet nie wiesz jak do tego podejsc. Bez bardzo dobrej znajomosci asma sie nie obejdzie. Maksimum co mozesz zrobic to interpretator jakiegos jezyka skryptowego.
1
Faszczu napisał(a)
Wlasny kompilator czego? Brainfucka? Ogolnie radze zarzucic pomysl bo widac ze nie masz wystarczajacej wiedzy. Nawet nie wiesz jak do tego podejsc. Bez bardzo dobrej znajomosci asma sie nie obejdzie. Maksimum co mozesz zrobic to interpretator jakiegos jezyka skryptowego.
od dobrego interpretera do kompilatora droga nie jest daleka ;)
0
No nie gadaj, interpretowany to pikus, nie trzeba tykac kodu maszynowego zeby zrobic binaria a do tego juz potrzeba wiedzy.
0
No więc tak.
Wlasny kompilator czego? Brainfucka? Ogolnie radze zarzucic pomysl bo widac ze nie masz wystarczajacej wiedzy. Nawet nie wiesz jak do tego podejsc. Bez bardzo dobrej znajomosci asma sie nie obejdzie. Maksimum co mozesz zrobic to interpretator jakiegos jezyka skryptowego.
Więc tak ... na razie potrzebny mi będzie skaner i do tego analiza leksykalna.Nie wiem czy dobrze mówie ale mam nadzieje ze sie nie myle w nazwach. A tak <ort>w ogóle</ort> to patrzyłem że ten ASM jest pod turbo pascala ... choć pod Devc++ też chodzi ale coś mi błędy wyświetlało. ort! poczytać więcej bo jestem totalny beton w tym asemblerze.
0
I dlatego nic nie zrobisz bo nie wiesz o czym mowisz.
0
Faszczu napisał(a)
No nie gadaj, interpretowany to pikus, nie trzeba tykac kodu maszynowego zeby zrobic binaria a do tego juz potrzeba wiedzy.
czyzby? ja bym powiedzial ze wlasnie gramatyka jest najwiekszym problemem bo jezeli masz juz to to konwersja np: poprzez dodatkowy interptreter bytecode czy kompilator asma nie jest juz tak straszna
0
cepa napisał(a)
Faszczu napisał(a)
No nie gadaj, interpretowany to pikus, nie trzeba tykac kodu maszynowego zeby zrobic binaria a do tego juz potrzeba wiedzy.
czyzby? ja bym powiedzial ze wlasnie gramatyka jest najwiekszym problemem bo jezeli masz juz to to konwersja np: poprzez dodatkowy interptreter bytecode czy kompilator asma nie jest juz tak straszna
A ja zgodzę się z Faszczu (Faszczem ;) ). Owszem implementacja gramatyki języka (a dokładniej zbudowanie dobrego parsera) może nie jest najłatwiejsze (chociaż do najtrudniejszych też nie należy - przecież nie trzeba Od razu budować kompilatora języka obiektowego czy jakiś makro asembler - można zbudować kompilator właśnie Brainfucka ;) ) ale dużo <ort>prostrze</ort> od budowania binarek. Budując kompilator po pierwsze trezba znać asembler procka pod który się pisze, system operacyjny pod który się pisze, nie mówiąc już o budowie pliku binarnego (poszczególne segmanty, relokacje itd.). Przy interpretatorze znajomość taka nie jest konieczna - no chyba że interpreter wywołuje specjalne funkcje systemu np. okienka w windows.
Ale ciekawym rozwiązaniem może być "pseudo kompilator". Działa to na podobnej zasadzie jak dawny Visual Basic (dawny bo nie wiem jak jest z obecnymi wersjami). Skompilowany exe w takim basicu to nic innego jak "uniwersalny" plik wykonywalny do którego dołączony jest kod programu tyle że nie w postaci źródłowej, a już przygotowanej do interpretacji (taki kod ma specjalną nazwę ale teraz nie pamiętam jak się nazywa - często nazywa się go kodem pośrednim).
// bytecode - Q?
0
mczarny ~ system operacyjny? budowa pliku binarnego? O czym ty mowisz? Chodzi o kompilator, a kompilator tworzy pliki obiektowe (wynikowe, z segmentami, relokacjami itp, jak to nazwales tworzy linker), na upartego moze tez tworzyc kody zrodlowe asma ktore potem mozna potraktowac jakims asemblerem (ja tak robilem w moim z, czy jak mu tam bylo). Poza tym struktura PE, Coff'a, elf'a itp nie jest wcale taka skomplikowana (zwlaszcza przy jego tworzeniu), wystarczy tylko poczytac troche dokumentacji.
Pisalem swoj kompilator (tani bo tani ale byl), pisalem swojego OSa (j/w) i wiem co mowie - parser to najwiekszy problem (pominajac oczywiscie gotowe narzedzia typu LEX/YACC, moze MS albo Borland zrobi jakiegos czarodzieja niedlugo :P).
0
Wolverine napisał(a)
mczarny ~ system operacyjny? budowa pliku binarnego? O czym ty mowisz? Chodzi o kompilator, a kompilator tworzy pliki obiektowe (wynikowe, z segmentami, relokacjami itp, jak to nazwales tworzy linker)
Masz racje że kompilator tworzy pliki obiektowe, ale żeby dojść do obiektów to trzeba umieć zamienić sparsowaną składnie na rozkazy asemblera, czego w przypadku interpretera robić nie trzeba.
Wolverine napisał(a)
, na upartego moze tez tworzyc kody zrodlowe asma ktore potem mozna potraktowac jakims asemblerem (ja tak robilem w moim z, czy jak mu tam bylo).
J/W - znajomość asemblera co w przypadku interpretera nie jest konieczne.
Wolverine napisał(a)
Poza tym struktura PE, Coff'a, elf'a itp nie jest wcale taka skomplikowana (zwlaszcza przy jego tworzeniu), wystarczy tylko poczytac troche dokumentacji.
Ok zgodze się , sama budowa nie jest skomplikowana, mi nie chodziło o samą budowę plików tylko o ich zawartość z której są budowane (czyli np. sekwencje rozkazów w asemblerze).
A co do systemu operacyjnego, to jeśli nasz kompilator tworzy od razu kod wykonywalny bez pośrednictwa linkera (a co za tym idzie bez łączenia z jakimiś standardowymi bibliotekami) to znajomośc systemu jest potrzebna, bo inaczej program będzie wyglądał gdy skompilujesz go dla DOSa Windowsa, OS-2 czy Linux-a.
0
To czy będzie trudne czy nie, zależy od języka, oczekiwanej wydajności i trochę od platformy na którą generujemy kod.
Jeżeli jest prosty język to:
-lex lub inny podobny generator - i masz gotowy analizator leksykalny (a jak prosty język i nie jest dla nas ważna wydajność to można nawet ręcznie)
-yacc lub inny podobny generator - i masz gotowy analizator składniowy (też można ręcznie jak niewielkie, ale to na prawdę małe powinno być). Dodatkowo jak akcje semantyczne się napisze, to prawie gotowy kompilator.
-ponieważ zakładam, że ma być maksymalnie prosty, to pomiń optymalizację (najtrudniejsza moim zdaniem faza)
-jak mocno chcesz, to nawet nie musisz mieć kodu pośredniego tylko od razu generować
-jeżeli absolutnie proste chcesz, to możesz generować kod do asm. Jeżeli chcesz do kodu binarnego to najlepiej generuj do dosowych *.com wykorzystując tylko najprostsze operacje (program będzie duży i wolny, ale będzie działać).
Wszystko zależy od tego, czy chcesz jakiś rzeczywisty język kompilować, czy jakąś zabawkę.
Któryś raz z kolei polecę: "Kompilatory: metody, reguły i narzędzia" Aho, Sethi, Ullman. Nieśmiertelna książka, chociaż strasznie stara.
0
a czy są jakieś sposoby aby w tracie parsowania kodu (lub w ktorymś z późniejszych etapów) móc wykryć możliwosc wystąpienia niekonczących się petli? tak alby ostrzec użytkownika warringiem: "probably infinitive loop"?
0
Do gramatyki polecam http://www.antlr.org/
0
albo yacc/bison zeby w ogole dowiedziec sie jak to dziala..
1
Jak to działa to łatwiej raczej się nauczyć właśnie na ANTLR. Parsery LL(k) są prostsze w budowie a generatory tych parserów generują krótszy kod źródłowy.