W dniu 2012-05-04 00:51, M.M. pisze:
> <f...@g...SKASUJ-TO.pl> napisał(a):
>
>>>
>>> http://www.tckerrigan.com/Chess/TSCP
>>>
>>
>> no to jest dosyc ciekawe (ciekawe jest np hall of
>> shame ) to co by mi sie gigantycznie przydalo to
>> cos takiego tylko nie dotyczacego programu szachowego
>> a minimalnego kompilatora c (najlepiej z jakims ciezkim
>> komentarzem albo wewn tutorialem zeby dalo sie to
>> jakos latwo przeczytac)
>
> Trudno przecenić wartość edukacyjną minimalnych programów i
> prostych przykładów. Osobiście sporo się nauczyłem właśnie
> na źródłach TSCP. Dzięki temu mogłem czytać źródła bardziej
> zaawansowanych programów. Jeśli chciałbyś się zainteresować
> budową kompilatorów to pewnie rozpoczęcie nauki od czytania
> najprostszych źródeł byłoby również dobrą lekcją. Ale język
> C, nie wspominając o C++ to dość duże bydle. Może warto
> poszukać jakiegoś kompilatora/parsera również dla minimalnego
> języka?

Imo, jeśli chodzi o kompilatory, to podstawą jednak jest teoria
+ warsztaty praktyczne na dobrej uczelni. Jeden semestr np. na PP z
przedmiotu Języki Formalne I Kompilatory i temat stoi otworem,
uporządkowany. Prowadzą jak po sznurku.

Najpierw scanner, potem na to jakiś YACC a potem... Imo ważna
jest kolejność wchodzenia w temat, np. sam fakt rozdzielenia
scannera od parsera to pierwszy kroczek do przodu. Potem stopniowe
dodanie do tego kompilacji do jakiegoś kodu pośredniego itp itd.

Analiza programów bez jakiejkolwiek wiedzy teoretycznej
(np. co to jest alfabet, jakie są rodzaje gramatyk i pułapkach
niejednoznaczności, sposoby rozbioru) wydaje mi się jednak
podejściem koszmarnie nieefektywnym i rokującym z dużym
prawdopodobieństwem załamanie/porzucenie
tematu :)

http://brasil.cel.agh.edu.pl/~11sustrojny/gramatyka-
formalna/

do góry

Dnia Tue, 08 May 2012 16:10:51 +0200, zażółcony napisal:

> W dniu 2012-05-04 00:51, M.M. pisze:
>> <f...@g...SKASUJ-TO.pl> napisał(a):
>>
>>>>
>>>> http://www.tckerrigan.com/Chess/TSCP
>>>>
>>>
>>> no to jest dosyc ciekawe (ciekawe jest np hall of
>>> shame ) to co by mi sie gigantycznie przydalo to
>>> cos takiego tylko nie dotyczacego programu szachowego
>>> a minimalnego kompilatora c (najlepiej z jakims ciezkim
>>> komentarzem albo wewn tutorialem zeby dalo sie to
>>> jakos latwo przeczytac)
>>
>> Trudno przecenić wartość edukacyjną minimalnych programów i
>> prostych przykładów. Osobiście sporo się nauczyłem właśnie
>> na źródłach TSCP. Dzięki temu mogłem czytać źródła bardziej
>> zaawansowanych programów. Jeśli chciałbyś się zainteresować
>> budową kompilatorów to pewnie rozpoczęcie nauki od czytania
>> najprostszych źródeł byłoby również dobrą lekcją. Ale język
>> C, nie wspominając o C++ to dość duże bydle. Może warto
>> poszukać jakiegoś kompilatora/parsera również dla minimalnego
>> języka?
>
> Imo, jeśli chodzi o kompilatory, to podstawą jednak jest teoria
> + warsztaty praktyczne na dobrej uczelni. Jeden semestr np. na PP z
> przedmiotu Języki Formalne I Kompilatory i temat stoi otworem,
> uporządkowany. Prowadzą jak po sznurku.
>
> Najpierw scanner, potem na to jakiś YACC a potem... Imo ważna
> jest kolejność wchodzenia w temat, np. sam fakt rozdzielenia
> scannera od parsera to pierwszy kroczek do przodu. Potem stopniowe
> dodanie do tego kompilacji do jakiegoś kodu pośredniego itp itd.

