Zadání domácího úkolu
- luk
- Matfyz(ák|ačka) level II
- Příspěvky: 74
- Registrován: 6. 6. 2005 18:32
- Typ studia: Informatika Mgr.
- Bydliště: Praha
Zadání domácího úkolu
Jak jsem byl požádán jedním kolegou, dávám sem info o zadání domácího úkolu. Nicméně, určitě se mi sem nepodaří napsat vše, tak kdyžtak prosím jiné o upřesnění
Předně to bude vypadat tak, že bude základní domácí úloha, kterou musí udělat všichni, chtějí-li zápočet, a pak bude možné jí různými směry rozšiřovat a za to dostávat body na zkoušku.
Základ je převést výstup, co nám generuje frontend (instrukce zásobníkového stroje) na instrukce stroje registrového. Budou opět dvě verze, bez polí a s nimi.
Zdaleka ještě nebylo vysvětleno vše, tak ještě není na čem pracovat, to se nám podaří asi až za 14 dní, teď se hlavně vysvětlila dokumentace ICM a trochu se něco řeklo o použitých datových strukturách...
Dokumentace ICM:
http://ulita.ms.mff.cuni.cz/mp/vyuka/SW ... instr.html
Grafy pro každou instrukci znázorňují, jakými mikrooperacemi se instrukce vykonává a v jakém pořadí.
Zelené krabice manipulují s registry
Červené a oranžové s pamětí
Bílé jsou nějaký výpočet
Šipky znázorňují tok dat, čísílka znamenají pořadí operandu
Každá mikrooperace nějakou dobu trvá, to načítá ICM z konfiguračního souboru a potom během vykonávání měří celkovou dobu, kterou program pracuje. Vertikální poloha krabice označuje pořadí vykonávání.
V grafu nejsou vidět všechny závislosti mezi operacemi, vlastně je tam jen tok dat, ale je třeba dát si pozor třeba na antidependence, to už je na nás.
Kostra D.Ú.:
Na internetu ještě zdrojáky nejsou, ale je tam celkem čitelná dokumentace souborů...Náš startovní bod bude funkce void mlaskal::the_rmgen(...) v souboru rmgdirect.cpp
Datové struktury:
Dokumentace je tady http://ulita.ms.mff.cuni.cz/mp/vyuka/SW ... index.html
Výchozím bodem je třída abstract_ic, která reprezentuje celý mezikód...Bude použita jak pro vstup (výstup frontendu) tak pro výstup.
Její asi nejdůležitější metoda je get_abstract_functions(), přes kterou se dostaneme k objektu třídy abstract_functions, která sdružuje všechny procedury mezikódu (tj. procedury, funkce a hlavní blok programu). Není to nic jiného než kontejner a tak se s ní také pracuje.
Jednotlivé procedury jsou reprezentovány objekty třídy abstract_function.
Odtud lze získat blok mezikódu příslušející proceduře, její parametry, návratovou hodnotu, lokální proměnné.
Důležitý je koncept UID a other_UID, které mají všechny objekty, které se v abstract_ic schovávají.
UID je zaručeně jednoznačný identifikátor a other_UID je identifikátor, který si může programátor nastavit sám. Dá se použít například k provázání zdrojové a cílové procedury, tj. z frontendu mi přilezla procedura XYZ se svým UID a já teď musím vytvořit její odpovídající sestřičku upravenou pro registrový stroj. Z důvodů, o kterých se ještě zmíním je třeba umět najít původní proceduru, která k ní patří, nabízí se tedy nastavit other_UID tohoto nového objektu na UID objektu výchozího.
Tak a teď přichází dvě nejkomplikovanější věci výkladu, na ty možná bude potřeba se mne (nebo někoho jiného) ještě doptat nad papírem...
V cílovém kódu bude potřeba mimo jiné upravovat instrukce podmíněného skoku a instrukci CALL...
Pro podmíněné skoky jsou v reg. stroji jiné instrukce než v zás. (JF - JEF, JT - JET)...Reprezentovány jsou tak, že jako operand obsahují UID instrukce, na kterou mají skočit. Přesto, že se typ operandu jmenuje label_type, je to tentýž typ jako UID. Pokud chci tedy někam skočit, musím si získat UID cílové instrukce a pomocí něj příslušné místo olabelovat a ten label se pak použije jako operand pro instrukci skoku (doufám, že jsem to pochopil správně ).
S CALL je to ještě o něco složitější...i ta totiž jako operand drží iterátor na abstract_function reprezentující danou proceduru. Ve vygenerovaném kódu je třeba jí tam tedy podšoupnout správný iterátor na novou funkci, jenže nikde není psáno, že ho musím už znát.
Proto je generátor kódu dvouprůchodový. V 1. průchodu se vygeneruje kostra provázaných objektů, procedury budou mít vytvořený prázdný labeled_icblock (blok instrukcí).
Teprve v 2. průchodu se do nich nagenerují instrukce a správně se nasměrují volání mezi procedurami.
Uf...Snad jsem to napsal alespoň trochu srozumitelně, upřesnění či dotazy vítám...
Zbytek bychom se měli dozvědět za 14 dní.
Tak už nám to zase začíná, přeji mnoho štěstí a pevné nervy při vytváření úkolů
Předně to bude vypadat tak, že bude základní domácí úloha, kterou musí udělat všichni, chtějí-li zápočet, a pak bude možné jí různými směry rozšiřovat a za to dostávat body na zkoušku.
Základ je převést výstup, co nám generuje frontend (instrukce zásobníkového stroje) na instrukce stroje registrového. Budou opět dvě verze, bez polí a s nimi.
Zdaleka ještě nebylo vysvětleno vše, tak ještě není na čem pracovat, to se nám podaří asi až za 14 dní, teď se hlavně vysvětlila dokumentace ICM a trochu se něco řeklo o použitých datových strukturách...
Dokumentace ICM:
http://ulita.ms.mff.cuni.cz/mp/vyuka/SW ... instr.html
Grafy pro každou instrukci znázorňují, jakými mikrooperacemi se instrukce vykonává a v jakém pořadí.
Zelené krabice manipulují s registry
Červené a oranžové s pamětí
Bílé jsou nějaký výpočet
Šipky znázorňují tok dat, čísílka znamenají pořadí operandu
Každá mikrooperace nějakou dobu trvá, to načítá ICM z konfiguračního souboru a potom během vykonávání měří celkovou dobu, kterou program pracuje. Vertikální poloha krabice označuje pořadí vykonávání.
V grafu nejsou vidět všechny závislosti mezi operacemi, vlastně je tam jen tok dat, ale je třeba dát si pozor třeba na antidependence, to už je na nás.
Kostra D.Ú.:
Na internetu ještě zdrojáky nejsou, ale je tam celkem čitelná dokumentace souborů...Náš startovní bod bude funkce void mlaskal::the_rmgen(...) v souboru rmgdirect.cpp
Datové struktury:
Dokumentace je tady http://ulita.ms.mff.cuni.cz/mp/vyuka/SW ... index.html
Výchozím bodem je třída abstract_ic, která reprezentuje celý mezikód...Bude použita jak pro vstup (výstup frontendu) tak pro výstup.
Její asi nejdůležitější metoda je get_abstract_functions(), přes kterou se dostaneme k objektu třídy abstract_functions, která sdružuje všechny procedury mezikódu (tj. procedury, funkce a hlavní blok programu). Není to nic jiného než kontejner a tak se s ní také pracuje.
Jednotlivé procedury jsou reprezentovány objekty třídy abstract_function.
Odtud lze získat blok mezikódu příslušející proceduře, její parametry, návratovou hodnotu, lokální proměnné.
Důležitý je koncept UID a other_UID, které mají všechny objekty, které se v abstract_ic schovávají.
UID je zaručeně jednoznačný identifikátor a other_UID je identifikátor, který si může programátor nastavit sám. Dá se použít například k provázání zdrojové a cílové procedury, tj. z frontendu mi přilezla procedura XYZ se svým UID a já teď musím vytvořit její odpovídající sestřičku upravenou pro registrový stroj. Z důvodů, o kterých se ještě zmíním je třeba umět najít původní proceduru, která k ní patří, nabízí se tedy nastavit other_UID tohoto nového objektu na UID objektu výchozího.
Tak a teď přichází dvě nejkomplikovanější věci výkladu, na ty možná bude potřeba se mne (nebo někoho jiného) ještě doptat nad papírem...
V cílovém kódu bude potřeba mimo jiné upravovat instrukce podmíněného skoku a instrukci CALL...
Pro podmíněné skoky jsou v reg. stroji jiné instrukce než v zás. (JF - JEF, JT - JET)...Reprezentovány jsou tak, že jako operand obsahují UID instrukce, na kterou mají skočit. Přesto, že se typ operandu jmenuje label_type, je to tentýž typ jako UID. Pokud chci tedy někam skočit, musím si získat UID cílové instrukce a pomocí něj příslušné místo olabelovat a ten label se pak použije jako operand pro instrukci skoku (doufám, že jsem to pochopil správně ).
S CALL je to ještě o něco složitější...i ta totiž jako operand drží iterátor na abstract_function reprezentující danou proceduru. Ve vygenerovaném kódu je třeba jí tam tedy podšoupnout správný iterátor na novou funkci, jenže nikde není psáno, že ho musím už znát.
Proto je generátor kódu dvouprůchodový. V 1. průchodu se vygeneruje kostra provázaných objektů, procedury budou mít vytvořený prázdný labeled_icblock (blok instrukcí).
Teprve v 2. průchodu se do nich nagenerují instrukce a správně se nasměrují volání mezi procedurami.
Uf...Snad jsem to napsal alespoň trochu srozumitelně, upřesnění či dotazy vítám...
Zbytek bychom se měli dozvědět za 14 dní.
Tak už nám to zase začíná, přeji mnoho štěstí a pevné nervy při vytváření úkolů
Luk
- joshis
- Matfyz(ák|ačka) level III
- Příspěvky: 127
- Registrován: 23. 11. 2006 01:47
- Typ studia: Informatika Mgr.
- Kontaktovat uživatele:
Luku, jsi nejlepsi... Pravem Matfyzak III Urovne ... Diky moc za zadani.
Petr Dvořák
http://twitter.com/joshis_tweets
http://twitter.com/joshis_tweets
- luk
- Matfyz(ák|ačka) level II
- Příspěvky: 74
- Registrován: 6. 6. 2005 18:32
- Typ studia: Informatika Mgr.
- Bydliště: Praha
Zdravím!
Přes práci na bakalářce jsem se zatím nedostal ani k tomu, abych si prohlédl projekt, který nám byl dodán
Ale dávám sem alespoň podrobnější diagram zadání úkolu a pár poznámek k němu. Pokoušel jsem se tam hodit přímo odkazy do dokumentace, ale z nějakého důvodu to PDFCreator nevzal, tak si je tam budete muset najít sami
Když budou ještě nějaké otázky neváhejte je položit, já možná i odpovím
http://www.ms.mff.cuni.cz/~kopel4am/zad ... ladace.pdf
Sílu a čest!
Přes práci na bakalářce jsem se zatím nedostal ani k tomu, abych si prohlédl projekt, který nám byl dodán
Ale dávám sem alespoň podrobnější diagram zadání úkolu a pár poznámek k němu. Pokoušel jsem se tam hodit přímo odkazy do dokumentace, ale z nějakého důvodu to PDFCreator nevzal, tak si je tam budete muset najít sami
Když budou ještě nějaké otázky neváhejte je položit, já možná i odpovím
http://www.ms.mff.cuni.cz/~kopel4am/zad ... ladace.pdf
Sílu a čest!
Luk
- luk
- Matfyz(ák|ačka) level II
- Příspěvky: 74
- Registrován: 6. 6. 2005 18:32
- Typ studia: Informatika Mgr.
- Bydliště: Praha
První dojmy
Tak přiznejte se, už jste s tím někdo začali?
Moje první dojmy, když jsem projekt otevřel by se daly nazvat panikou a zmatkem, ale když jsem se pak trošičku zklidnil a začal přemýšlet, tak se mi to dokonce začlo i líbit Nedocenitelná věc je ToDo list v dokumentaci, bez toho bychom se v tom kódu asi přehrabovali pěkně dlouho.
Ze zdrojáků a z dokumentace jsem došel k závěru, že kopírování informací o funkcích je hotové úplně a my se v podstatě soustředíme už jen na kroky, které se dělají pro každou proceduru zvlášť.
Všechny ty fáze jsou sdružené uvnitř funktoru functor_function_generate_code, kde je všude pěkně okomentované, co a kam má přijít. Mnohdy už jsou pro to dokonce připravené funktory, jejichž vnitřek "akorát" zbývá doplnit Opět odkazuji na výše zmíněný ToDo list.
Ovšem, když stojím mezi volbou bakalářka a tohle, tak se zatím stále uchyluji spíše k bakalářce...možná, že až mi to dneska poleze ušima, mohl bych se pustit alespoň do detekce BB
Nu, tolik sbírka mých prvních dojmů z našeho domácího úkolu, snad to někomu alespoň trošičku pomůže...Když už jsem slíbil Kačce, že sem něco napíšu, nemohl jsem si dovolit slovo nedodržet a riskovat, že už nedostanu plat
Moje první dojmy, když jsem projekt otevřel by se daly nazvat panikou a zmatkem, ale když jsem se pak trošičku zklidnil a začal přemýšlet, tak se mi to dokonce začlo i líbit Nedocenitelná věc je ToDo list v dokumentaci, bez toho bychom se v tom kódu asi přehrabovali pěkně dlouho.
Ze zdrojáků a z dokumentace jsem došel k závěru, že kopírování informací o funkcích je hotové úplně a my se v podstatě soustředíme už jen na kroky, které se dělají pro každou proceduru zvlášť.
Všechny ty fáze jsou sdružené uvnitř funktoru functor_function_generate_code, kde je všude pěkně okomentované, co a kam má přijít. Mnohdy už jsou pro to dokonce připravené funktory, jejichž vnitřek "akorát" zbývá doplnit Opět odkazuji na výše zmíněný ToDo list.
Ovšem, když stojím mezi volbou bakalářka a tohle, tak se zatím stále uchyluji spíše k bakalářce...možná, že až mi to dneska poleze ušima, mohl bych se pustit alespoň do detekce BB
Nu, tolik sbírka mých prvních dojmů z našeho domácího úkolu, snad to někomu alespoň trošičku pomůže...Když už jsem slíbil Kačce, že sem něco napíšu, nemohl jsem si dovolit slovo nedodržet a riskovat, že už nedostanu plat
Luk
No ja se na to koukal a nejak nevim, kde zacit. Po prohlednuti kodu jsem dospel k mistu, kam by se podle vseho mel psat kod treba na tu detekci zakl. bloku v ramci procedury, ale jak se dostat k tem zasobnikovym instrukcim, abych je mohl presoupat do bloku, to tedy nevim. Je tam spousta ruznych template-struktur, ale mam v nich bordel, nebyl jsem za tu dobu, co jsem tomu dal, ty zasobnikove instrukce schopny najit.
- luk
- Matfyz(ák|ačka) level II
- Příspěvky: 74
- Registrován: 6. 6. 2005 18:32
- Typ studia: Informatika Mgr.
- Bydliště: Praha
Já to ještě nezkoušel, ale dle mého skromného názoru bychom měli normálně proiterovat ten icblock stack_code, co se hned na začátku toho funktoru plní voláním stack_function.get_block().
labeled_icblock je v zásadě kontejner a má metody begin a end.
EDIT: Fuj já mám teda vyjadřování! A to ještě není ani tak pozdě
labeled_icblock je v zásadě kontejner a má metody begin a end.
EDIT: Fuj já mám teda vyjadřování! A to ještě není ani tak pozdě
Luk
-
- Matfyz(ák|ačka) level I
- Příspěvky: 24
- Registrován: 6. 2. 2007 18:01
- Typ studia: Informatika Bc.
- Bydliště: Praha
Nevím jestli jste si toho všimli, ale Bednárek rozšířil dokumentaci a v sekci HOWTO se objevil celkem obsažný návod, jak udělat rozdělení do základních bloků. Chybí tam snad jen natahání hran mezi bloky.
Akorát jsem nepřišel na to, jak udělat takový ty hezký ladící výpisy, abych si mohl ověřit, že můj kód dělá něco rozumnýho. Nevíte někdo jak na to?
BTW funguje vám MLC (z public-bin)?
Akorát jsem nepřišel na to, jak udělat takový ty hezký ladící výpisy, abych si mohl ověřit, že můj kód dělá něco rozumnýho. Nevíte někdo jak na to?
BTW funguje vám MLC (z public-bin)?