🚀 go-pugleaf

W dniu piątek, 21 kwietnia 2017 22:51:12 UTC+2 użytkownik (fir) napisał:
> W dniu piątek, 21 kwietnia 2017 20:00:46 UTC+2 użytkownik godek....@gmail.com napisał:
> > W dniu piątek, 21 kwietnia 2017 18:01:23 UTC+2 użytkownik (fir) napisał:
> > 
> > > jak ja ostatnio pisalem prosty kompilator "wyrazen z jednym rowna sie i z czterema operatorami (+-*/) plus nawiasy" to to wcale nie do konca przypominalo 'petle z ifami lub ze switchem')
> > 
> > też ostatnio rozwijam kompilator na potrzeby pracy magisterskiej,
> > ale kompilacja to jednak coś innego, niż parsowanie. w ogólnym
> > przypadku celem parsowania jest zbudowanie drzewa rozbioru składni,
> > choć oczywiście jeżeli format instrukcji jest prosty, często może
> > wcale nie być nawet takiej potrzeby (co ma znaczenie, jak ktoś
> > pracuje w językach takich jak C czy Pascal, gdzie obsługa drzew
> > jest raczej uciążliwa). Jeżeli masz już drzewo rozbioru składni,
> > to stworzenie interpretera dla języka jest raczej łatwym zadaniem.
> > 
> > Dla amatorów Lispa parsowanie jest zasadniczo umiarkowanie ciekawym
> > zagadnieniem, natomiast kompilacja -- jak najbardziej. Najbardziej
> > podstawowa technika kompilacji to konwersja do postaci, w której
> > funkcje przekazują kontynutacje ("Continuation-Passing Style").
> > 
> > Na przykład, wyrażenie (+ (* x y) (/ z w))
> > w postaci przekazującej kontynuacje miałoby postać
> > 
> > (pass* x y
> >   (lambda (xy)
> >     (pass/ z w
> >        (lambda (zw)
> >          (pass+ xy zw return)))))
> > 
> > gdzie pass+, pass/ i pass* to CPS-owe odpowiedniki działań arytmetycznych,
> > a "return" to "nadrzędna kontynuacja" (np. koniec programu, albo
> > powrót do wywołującej funkcji). Słowo kluczowe "lambda" ma takie samo
> > znaczenie, jak w języku Scheme czy w lambda-rachunku, i podobne
> > jak "function" w JavaScripcie.
> > 
> > Program w takiej postaci można już dość łatwo przekształcić
> > do pseudo-asemblera:
> > 
> > xy := x * y
> > zw := z / w
> > result := xy + zw
> > return
> > 
> > albo czegoś w tym rodzaju. Dalszy etap nosi w literaturze nazwę
> > "register allocation" (i używa się do tego np. metod kolorowania
> > grafów), a chodzi w nim o to, żeby tym zmiennym przechowującym
> > wyniki pośrednie przypisać konkretne rejestry procesora (żeby zmniejszyć
> > liczbę dostępów do pamięci)
> > 
> > lista źródeł, na których się opieram, jest dostępna tutaj:
> > 
> > https://www.quora.com/How-do-people-develop-lisps/answer/Panicz-Godek
> 
> 
> jak wspomnielem nie chce mi sie zagladac do mojego kodu i przerywac cenny stan odpoczywania ale moge powiedziec z pamieci jak to dzialalo (chyba zreszta o tym tu pisalem)
> 
> jak mam np takie wyrazenie
> 
> x = (3*a+(c-2)/d+f)*g
> 
> to moj kod po prostu polegal na tym ze wykonywal powtarzalne przejscia i odkladal 'partykuly' na liste
> upraszczajac wyrazenie
> 
> t1=3*a
> x = (t1+(c-2)/d+f)*g
> t2=(c-2)
> x=(t1+t2/d+f)*g
> t3=t2/d
> x=(t1+t3+f)*g
> t4=t1+t3
> x=(t4+f)*g
> t5=(t4+f)
> x=t5*g
> t6=t5*g
> x=t6
> 
> sama liste 
> t1=3*a
> t2=(c-2)
> t3=t2/d
> t4=t1+t3
> t5=(t4+f)
> t6=t5*g
> x=t6
> 
> na asm juz jest przerobic banalnie
> 
> mov t1,3
> mul t1,a
> mov t2,c
> sub t2,2 ...itd
> 
> algorytm jest uwaam dobry i nie bardo prypomina switcha w petli (bo te operacje sa dosyc uniformiowane i dzialaja w 'multipasie' ) aczkolwiek zakodowalem dokladnie to ale mam wrazenie mniej elegancko niz by sie dalo... mozna by napisac pseudokod jak to zrobic ladniej i prosciej, (ew nieco bardziej ogolnie dla wiekszego seta operatorów), moze troche pozniej cos skrobne

mozliwe jest ze detale tego algorytmu wymagaja wlasnie malej 'konsyderacji'
ogolnie jesli te operacje upraszczajace mialbym juz zakodowane i nazwalbym je
- zdejmij_mnozenie
- zdejmij_dzielenie
- zdejmij_maly_nawias
- zdejmij_dodawanie
- zdejmij_odejmowanie

to jak puscis to w petli by to dzialalo jak najlepiej?
(ciekawe pytanie, ktos ma chec odpowiedziec?)