... na tym poziomie to można znaleźć to samo na pierwszym lepszym wiki
o kompilatorach. Niektóre parsery BTW są tożsame ze scannerem,
pytanie czy wykładowca uaktualnił skrypt po dwutysięcznym którymś.

>
> Analiza programów bez jakiejkolwiek wiedzy teoretycznej
> (np. co to jest alfabet, jakie są rodzaje gramatyk i pułapkach
> niejednoznaczności, sposoby rozbioru) wydaje mi się jednak
> podejściem koszmarnie nieefektywnym i rokującym z dużym
> prawdopodobieństwem załamanie/porzucenie
> tematu :)

Czasem można mieć podejście takie jak kompilator: czytać
sobie kod i oglądać jak jest napisany, a (prawie jak kompilator)
olewać co on robi na jakimś poziomie. Chociaż jeżeli mam być
szczery to nieczęsto mam takie zapędy, ale poprawiając wielki
blob którego nie znam to tak faktycznie działa, nie muszę
znać całości żeby go odpowiednio przekształcić: robi potem to
samo, tylko szybciej i się nie wywala, a analizuję go
bardzo wybiórczo (a'la escape analysis). Oczywiście tak jest
wtedy, gdy muszę poprawić coś, co mam centralnie w dupie,
poza tym że ma działać potem lepiej.

Uprzedzając: znam teorię.

Edek

do góry

zażółcony <r...@c...pl> napisał(a):

> Imo, jeśli chodzi o kompilatory, to podstawą jednak jest teoria
Z pewnością podstawą każdego trudniejszego zadania jest teoria.

Jednak podstawy to zdecydowanie nie wszystko. Weźmy np. taki
teoretyczny algorytm mini-max, albo nawet alpha-bete do gry w
szachy czy warcaby - program oparty jedynie o takie podstawy nie
będzie grał lepiej niż małpa. A tymczasem dobre programy pokonują
najlepszych ludzi, dobre kompilatory generują lepszy kod maszynowy
niż programiści...

Samo parsowanie albo zamiana na kod maszynowy nie wydaje się
trudnym zadaniem. Bardzo pracochłonnym jest, ale każdy przeciętny
programista jakby zadał sobie ten spory trud to podejrzewam żeby zrobił
kompilator języka C.

Natomiast strasznie enigmatyczne wydaje mi się generowanie ekstremalnie
wydajnego kodu maszynowego - takiego prawie optymalnego.

> + warsztaty praktyczne na dobrej uczelni. Jeden semestr np. na PP z
> przedmiotu Języki Formalne I Kompilatory i temat stoi otworem,
> uporządkowany. Prowadzą jak po sznurku.

> Najpierw scanner, potem na to jakiś YACC a potem... Imo ważna
> jest kolejność wchodzenia w temat, np. sam fakt rozdzielenia
> scannera od parsera to pierwszy kroczek do przodu. Potem stopniowe
> dodanie do tego kompilacji do jakiegoś kodu pośredniego itp itd.
Zawsze mnie dręczył temat jakiegoś języka który by się dało
skompilować nie do kodu maszynowego, ale do innego języka wysokiego
poziomu, choćby do tych trzech: Javy, C i C++ :) Składnia jakaś
Javo-podobna...

> Analiza programów bez jakiejkolwiek wiedzy teoretycznej
> (np. co to jest alfabet, jakie są rodzaje gramatyk i pułapkach
> niejednoznaczności, sposoby rozbioru) wydaje mi się jednak
> podejściem koszmarnie nieefektywnym i rokującym z dużym
> prawdopodobieństwem załamanie/porzucenie
> tematu :)
Hmmm nie wiem, nigdy nie miałem wystarczającej motywacji aby brać się
za pisanie analizatora jakiegoś bardziej skomplikowanego formatu.
Jak dotąd, zawsze gdy się zapowiadała jakaś ciekawsza praca, to potem
okazywało się że to student 3go roku szuka pomocy do pracy inż bo sam
nie umie programować w żadnym języku.

