V tejto kapitole sme sa poskytnúť čitateľovi prehľad o vnútornej štruktúre prekladateľov, a nejakú predstavu o tom, ako sú klasifikovaní.
Prekladateľ môže byť formálne definovaná ako funkcia, ktorého doména je zdrojový jazyk, a ktorého rozsah je obsiahnutá v objekte alebo cieľového jazyka.
Zdrojový jazyk ---------> Translator ---------> Cieľový jazyk
návod na obsluhu
Málo skúseností s prekladateľmi ukáže, že to je len zriedka považovaná za súčasť prekladateľa funkciu vykonať algoritmus vyjadrený zdroje, iba k zmene jeho zastúpenie z jednej formy do druhej. V skutočnosti, sú najmenej v troch jazykoch podieľa na rozvoji prekladateľa: zdrojový jazyk k prekladu, objekt alebo cieľového jazyka, ktoré vzniknú, a jazyk hostiteľskej krajiny, ktorý bude použitý na realizáciu prekladateľa. Ak preklad prebieha v niekoľkých fázach, môže byť aj iná, stredná, jazyky. Väčšina z nich - a naozaj, jazyk hostiteľskej krajiny a objekt jazyky sám - zvyčajne zostávajú skryté pred užívateľom z predvoleného jazyka.
2.1 T-diagramy
Užitočné notácie pre opis počítačový program, zvlášť prekladateľa, používa tzv T-diagramy, príklady, ktoré sú zobrazené na obrázku 2.1.
.-------------------------------------------------------.
| Názov programu |
|dátové vstupy ----------------> dátové výstupy |
| |
`------------------. .------------------'
| implementácia |
| jazyk |
`-----------------'
.-------------------------------------------------------.
| Prekladateľ Názov |
| zdrojový jazyk -------------------> cieľový jazyk |
| |
`------------------. prekladateľ .------------------'
| Hostiteľ |
| Jazyk |
`-----------------'
.-------------------------------------.
| TPC.EXE |
| Turbo Pascal -------> 8086 M-code |
| |
`----------. .----------'
| 8086 M-code |
| |
`---------------'
Obrázok 2.1 T-diagramy. (A) Všeobecný program (b) všeobecný tlmočník
(C) Turbo Pascal kompilátor pre MS-DOS systému
Budeme používať notáciu "M-kód" štát "strojového kódu" v týchto diagramoch. Preklad sám je zastúpená stojí na T na počítači, a umiestnenie zdrojový program a objektový program na ľavej a pravej ruky, ako je znázornené na obrázku 2.2.
.-------------------------------------.
| TPC.EXE |
PROG.PAS | Turbo Pascal ---------> 8086 M-code | PROG.EXE
| |
`----------. .----------'
| 8086 M-code |
| |
`---------------'
.---------------.
| 80x86 Machine |
`---------------'
Obrázok 2.2 A Turbo Pascal kompiláciu na 80x86 počítači
Môžeme tiež pozorovať tento osobitný kombinácia ako líčiť abstraktné stroj (niekedy nazývané virtuálny stroj), ktorého cieľom v živote je previesť Turbo Pascal zdrojové programy do svojich 8086 ekvivalenty strojového kódu.
T-diagramy boli najprv predstavil Bratman (1961). Tieto boli ďalej zdokonalená Earley a Sturgis (1970), a sú tiež použité v knihách Bennett (1990), Watt (1993), a Aho, Sethi a Ullman (1986).
2.2 Triedy prekladateľa
To je obyčajné rozlišovať medzi niekoľkými zavedenými tried prekladateľa:
- Termín assembler je obvykle spájaný s týmito prekladateľmi, ktoré mapujú low-level jazyka inštrukcie do strojového kódu, ktorý potom môže byť spustený priamo. Jednotlivé príkazy source jazyk zvyčajne mapovanie one-pre-jeden na zariadenia na úrovni inštrukcií.
- Termín makro-assembler je tiež spájaný s týmito prekladateľmi, ktoré mapujú low-level jazyka inštrukcie do strojového kódu, a je variáciou na vyššie uvedené. Väčšina zdrojového jazyka závierka mapa one-pre-jeden do ich ekvivalentov cieľového jazyka, ale niektoré makro príkazy mapovať do slede stroj na úrovni inštrukcií - efektívne poskytovať textové náhradné zariadenia, a tým rozširuje jazyk symbolických inštrukcií, aby vyhovoval užívateľovi. (To nemá byť zamieňaná s použitím postupov alebo iných podprogramy na "predĺženie" vysokoúrovňové jazyky, pretože spôsob prevedenia je zvyčajne veľmi odlišné.)
- Termín Kompilátor je obvykle spájaný s týmito prekladateľmi, ktoré mapujú na vysokej úrovni jazykové pokyny do strojového kódu, ktorý potom môže byť spustený priamo. Jednotlivé príkazy source jazyk zvyčajne mapujú do mnohých zariadení na úrovni inštrukcií.
- Termín pre-procesor je obvykle spájaný s týmito prekladateľmi, ktoré mapujú množinu vysokej úrovni jazyka do pôvodného vysokej úrovni jazyka, alebo že vykonávanie jednoduchých textových substitúciou pred prekladom koná. Best-known pre-procesor je pravdepodobne ten, ktorý tvorí neoddeliteľnú súčasť implementácie jazyka C, a ktorá poskytuje mnoho funkcií, ktoré prispievajú k široko zdieľaný názor, že C je jediný naozaj prenosný jazyk.
- Termín na vysokej úrovni prekladateľ je často spájaný s týmito prekladateľmi, ktoré mapovať jednu na vysokej úrovni jazyka do iného jazyka vyššej úrovne - zvyčajne jeden, pre ktoré sofistikované prekladača už existujú v rade strojov. Takéto prekladatelia sú obzvlášť užitočné ako zložky dvojstupňového zostavovaní systému, alebo pri pomoci s Bootstrapping techniky na prerokovanie krátko.
- Podmienky Decompiler a disassembler odkazujú na prekladateľov, ktoré sa snažia, aby objektového kódu na nízkej úrovni a regeneráciu zdrojový kód na vyššej úrovni. Aj keď to môže byť robené celkom úspešne pre výrobu kódu na úrovni assembleri, je to oveľa ťažšie, keď sa človek snaží obnoviť zdrojový kód pôvodne napísaný, povedzme, Pascal.
Mnoho prekladatelia generovať kód pre ich hostiteľských počítačoch. Jedná sa o tzv self-rezidentmi prekladatelia. Iní, známe ako cross-prekladateľov, generovať kód pre stroje iné ako v hostiteľskom počítači. CROSS-prekladatelia sú často používané v súvislosti s mikropočítaču, najmä vo vstavaných systémoch, ktoré môžu samy o sebe byť príliš malá, aby self-rezidentmi prekladateľa uspokojivo fungujú. Samozrejme, cross-preklad zavádza ďalšie problémy v súvislosti s prevodom objektový kód z darcovského stroja k stroju, ktorý je na vykonanie preložený programu, a môže viesť k oneskoreniu a frustrácie v programe rozvoja.
Výstup niektorých prekladateľov je absolútna strojovom kóde, ponechané v zaťaženom v pevných miestach v zariadení je pripravená na okamžité prevedenie. Ostatné prekladatelia, známe ako load-and-go prekladateľov, môže dokonca iniciovať spustenie tohto kódu. Avšak, veľké množstvo prekladateľov nevytvára pevnú adresu strojový kód. Trochu, oni produkujú niečo, čo úzko podobné na to, známy ako semicompiled alebo binárne symbolické alebo premiestniteľná forme. Pri častom používaní je to vo vývoji kompozitných knižníc špeciálnych účelových rutín, možno pochádzajúce zo zmesi zdrojových jazykov. Rutiny zostavené týmto spôsobom sú prepojené programy tzv zdvih editory alebo linker, ktoré môžu byť považované takmer za poskytnutie konečnej fáze pre viacstupňového prekladateľ. Jazyky, ktoré podporujú samostatné zostavovanie častí programu - ako Modula-2 a C + + - závisí kriticky na existenciu takých linker, ako čitateľ je nepochybne vedomý. Pre vývoj naozaj veľké softvérové projekty tieto systémy sú neoceniteľné, keď pre druh "vyhodiť" programy, na ktoré väčšina študentov znížiť svoje zuby, môžu spočiatku zdajú byť na obtiaž, pretože režijných trov konania niekoľko súborov, a Čas potrebný k prepojeniu ich obsah spolu.
T-diagramy môžu byť kombinované ukázať previazanosť nakladače prekladateľov, a tak ďalej. Napríklad, FST Modula-2 systém umožňuje použitie kompilátora a linker, ako je znázornené na obrázku 2.3.
.-----------------------------.
| M2COMP.EXE | ---------.
PROG.MOD | Modula-2 --------> m2o code | PROG.M2O |
| | |
`---------. .---------' |
| 8086 | |
| M-code | |
`---------' |
.--------------------------------'
| .-----------------------------.
`----->| M2LINK.EXE |
knižnica ---->| m2o code ----> 8086 M-code | PROG.EXE
| |
`---------. .---------'
| 8086 |
| M-code |
`---------'
Obrázok 2.3 Kompilácia a prepojenie Modula-2 program na FST systému
cvičenie
2,1 Urobte si zoznam čo najviac prekladateľov, ako si môžete myslieť, že je možné nájsť na vašom systéme.
2.2 Ktoré z prekladateľov pred tebou sú zaťažení-a-go typu?
2.3 Viete, či niektorý z prekladateľov použiť vyrábať premiestniteľné kód? Je to o štandardnej forme? Poznáte mená zdvih editory alebo nakladače použité na vašom systéme?
2.4 Existujú nejaké pre-procesory na vašom systéme? Čo sú použité pre?
2.3 Fáza v preklade
Prekladatelia sú veľmi zložité programy, a to je nerozumné považovať procesu prekladu ako vyskytujúce sa v jedinom kroku. Je obvyklé, že sa považujú za rozdelená do niekoľkých fáz. Najjednoduchšie členenie uznáva, že je analytický fáza, v ktorej sa zdrojový program zisťuje sa, či spĺňa syntaktickej a statické sémantické obmedzenia vyplývajúce jazyka. Potom nasleduje syntetického fáza, v ktorej sa zodpovedajúce objekt kód generovaný v cieľovom jazyku. Súčasti prekladateľa, ktorý rieši práve tieto dve hlavné fázy sú povedal, aby zahŕňal predný koniec a zadný koniec kompilátora. Predný koniec je do značnej miery nezávislý na cieľovom počítači, zadný koniec závisí veľmi silne na cieľovom počítači. V rámci tejto štruktúry môžeme rozpoznať menšie komponenty alebo fázy, ako je znázornené na obr 2.4.
zdrojový kód
|
|
|
.- Tabuľka handler (non-portable) ----.
| | |
| | |
| | |
Analytický | .-------lexikálny analyzátor------------|
fázy | | (Skener) |
| | | |
| | | |
(Front end) | |-------- Syntax analyzátor------------|
| | (Parser) |
| | | |
| | | |
| Tabuľka --+------- obmedzenie analyzátor-----------+-- chyba
`- psovod | (Statický sémantickej analyzátor) | reportér
| | |
.- | | |
| |-- strednej generátor kódu ------|
| | | |
| | | |
| | | |
Synthetic | `--------- kód optimizer ------------|
phase | | |
| | |
| | |
(späť koniec) | generátor kódu (non-portable) ------'
| |
| |
| |
`- Kukátko optimizer (non-portable)
|
|
objektový kód
Obrázok 2.4 Štruktúra a fázy prekladača
Charakter handler je časť, ktorá komunikuje s vonkajším svetom, prostredníctvom operačného systému, čítať v znakoch, ktoré tvoria zdrojový text. Ako znakovej sady súborov a manipulácia sa líši systém od systému, táto fáza je často stroj alebo operačný systém závislý.
Lexikálny analyzátor alebo skener časť, ktorá spája znaky zdrojového textu do skupín, ktoré logicky tvorí tokeny jazyka - symboly ako identifikátory, struny, číselné konštanty, kľúčové slová ako pri, a ak operátori ako <=, a tak ďalej . Niektoré z týchto symbolov sú veľmi jednoducho zastúpené na výstupe z skenera, niektoré sa byť spojené s rôznymi vlastnosťami, ako je ich mien alebo hodnôt.
Lexikálne analýza je niekedy ľahké, a inokedy nie. Napríklad, Modula-2 vyhlásenie
WHILE A > 3 * B DO A := A - 1 END
ľahko dekóduje do žetóny
WHILE keyword
A identifier name A
> operator comparison
3 constant literal value 3
* operator multiplication
B identifier name B
DO keyword
A identifier name A
:= operator assignment
A identifier name A
- operator subtraction
1 constant literal value 1
END keyword
ako sme si to zľava doprava, ale vyhlásenie Fortran
10 DO 20 I = 1 . 30
nie je tak klamné. Čitatelia oboznámenie s Fortran mohol vidieť to ako dekódovanie do
10 label
DO keyword
20 statement label
I INTEGER identifier
= assignment operator
1 INTEGER constant literal
, separator
30 INTEGER constant literal
zatiaľ čo tí, ktorí majú zvrátenosť by si prial, aby to, ako to naozaj je:
10 label
DO20I REAL identifier
= assignment operator
1.30 REAL constant literal
Človek sa musí pozerať docela ťažké rozlíšiť obdobie od "očakávaného" čiarkou. (Priestory sú irelevantné vo FORTRAN,. Jeden by, samozrejme zvrátené používať identifikátory zbytočnými a veľmi sugestívne priestor v nich) Kým jazyky ako Pascal, Modula-2 a C + + sú šikovne navrhnuté tak, aby lexikálny analýza môže byť jasne oddelené od zvyšok analýzy, to isté samozrejme nie je pravda, Fortran a ďalšie jazyky, ktoré nemajú vyhradené kľúčové slová.
Syntax analyzátor alebo analyzátor skupiny tokeny produkovanej skenerom do syntaktických štruktúr - ktoré to robí pri analýze výrazov a príkazov. (Toto je analogické k človeku analýzy trest nájsť komponenty, ako "predmet", "objekt" a "vedľajších viet"). Často parser je v kombinácii s kontextovú obmedzujúcimi analyzátora, ktorého úlohou je určiť, že zložky v syntaktických štruktúr uspokojiť také veci ako je rozsah pôsobnosti pravidiel a typu pravidiel v rámci štruktúry v súčasnej dobe analyzujú. Napríklad, v roku Modula-2 je syntax while niekedy popisovaný ako
WHILE Vyjadrenie DO StatementSequence END
Je rozumné uvažovať o vyhlásenie vo vyššie uvedenom formulári s akýmkoľvek typom prejavu ako bytia syntakticky správny, ale ako obyčajný skutočný význam, ak hodnota výrazu je obmedzený (v tomto kontexte) k byť Boolean typu. Žiadny program naozaj nemá zmysel, kým je spustený dynamicky. Avšak, to je možné, sa silno skriptovacími jazyky predvídať pri kompilácii, že niektoré zdroje programy môžu mať žiadny rozumný zmysel (to znamená, že staticky, ako je vykonaný pokus o spustenie programu dynamicky). Sémantika je termín používaný na opis "význam", a tak obmedzenie analyzátor je často nazývaný statickú sémantický analyzátor, alebo jednoducho sémantickej analyzátor.
Výstup syntaxe analyzátora a sémantických analyzátora fáza je niekedy vyjadrené v podobe zdobené abstraktné syntaktickú strom (AST). To je veľmi užitočné reprezentácia, ako to môže byť použitý v chytrých spôsobov pre optimalizáciu generovanie kódu v neskoršej fáze.
Vzhľadom k tomu, betón syntaxe mnohých programovacích jazykov obsahuje mnoho kľúčových slov a žetóny, abstraktné syntax je trochu jednoduchšie, zachovanie len tie zložky jazyka potrebné zachytiť skutočný obsah a (nakoniec) zmysel programu. Napríklad, zatiaľ čo betón syntaxe while vyžaduje prítomnosť WHILE, DO a END, ako je uvedené vyššie, základné súčasti while sú jednoducho (Boolean) Vyjadrenie a vyhlásenie tvoriace StatementSequence.
Tak Modula-2 Vyhlásenie
WHILE (1 <P) A (P <9) DO P: = P + Q END
alebo jeho C + + ekvivalent
while (1 <P && P <9) P = P + Q;
sú oba líčenie spoločnú AST je znázornené na obr 2.5.
| (WhileStatement)
|
(výraz) .---------------------------------------. (úloha)
| |
| |
(faktor) .- disjunkcia -. (faktor) (označenie) .-- priradiť --. (výraz)
| | | |
| | | |
.-- < --. .-- < --. | .--- + ----.
| | | | | | |
| | | | | | |
1 P P 9 P P Q
Obrázok 2.5 AST pre vyhlásenie while (1 <P && P <9) P = P + Q;
Abstraktné syntaktickú strom na jeho vlastné chýba nejaké sémantické informáciu, sémantickej analyzátor má za úlohu doplniť "typ" a ďalšie kontextové informácie pre rôzne uzly (od tejto doby termín "vyzdobené" strom).
Niekedy, ako napríklad v prípade väčšiny Pascal kompilátorov, výstavba takého stromu nie je explicitný, ale zostáva implicitné v rekurzívne volanie procedúr, ktoré vykonávajú syntax a sémantickej analýzy.
Samozrejme, že je tiež možné zostaviť konkrétny syntaktické stromy. Modula-2 forma vyhlásenie
WHILE (1 <P) A (P <9) DO P: = P + Q END
môže byť opísaný v plnom a zdĺhavý podrobne stromu je znázornené na obr 2.6. Čitateľ môže mať, aby sa odkaz na Modula-2 syntaktické diagramy a znalosti Modula-2 pravidlá prednosť pochopiť, prečo strom vyzerá tak zložité.
vyhlásenie
|
|
WhileStatement
|
.-----------------------+-------------------------.
| | | | |
WHILE výraz DO vyhlásenie Sequence koniec
| |
| vyhlásenie
| |
| úloha
| |
SimpleExpression .--------+--------.
| | | |
| premenlivý := výraz
| | |
termín identifikátor (P) SimpleExpression
| |
.------------+-----------. .------+------.
| | | | | |
faktor koniec faktor termín + termín
| | | |
.-------+--------. .-------+-------. | |
| | | | | | faktor faktor
( výraz ) ( výraz ) | |
| | | |
| | Identifier (P) Identifier (Q)
| |
| `-------------.
.------------+--------. .-----------+--------.
| | | | | |
SimpleExpression < SimpleExpression SimpleExpression < SimpleExpression
| | | |
| | | |
termín termín termín termín
| | | |
| | | |
faktor faktor Faktor Faktor
| | | |
| | | |
číslo (1) identifikátor (P) identifikátor (P) číslo (9)
Obrázok 2.6 betón syntaktickú strom pre vyjadrenie
WHILE (1 <P) A (P <9) DO P: = P + Q END
Jednotlivé fázy práve hovoril, sú všetky analytické v prírode. Tie, ktoré nasledujú, sú viac syntetické. Prvý z nich môže byť prechodný generátor kódu, ktorý sa v praxi, môže byť prepojený s predchádzajúcich fázach, alebo vynechaná v prípade niektorých veľmi jednoduchých prekladateľov. Využíva dátové štruktúry vyrobené z predchádzajúcich fázach tvoriť formu kódu, napríklad vo forme jednoduchých kódov kostier alebo makrá, alebo assembler alebo dokonca na vysokej úrovni kódu pre spracovanie externým Assembler alebo samostatného kompilátora. Hlavný rozdiel medzi mezikódu a skutočným strojovom kóde je skutočnosť, že stredná kód nemusí podrobne špecifikovať veci ako presný stroj registre ktoré majú byť použité, presné adresy potrebné vziať do úvahy, a tak ďalej.
Náš príklad vyhlásenia
WHILE (1 <P) A (P <9) DO P: = P + Q END
môže priniesť mezikódu, čo zodpovedá
L0 if 1 < P goto L1
goto L3
L1 if P < 9 goto L2
goto L3
L2 P := P + Q
goto L0
L3 continue
Potom znova, mohlo by to vytvoriť niečo ako
L0 T1 := 1 < P
T2 := P < 9
if T1 and T2 goto L1
goto L2
L1 P := P + Q
goto L0
L2 continue
v závislosti na tom, či realizátora prekladateľa používajú tzv sekvenčné spojku alebo skratu prístup k riešeniu zložené logické výrazy (ako v prvom prípade) alebo tzv logický operátor prístup. Čitateľ si spomenie, že Modula-2 a C + + vyžadujú skratu prístup. Avšak, veľmi podobné jazyk Pascal sa neuvádza, že jeden prístup prednosť nad sebou.
Kód optimalizátor môže voliteľne byť, v snahe zlepšiť sprostredkujúca kód v záujme rýchlosti alebo priestoru alebo oboje. Ak chcete použiť rovnaký príklad ako predtým, by zrejmé, optimalizácia viedlo k kódovanie zodpovedá
L0 if 1 ³ P goto L1
if P ³ 9 goto L1
P := P + Q
goto L0
L1 continue
Najdôležitejšie fázy v back-end je zodpovednosťou generátor kódu. V reálnom kompilátor táto fáza trvá výstup z predchádzajúcej fázy a vytvára objektový kód, rozhodovanie o umiestnení pamäte pre dáta, generovanie kódu pre prístup takých miest, výber registrov pre stredne pokročilých výpočty a indexovanie, a tak ďalej. Je zrejmé, je to fáza, ktorá si vyžaduje veľa zručnosti a dôrazom na detail, v prípade, že hotový výrobok má byť vôbec účinné. Niektorí prekladatelia ísť na ďalšiu fázu začlenením tzv kukátkom optimalizátora, v ktorých sú pokusy o zníženie zbytočné operácie ešte viac tým, že skúma krátke sekvencie z generovaného kódu v podrobnejšie.
Nižšie uvádzame zoznam skutočný kód vygenerovaný rôznych MS-DOS kompilátory pre toto tvrdenie. Je úplne evidentné, že fáza generovanie kódu v týchto kompilátorov sú výrazne odlišné. Tieto rozdiely môžu mať hlboký vplyv na veľkosti programu a rýchlosť implementácie.
Borland C++ 3.1 (47 bytes) Turbo Pascal (46 bytes)
(with no short circuit evaluation)
CS:A0 BBB702 MOV BX,02B7 CS:09 833E3E0009 CMP WORD PTR[003E],9
CS:A3 C746FE5100 MOV WORD PTR[BP-2],0051 CS:0E 7C04 JL 14
CS:A8 EB07 JMP B1 CS:10 B000 MOV AL,0
CS:AA 8BC3 MOV AX,BX CS:12 EB02 JMP 16
CS:AC 0346FE ADD AX,[BP-2] CS:14 B001 MOV AL,1
CS:AF 8BD8 MOV BX,AX CS:16 8AD0 MOV DL,AL
CS:B1 83FB01 CMP BX,1 CS:18 833E3E0001 CMP WORD PTR[003E],1
CS:B4 7E05 JLE BB CS:1D 7F04 JG 23
CS:B6 B80100 MOV AX,1 CS:1F B000 MOV AL,0
CS:B9 EB02 JMP BD CS:21 EB02 JMP 25
CS:BB 33C0 XOR AX,AX CS:23 B001 MOV AL,01
CS:BD 50 PUSH AX CS:25 22C2 AND AL,DL
CS:BE 83FB09 CMP BX,9 CS:27 08C0 OR AL,AL
CS:C1 7D05 JGE C8 CS:29 740C JZ 37
CS:C3 B80100 MOV AX,1 CS:2B A13E00 MOV AX,[003E]
CS:C6 EB02 JMP CA CS:2E 03064000 ADD AX,[0040]
CS:C8 33C0 XOR AX,AX CS:32 A33E00 MOV [003E],AX
CS:CA 5A POP DX CS:35 EBD2 JMP 9
CS:CB 85D0 TEST DX,AX
CS:CD 75DB JNZ AA
JPI TopSpeed Modula-2 (29 bytes) Stony Brook QuickMod (24 bytes)
CS:19 2E CS: CS:69 BB2D00 MOV BX,2D
CS:1A 8E1E2700 MOV DS,[0027] CS:6C B90200 MOV CX,2
CS:1E 833E000001 CMP WORD PTR[0000],1 CS:6F E90200 JMP 74
CS:23 7E11 JLE 36 CS:72 01D9 ADD CX,BX
CS:25 833E000009 CMP WORD PTR[0000],9 CS:74 83F901 CMP CX,1
CS:2A 7D0A JGE 36 CS:77 7F03 JG 7C
CS:2C 8B0E0200 MOV CX,[0002] CS:79 E90500 JMP 81
CS:30 010E0000 ADD [0000],CX CS:7C 83F909 CMP CX,9
CS:34 EBE3 JMP 19 CS:7F 7CF1 JL 72
Tlmočník nevyhnutne využíva komplexné dátové štruktúry, známy ako symbol tabuľke, v ktorej sa udržiava informácie o mená používala programu, a súvisiace vlastnosti pre tieto, ako ich druhu, a ich skladovanie požiadavkách (v prípade, že premenné), alebo ich hodnoty (v prípade, že konštánt).
Ako je dobre známe, užívatelia vysokoúrovňové jazyky sú schopné robiť veľa chýb vo vývoji aj celkom jednoduchých programov. Tak rôzne fázy prekladača, najmä tie predchádzajúce, aj komunikovať s obslužná rutina chýb a chýb reportér, ktoré sú vyvolaná pri zistení chyby. Je žiaduce, aby zostavenie chybných programov pokračovať, pokiaľ je to možné, aby sa užívateľ môže čistiť niekoľko chýb z zdroja pred rekompilace. To vyvoláva veľmi zaujímavé otázky týkajúce sa konštrukcie zotavenie po chybe a techniky pre opravu chýb. (Hovoríme o zotavenie po chybe, kedy proces prekladu sa pokúsi pokračovať v po zistení chyby, a opravy chýb alebo chyby opravy pri pokuse opraviť chybu z kontextu - zvyčajne sporné predmet, pretože oprava môže byť nič ako to, čo programátor mal pôvodne na mysli.)
Detekcia chýb pri kompilácii v zdrojovom kóde nesmie zamieňať s detekciou chýb za behu pri vykonávaní strojového kódu. Mnoho kód generátory sú zodpovedné za pridanie kontroly chýb kód objektu programu (pre kontrolu, že indexy pre polia zostať v medziach, napríklad). To môže byť pomerne primitívne, alebo to môže znamenať pridávanie značné kód a dátové štruktúry pre použitie s sofistikované ladenie systému. Takéto vedľajšie kód môže výrazne znížiť účinnosť programu, a niektoré kompilátory aby mohla byť potlačená.
Niekedy chyby v programe, ktoré sú zistené pri kompilácii sú známe ako chyby, a chyby, ktoré sa objavia pri spustení sú známe ako výnimky, ale nie je tam žiadna všeobecne dohodnutá terminológie pre tento.
Obrázok 2.4 zdá vyplývať, že kompilátory pracovať sériovo, a že každá fáza komunikuje s ďalšou pomocou vhodného medziľahlé jazyka, ale v praxi sa rozdiel medzi jednotlivými fázami sa často stáva trochu rozmazaný. Navyše, mnoho kompilátorov vlastne postavený okolo centrálneho analyzátora ako dominantné zložky, sa štruktúrou skôr ako jeden v obr 2.7.
.----------------.
| | (vyrába)
zdrojový kód ------> | zdroj Handler |--------------> zdroj Výpis
| | Error Výpis
`----------------'
(vyrába)
(bude volať) |
| |
.---------------------. .----------------------.
| | (môžu volať) | |
|lexikálny analyzátor |---------------->| chyba Reporter |
| | .---------->| |
`---------------------' | `----------------------'
|
(bude volať) (môžu volať) (môžu volať)
| | |
.-----------------------------. .----------------.
| | (will call) | |
|Syntax/Sémantický analyzátor |-------------->| Code Generator |
| | | |
`-----------------------------' `----------------'
¯
objektový kód
Obrázok 2.7 Štruktúra parser-nariadil kompilátor
Cvičenie
2.5 Aké problémy môžete predvídať Fortran kompilátor, ktorý má v analýze výkazov počnúc
IF ( I(J) - I(K) ) ........
CALL IF (4 , ...........
IF (3 .EQ. MAX) GOTO ......
100 FORMAT(X3H)=(I5)
2.6 Aké kódu by ste vyrába keby ste boli kódovanie vyhlásenie ako "WHILE (1 <P) A (P <9) DO P: = P + Q END" do vášho obľúbeného assembleri?
2.7 Nakreslite konkrétnu syntaktickú strom pre C + + verzia while slúži pre ilustráciu v tejto časti.
2.8 Existujú nejaké dôvody, prečo by skrat hodnotenie je prednostné cez logický operátor prístupu? Spomeniete si na všetky algoritmy, ktoré bude závisieť kriticky, na ktorých prístup bol prijatý?
2.9 Zapíšte niekoľko ďalších high-úrovni konštrukcia a skúste si predstaviť, aký assembler-ako strojového kódu kompilátor by vyrábajú pre ne.
2.10 Čo myslíte, že je to relatívne jednoduché zostaviť Pascal? Spomeniete si na všetky aspekty Pascal ktoré by mohli preukázať naozaj ťažké?
2.11 sme použili dva nedefinované pojmy, ktoré na prvý pohľad zdajú byť zameniteľné, a to "oddelené" a "nezávislé" kompilácie. Pozrite sa, či môžete zistiť, aké rozdiely sú.
2.12 Mnoho vývojové systémy - najmä ladiaci - umožňujú užívateľovi skúmať objektový kód produkovaný kompilátora. Ak máte prístup k jednému z nich, skúste napísať niekoľko veľmi jednoduchých (jeden príkaz) programy, a pozrieť sa na druh objektu kódu, ktorý je generovaný pre nich.
2.4 Multi-fáza prekladatelia
Okrem toho, že koncepčne rozdelená do niekoľkých fáz, sú prekladatelia často rozdelené do priechodov, v každom z nich môže byť niekoľko fáz byť kombinované alebo prekladané. Tradične, priechod číta zdrojový program, alebo výstup z predchádzajúceho priechodu, robí nejaké transformácie, a potom zapíše výstup na strednej súboru, odkiaľ môže znovu naskenovať v nasledujúcom priechodu.
Tieto fázy môžu byť riešené rôznymi integrovanými časťami jedného kompilátora, alebo môžu byť spracované spustenia dvoch alebo viacerých oddelených programov. Môžu komunikovať pomocou svojej vlastnej špecializované formy medziľahlé jazyka, môže oznámiť využitím interných dátových štruktúr (skôr než súborov), alebo sa môžu vytvoriť niekoľko priechodov v rovnakom pôvodnej zdrojový kód.
Počet použitých priechodov závisí od mnohých faktorov. Niektoré jazyky vyžadujú aspoň dva priechody byť vykonaná, ak kód sa generuje ľahko - napríklad tie, kde vyhlásenie identifikátorov môže dôjsť po prvom odkazom na identifikátor, alebo kde môžu vlastnosti spojené s identifikátorom nedajú ľahko odvodiť z kontextu , v ktorom sa na prvý pohľad zdá. Multi-pass kompilátor môže často ušetriť miesto. Hoci moderné počítače sú zvyčajne obdarení oveľa viac pamäte ako ich predchodcovia z niekoľkých málo rokov späť, môže byť viac priechody byť dôležitým faktorom, pokiaľ si niekto želá preložiť zložité jazyky v medziach malých systémov. Multi-priepustu prekladača môžu taktiež umožniť lepšie poskytovanie optimalizácia kódu, hlásenie chýb a chýb. Konečne, sa to hodí do tímu vývoja, s rôznymi členmi tímu za prevzatie zodpovednosti za rôzne priechody. Avšak, multi-pass kompilátory sú zvyčajne pomalší ako single-pass ty, a ich pravdepodobné potreba sledovať z niekoľkých súborov, z nich robí ľahko trápne písať a používať. Kompromisy v projekčnej fáze často vyústi v jazykoch, ktoré sú dobre prispôsobené jednopriechodové kompilácie.
V praxi, je značná využitie dvojstupňového prekladateľov, v ktorom prvej fáze je na vysokej úrovni, prekladateľ, ktorý prevádza zdrojový program do assembleri, alebo dokonca do inej relatívne vysokej úrovni jazyka, pre ktorý účinný tlmočník už existuje. Proces kompilácie by sa potom predstavovaný ako na obrázku 2.8 - náš príklad ukazuje Modula-3 programu sa pripravuje na spustenie na počítači, ktorý má Modula-3 na C: Konvertor:
.-------------------------. .-------------------------.
| M3toC.M |--------->| CtoM.M |
PROG.M3 | Modula-3 --------> C | PROG.C | C ---------> M-kód | PROG.M
| | | |
`-------. .-------' `-------. .-------'
| | | |
| M-kód | | M-kód |
`---------' `---------'
.---------. .---------.
|M-stroj | |M-stroj |
`---------' `---------'
Obrázok 2.8 Kompilácia Modula-3 pomocou C ako medziprodukt jazyk
To je zvýšene obyčajné nájsť kompilátory pre vysokoúrovňové jazyky, ktoré boli realizované s využitím C a ktoré sami vyrábame C kód ako výstup. Úspech z nich je založený na mieste, ktoré "prichádzajú všetky moderné počítače, ktoré sú vybavené kompilátor C" a "zdrojový kód napísaný v C je skutočne prenosný". Ani predpoklad je, bohužiaľ, úplne pravda. Avšak, prekladača písané týmto spôsobom sú tak blízko k dosiahnutiu sen sami je prenosný všetky zmeny, ktoré existujú v súčasnej dobe. Spôsob, akým môžu byť tieto prekladača byť použité je diskutovaná ďalej v kapitole 3.
Cvičenie
2,13 Pokúste sa zistiť, ktorý z kompilátorov ste použili, sú jedno-pass, a ktoré sú multi-pass, a pre druhú, zistiť, koľko priechodov sú zapojené. Ktoré produkujú premiestniteľná kód potrebujú ďalšie spracovanie linker alebo tiahla redaktorov?
2.14 Vykonajte niektorú z kompilátorov používa na vašom assembleri systému potravinársky, C alebo iného kódu počas procesu kompilácie? Môžete predvídať žiadne konkrétne problémy, ktoré užívatelia môžu nastať pri použití týchto kompilátory?
2.15 Jedným z niekoľkých prekladačov, ktoré prekladá z Modula-2 na C sa nazýva MTC, a je voľne dostupný z niekoľkých ftp. Ak ste Modula-2 programátor, získať kópiu, a experimentovať s ním.
2,16 vynikajúci kompilátor, ktorý prekladá Pascal a C sa nazýva P2C, a je široko dostupný pre unixové systémy z niekoľkých ftp. Ak ste programátor Pascal, získať kópiu, a experimentovať s ním.
2,17 Dokážete predvídať nejaké praktické problémy pri používaní C ako medziprodukt jazyk?
2.5 Tlmočníci, interpretačné prekladača, a emulátory
Spracovatelia druhu, ktoré sme diskutovali majú niekoľko vlastností, ktoré môžu byť okamžite zrejmé. Po prvé, sa obvykle zameriavajú na vytváranie strojového kódu, ktorý môže pracovať v plnej rýchlosti v cieľovom počítači. Po druhé, oni sú zvyčajne usporiadané zostaviť celú časť kódu pred nič z toho môže byť popravený.
V niektorých interaktívnych prostrediach potreby pre systémy, ktoré môžu vykonať časť aplikácie bez nutnosti pripravovať všetko, alebo tie, ktoré umožňujú užívateľovi meniť jeho alebo jej priebeh akcie v reálnom čase. Typické scenáre zahŕňajú použitie tabuliek, on-line databázy, alebo dávkové súbory alebo Shell skripty pre operačné systémy. S týmito systémami môže byť možné (alebo dokonca žiaduce) k výmene niektoré z výhod rýchlosti prevedení pre výhodou získavať výsledky na požiadanie.
Systémy, ako sú tieto, sú často konštruované tak, aby sa využiť služby tlmočníka. Interpret je prekladač, ktorý účinne prijíma zdrojový program a spustí ho priamo, bez toho, aby zdanlivo, výrobu ľubovoľnej objektový kód ako prvý. Je to tým, načítanie návod source program jeden po druhom, analýzy je jeden po druhom, a potom "prevedení" jedného po druhom. Je zrejmé, že systém ako je tento, ak je to, aby bola úspešná, umiestňuje niektoré docela vážne obmedzenia na povahe zdrojového programu. Komplexné programové štruktúry, ako sú vnorené postupy alebo kŕmnych vyhlásenie nepožičiavajú seba ľahko k takému zaobchádzaniu. Na druhej strane, možno-line otázky vyrobené z databázy, alebo jednoduché manipulácia riadku alebo stĺpca z tabuľky zaobchádzať veľmi efektívne.
Táto myšlienka je vyčerpané pomerne oveľa ďalej vo vývoji niektorých prekladateľov vysokoúrovňové jazyky, známy ako interpretačné prekladača. Takéto prekladatelia produkujú (ako výstup) sprostredkujúcej kód, ktorý je vnútorne natoľko jednoduchý, aby spĺňali obmedzenia vyplývajúce z praktického tlmočníka, aj keď to môže ešte byť docela ďaleko od strojového kódu systému, na ktorom je požadované vykonať originál program. Skôr než pokračovať preklad na úroveň strojového kódu, alternatívny prístup, ktorý môže vykonávať prijateľne dobre, je použiť sprostredkujúci kód ako súčasť vstupu do špeciálne písomného tlmočníka. To zase "vykoná" pôvodné algoritmus, pomocou simulácie virtuálny stroj pre ktoré strednej kód účinne je strojový kód. Rozdiel medzi strojového kódu a pseudo-kódu prístupy k realizácii je zhrnutý v grafe 2.9.
Zdrojový kód Intermediate Strojový kód
vyhlásenie ---> Stage 1 -> (pseudo) kód -------> Stage 2 ---> návod
| |
¯ ¯
(naložený) (naložený)
| |
¯ ¯
Interpreter --------------------> Prevedenie
Obrázok 2.9 Rozdiely medzi natívnym kódu a pseudo-kódu prekladača
Môžeme líči proces používaný v interpretačnej prekladač s operačným systémom MS-DOS pre hračky jazyk ako Clang, jeden ilustrovaný v ďalších kapitolách, v T-schémy podobe (pozri obr 2.10).
.-----------------------. .-----------------------.
| CLN.EXE |-- PROG.STK ->| PROG Interp.EXE |
PROG.CLN | Clang ----------> STK | | --------> RESULTS| Results
| | Data ----->| DATA |
`------. .------' `------. .------'
| 80486 | | 80486 |
| M-code | | M-code |
`---------' `---------'
.---------. .---------.
| 80486 | | 80486 |
`---------' `---------'
Obrázok 2.10 interpretačné prekladač/interpret pre Clang
Nie je nutné, aby obmedziť tlmočníkov iba pre prácu s medziľahlú výstupom z prekladateľom. Všeobecnejšie, samozrejme, môže mať aj skutočný stroj považovať za vysoko špecializované tlmočníka - ten, ktorý vykonáva inštrukcie stroja o úrovni očarujúce, analýzy, a potom tlmočenie je jeden po druhom. V reálnom stroji to všetko sa deje "v hardvéru", a teda veľmi rýchlo. Vykonaním tejto myšlienok, čitateľ by mal byť schopný vidieť, že program by mohol byť napísaný, aby jeden skutočný stroj emulovať iný skutočný stroj, aj keď možno pomaly, jednoducho tým, že písanie tlmočníka - alebo, ako to je zvyčajne viac názvom, emulátor - pre druhý stroj.
Napríklad, môžeme vytvoriť emulátor, ktorý beží na počítači Sun SPARC a robí to vyzerať, že IBM PC (alebo naopak). Potom, čo sme urobili, sme (v zásade) v pozícii vykonať akýkoľvek softvér vyvinutý pre IBM PC na stroji Sun SPARC - účinne PC softvér stáva prenosné!
T-diagram notácie je ľahko rozšírený pre spracovanie koncepcie týchto virtuálnych strojov. Napríklad, môže beh Turbo Pascal na našom počítači Sun SPARC byť zobrazený na obrázku 2.11.
.-------------------------------------.
PROG.PAS | TPC.EXE | PROG.EXE
| Turbo Pascal ------> 8086 code |
| |
`----------. .----------'
| 80x86 M-code |
| |
`---------------'
.- .---------------.
| | 80x86 M-code |
| | interpreter |
Virtual | SPARC code |
80x86 `---------------'
| .---------.
| | SPARC |
`- `---------'
Obrázok 2.11 Vykonávanie Turbo Pascal kompilátor na Sun SPARC
Tlmočník / emulátor prístup je široko používaný v oblasti navrhovania a vývoja ako nových strojov samotných, a softvér, ktorý je pre prevádzku na týchto strojoch.
Interpretačný prístup môže mať niekoľko bodov vo svoj prospech:
- Je oveľa jednoduchšie vytvárať hypotetické strojového kódu (ktorý môže byť prispôsobený k vtipov z pôvodného zdrojového jazyka), ako skutočné strojového kódu (ktorý sa musí vysporiadať s nekompromisnou vtipov skutočných strojov).
- Kompilátor písaný na výrobu (ako výstup) dobre definované pseudo-strojového kódu schopný ľahko výkladu na rade strojov možno ľahko prenosné, najmä ak je to napísané v jazyku hostiteľskej krajiny, ktorý je široko dostupný (napr. ANSI C) , alebo aj keď je k dispozícii už boli vykonané v jeho vlastný pseudo-kód.
- To môže ľahšie vykonať "user friendly", ako môže natívne kód prístup. Vzhľadom k tomu, tlmočník pracuje bližšie k zdrojovému kódu, než sa plne preložený program, môže chybové správy a ďalšie ladenie pomôcky ľahko vzťahujúce sa k tomuto zdroju.
- Celá rada jazykov môže byť rýchlo realizované v užitočné forme na širokej škále rôznych strojov relatívne ľahko. To sa vykonáva predložením mezikódu do dobre definované štandardom, pre ktorý pomerne účinná tlmočník by mal byť ľahko realizovať na konkrétne reálnom stroji.
- To sa ukázalo byť užitočné v súvislosti s krížovými prekladateľov ako boli spomenuté skôr. Kód produkované takými prekladateľov môže byť niekedy skúša viac účinne simulované spustenie na darcu počítači, skôr než po prevode do cieľového počítača - oneskorenie spojené s prechodom z jedného počítača na druhý môže byť dané degradáciou čase vykonania v interpretačnej simuláciu.
- Konečne, stredná jazyky sú často veľmi kompaktný, čo umožňuje veľké programy, ktoré budú prebiehať, a to aj na relatívne malých strojov. Úspech kedysi veľmi široko používaný UCSD Pascal a UCSD p-systém stojí ako príklad toho, čo sa dá urobiť v tomto smere.
U všetkých týchto výhod, interpretačné systémy niesť pomerne zjavné režijných nákladov v prevedení rýchlosťou, pretože výkon mezikódu efektívne so sebou nesie to náklady na virtuálne preklad do strojového kódu zakaždým hypotetický stroj pokyn poslúchol.
Jeden z najlepších známy prvých prenosných interpretačných prekladačov bol jeden vyvinutý na Zürich a známy ako "Pascal-P" kompilátor (Nori et al., 1981). To bola dodávaná v sade troch zložiek:
- Prvou zložkou je zdrojom forma Pascal kompilátor, písané v veľmi kompletný podmnožiny jazyka, známy ako Pascal-P. Cieľom tohto kompilátora bolo preložiť Pascal-P zdrojové programy v dobre definované a dobre zdokumentovaný Intermediate Language, známy ako P-kód, ktorý bol "strojový kód" pre hypotetickú stack-založené počítača, známy ako P -stroj.
- Druhá komponenta bola kompilované verzie prvá - P-kódy, ktoré by boli vyrobené Pascal-P kompilátor, keby sa o to zostaviť sám.
- Konečne, sada obsahuje tlmočníka pre P-kód jazyka, dodávané ako algoritmus Pascal.
Tlmočník slúžil primárne ako model pre písanie podobný program pre cieľovom počítači, aby mohla napodobniť hypotetický P-stroj. Ako bude vidieť v neskoršej kapitole, emulátory sú relatívne ľahko vytvoriť - aj, ak je to potrebné, v assembleri - tak, aby bola v tejto fáze obvykle pomerne bezbolestne dosiahnuť. Akonáhle človek naložil tlmočníka - to znamená, verzia je prispôsobená miestnym reálnom stroji - do skutočného stroja, jeden bol v pozícii, aby "spustiť" P-kód, a najmä na P-kód P-kompilátor. Zostavovaní a realizácii užívateľského programu by potom mohla byť dosiahnutá takým spôsobom, znázornené na Obrázku 2.12.
.--------------------------. .--------------------------.
| MyProgram.Pas | | MyProgram.P |
| Data ----------> Results| | Data ---------> Results|
| | | |
`-------. .--------------------------. .-------'
| | PasPtoP.P | |
| Pascal-P | Pascal-P -----> P-code | P-code |
| | | |
`------------------. .------------------'
| | .-----------. --.
| P-code | | P-code | |
| | | tlmočník | |
`----------' | M-code | P-stroje
.--- .-----------. `-----------' |
| | P-code | .-----------. |
| |Interpreter| | M-Machine | |
P-stroje | M-code | `-----------' --'
| `-----------'
| .-----------.
| | M-Machine |
`--- `-----------'
Obrázok 2.12 Kompilácia a spúšťanie programu s P-kompilátor
Cvičenie
2,18 Pokúste sa zistiť, ktorý z prekladateľov ste použili, sú tlmočníci, skôr než plné prekladača.
2.19 Ak máte prístup k obom natívnym kódu kompilátor a interpret pre programovací jazyk známy pre Vás, pokúste sa zmerať stratu v účinnosti, ak je interpret slúži na spustenie veľkého programu (možno ten, ktorý robí značný počet-chrumkavý) .
Preložené z
http://scifac.ru.ac.za/compilers/cha02s.htm
Homepage