Tak z własnego zainteresowania to intryguje mnie jedynie tak jak już
pisałem wyżej: jakiś meta-język kompilowany do kilku różnych języków
wysokopoziomowych - ale to masa roboty, pewnie nigdy nawet nie zacznę
takiego projektu.

Pozdrawiam

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 08.05.2012 16:10, zażółcony wrote:
> Imo, jeśli chodzi o kompilatory, to podstawą jednak jest teoria
> + warsztaty praktyczne na dobrej uczelni. Jeden semestr np. na PP z
> przedmiotu Języki Formalne I Kompilatory i temat stoi otworem,
> uporządkowany. Prowadzą jak po sznurku.
Tu są materiały:
http://wazniak.mimuw.edu.pl/index.php?title=Podstawy
_kompilator%C3%B3w

--
Pozdrawiam
Michoo

do góry

Dnia Tue, 08 May 2012 20:37:26 +0000, M.M. napisal:

> zażółcony <r...@c...pl> napisał(a):
>
>> Imo, jeśli chodzi o kompilatory, to podstawą jednak jest teoria
> Z pewnością podstawą każdego trudniejszego zadania jest teoria.
>
> Jednak podstawy to zdecydowanie nie wszystko. Weźmy np. taki
> teoretyczny algorytm mini-max, albo nawet alpha-bete do gry w
> szachy czy warcaby - program oparty jedynie o takie podstawy nie
> będzie grał lepiej niż małpa. A tymczasem dobre programy pokonują
> najlepszych ludzi, dobre kompilatory generują lepszy kod maszynowy
> niż programiści...
>
> Samo parsowanie albo zamiana na kod maszynowy nie wydaje się
> trudnym zadaniem. Bardzo pracochłonnym jest, ale każdy przeciętny
> programista jakby zadał sobie ten spory trud to podejrzewam żeby zrobił
> kompilator języka C.

Zwłaszcza, że najpopularniejsze kompilatory C/C++ nie mają generowanych
parserów, pisane są ręcznie.

>
> Natomiast strasznie enigmatyczne wydaje mi się generowanie ekstremalnie
> wydajnego kodu maszynowego - takiego prawie optymalnego.

Niektóre uczelnie uczą albo uczyły zaczynając nie od parsowania
tylko od struktur danych i optymalizacji. Wszystko co wrzuca
się do worka zwanego peephole jest jak najbardziej odpowiednie
na początek. Jeżeli mnie pamięć nie myli, ten program zajęć pomija
całkowicie parsowanie. Nie jestem pewien czy określenie "teoria"
jest najszczęśliwsze, bo zajęcia to głównie praktyka, cała teoria
sprowadza się do reguły as-if oraz rozwinięć w kierunku przekształceń
co może zahaczać o różne tematy takie jak currying.

>
>> + warsztaty praktyczne na dobrej uczelni. Jeden semestr np. na PP z
>> przedmiotu Języki Formalne I Kompilatory i temat stoi otworem,
>> uporządkowany. Prowadzą jak po sznurku.
>
>> Najpierw scanner, potem na to jakiś YACC a potem... Imo ważna
>> jest kolejność wchodzenia w temat, np. sam fakt rozdzielenia
>> scannera od parsera to pierwszy kroczek do przodu. Potem stopniowe
>> dodanie do tego kompilacji do jakiegoś kodu pośredniego itp itd.
> Zawsze mnie dręczył temat jakiegoś języka który by się dało
> skompilować nie do kodu maszynowego, ale do innego języka wysokiego
> poziomu, choćby do tych trzech: Javy, C i C++ :) Składnia jakaś
> Javo-podobna...

Tak jest i/lub było. Kiedyś Fortran kompilował się do C, później
od razu do formy pośredniej, bo tak jest lepiej. Istnieje co najmniej
kilka kompilatorów tworzących nie binarki a może nie tyle Javę,
co bajtkod JVM. Nie muszą mieć składni Javo-podobnej, to są bardziej
strukturalne zależności. Więc możesz stworzyć kolejny.

Edek

do góry