252-210: Compiler Design 1.1 Simple compiler model 1.2 - - PowerPoint PPT Presentation

252-­‑210: ¡Compiler ¡Design ¡ ¡ 1.1 ¡Simple ¡compiler ¡model ¡ 1.2 ¡Admin ¡issues ¡

Thomas ¡R. ¡Gross ¡ ¡ Computer ¡Science ¡Department ¡ ETH ¡Zurich, ¡Switzerland ¡

1.1 ¡Simple ¡realisCc ¡compiler ¡model ¡

§ Simple: ¡can ¡be ¡handled ¡in ¡one ¡semester, ¡8 ¡credits ¡ § RealisCc: ¡experience ¡problems ¡encountered ¡by ¡real ¡ compilers ¡

§ Mirrors ¡structure ¡of ¡many ¡compilers ¡

2 ¡

Compiler ¡model ¡

5 ¡

§ CompilaCon ¡prior ¡to ¡execuCon ¡

§ AOT ¡“Ahead ¡of ¡(ExecuAon) ¡Time” ¡compilaAon ¡ § Commonly ¡used ¡for ¡languages ¡without ¡language-­‑specific ¡execuAon ¡ environments ¡ ¡(e.g., ¡C, ¡C++, ¡…) ¡

§ Other ¡model: ¡conCnuous ¡compilaCon ¡

§ JIT ¡“Just ¡in ¡Time” ¡compilaAon ¡ ¡ § Usually ¡op-miza-on ¡ ¡prior ¡to ¡execuAon ¡of ¡methods ¡that ¡are ¡invoked ¡ frequently ¡ § Commonly ¡used ¡with ¡language ¡virtual ¡machines ¡(e.g., ¡JVM) ¡

IR ¡– ¡intermediate ¡representaCon ¡ ¡

§ Compiler-­‑internal ¡representaCon ¡

§ E.g., ¡compiler ¡must ¡disAnguish ¡between ¡names ¡in ¡different ¡scopes ¡ § E.g., ¡many ¡programs ¡work ¡with ¡variables, ¡computers ¡work ¡with ¡ locaAons ¡

§ Must ¡express ¡all ¡language ¡constructs/concepts ¡ § Code ¡generator ¡must ¡map ¡IR ¡to ¡assembly ¡code ¡

§ Machine ¡code ¡another ¡opAon ¡ ¡

§ No ¡“best” ¡IR ¡– ¡all ¡are ¡compromises ¡ ¡ ¡

9 ¡

Compiler ¡design ¡ ¡

§ Overriding ¡concern ¡in ¡compiler ¡construcCon: ¡ § Correctness ¡

§ The ¡translated ¡program ¡PL2 ¡behaves ¡the ¡same ¡way ¡as ¡the ¡original ¡ program ¡PL1 ¡

§ For ¡correct ¡programs, ¡for ¡defined ¡inputs ¡ § Correct: ¡PL1 ¡obeys ¡the ¡rules ¡of ¡L1 ¡

§ For ¡incorrect ¡programs, ¡or ¡undefined/illegal ¡inputs, ¡PL2 ¡behaves ¡in ¡a ¡ defined ¡ ¡way ¡

§ Ideally ¡defined ¡by ¡L1, ¡someAmes ¡defined ¡by ¡L1 ¡and ¡L2 ¡resp. ¡the ¡target ¡machine ¡

13 ¡

Checking ¡input ¡(PL1) ¡

§ Compiler ¡must ¡check ¡that ¡program ¡can ¡be ¡translated ¡

• correctly. ¡

§ The ¡program ¡may ¡sAll ¡be ¡flawed ¡ § ExecuAon ¡behaves ¡as ¡expected ¡(or ¡specified) ¡

§ Issues ¡or ¡aspects ¡that ¡a ¡compiler ¡should ¡check: ¡

14 ¡

Issues/ProperCes ¡

§ All ¡variables/methods/symbols ¡defined ¡ § All ¡variables ¡iniCalized ¡before ¡use ¡ § Program ¡has ¡no ¡syntax ¡errors ¡ § Defined ¡program ¡start ¡(main ¡method ¡if ¡appropriate) ¡ § ExcepCons ¡are ¡caught ¡ § No ¡null-­‑ptr ¡accesses ¡ § No ¡out-­‑of-­‑bound ¡accesses ¡for ¡arrays, ¡records/instances ¡ § Program ¡type ¡checks ¡

17 ¡

§ No ¡unused ¡variables/fields ¡ § Return ¡statement ¡is ¡reachable ¡ § ExecuCon ¡reaches ¡end ¡of ¡program ¡ § All ¡funcCons ¡return ¡value ¡ § Rules ¡ ¡of ¡the ¡module ¡system ¡followed ¡

§ No ¡access ¡to ¡private/protected ¡members ¡unless ¡legal ¡

§ No ¡cycle ¡in ¡inheritance ¡graph ¡ § Interfaces/abstract ¡funcCons ¡implemented ¡ § Loops ¡terminate ¡ § Program ¡executes ¡within ¡a ¡given ¡Cme ¡ § Program ¡stays ¡within ¡power ¡budget ¡ § All ¡values ¡computed ¡can ¡be ¡represented ¡ ¡

18 ¡

252-­‑210: ¡Compiler ¡Design ¡ ¡ 2.0 ¡TranslaAon ¡of ¡assignment ¡statements ¡

Thomas ¡R. ¡Gross ¡ ¡ Computer ¡Science ¡Department ¡ ETH ¡Zurich, ¡Switzerland ¡

2.0 ¡TranslaCon ¡of ¡assignment ¡statements ¡

§ Assignment ¡statements ¡(stmts) ¡are ¡found ¡in ¡many ¡ programming ¡languages ¡ § We ¡look ¡at ¡simple ¡assignment ¡stmts: ¡

§ A ¡= ¡B ¡+ ¡1 ¡ § Types ¡of ¡A, ¡B? ¡ ¡int ¡ ¡ ¡(32bit) ¡

§ As ¡in ¡C, ¡C++, ¡Java, ¡Pascal, ¡…. ¡

§ Only ¡scalar ¡enAAes ¡ § Only ¡32-­‑bit ¡integer ¡constants ¡

21 ¡

One ¡boring ¡assignment ¡stmt ¡

§ Examples: ¡

int A, B, C; A = B + C; // “+” generic operator int A, B, C, D; A = B + C + D; int A, B, C; A = B + C + 2 + 4;

§ Simple. ¡ ¡ ¡ § Your ¡task: ¡given ¡a ¡single ¡assignment ¡stmt, ¡generate ¡code ¡for ¡ this ¡stmt. ¡

§ We ¡give ¡you ¡the ¡IR ¡for ¡the ¡stmt. ¡

22 ¡

A ¡start ¡

§ Use ¡assignment ¡stmt ¡to ¡explore ¡(part ¡of) ¡the ¡IR ¡ § Can ¡you ¡generate ¡“opCmal” ¡code? ¡

§ What ¡is ¡opAmal? ¡ § Is ¡there ¡an ¡efficient ¡algorithm? ¡

§ Efficient: ¡guaranteed ¡to ¡terminate ¡before ¡the ¡deadline ¡

§ Easy ¡extension: ¡one ¡stmt ¡ ¡list ¡of ¡stmts ¡ ¡

§ Known ¡as ¡a ¡block ¡ ¡ § SoluAon ¡to ¡this ¡assignment ¡to ¡be ¡reused ¡later ¡(Homework ¡5, ¡November) ¡

23 ¡

2.1 ¡Intermediate ¡representaCon ¡ ¡

§ There ¡exist ¡many ¡IRs ¡

§ Some ¡compilers ¡use ¡several ¡IRs ¡during ¡translaAon ¡

§ First ¡IR ¡to ¡represent ¡input ¡program ¡ § Analyze, ¡add ¡annotaAons ¡ § “Lower” ¡IR: ¡expose ¡more ¡details ¡

§ No ¡single ¡IR ¡is ¡best ¡

§ IR ¡for ¡this ¡course ¡is ¡tree-­‑based ¡

§ Easy ¡to ¡understand ¡ § Easy ¡to ¡extend: ¡tree ¡à ¡forest ¡ § Close ¡to ¡IR ¡used ¡in ¡real ¡compilers ¡

§ More ¡sophisCcated ¡IR ¡le_ ¡for ¡“Advanced ¡Compiler ¡Design” ¡

24 ¡

Approach ¡

§ Tree ¡describes ¡computaCon ¡to ¡be ¡done ¡ § Determines ¡“evaluaCon ¡order” ¡

§ First ¡ ¡(C ¡* ¡D) ¡ § Then ¡add ¡product ¡to ¡B ¡

§ Compile ¡one ¡tree ¡at ¡a ¡Cme ¡ § Code ¡generator ¡“visits” ¡a ¡node ¡

§ Bookkeeping ¡ § (maybe) ¡Generate ¡code ¡ § Visit ¡subnodes ¡ § Bookkeeping ¡ § (maybe) ¡Generate ¡code ¡

29 ¡

Some ¡texts ¡say ¡“Code ¡ generator ¡evaluates ¡a ¡ node” ¡

Binary ¡trees ¡

§ IR ¡allows ¡only ¡binary ¡trees ¡

int A, B, C, D; A = B + C + D;

30 ¡

§ Tree ¡determines ¡evaluaCon ¡order ¡ § Compare ¡

Add B, C // B = B + C Add B, D // B = B + D § With ¡ Add B, D // B = B + D Add B, C // B = B + C

§ The ¡results ¡may ¡differ ¡

§ FloaAng ¡point ¡arithmeAc ¡is ¡not ¡associaAve ¡

34 ¡

Non-­‑associaCve ¡arithmeCc ¡

§ (X ¡+fp ¡Y) ¡+fp ¡Z ¡ ¡is ¡possibly ¡different ¡from ¡X ¡+fp ¡(Y ¡+fp ¡Z) ¡ ¡ ¡

§ +fp ¡floaAng ¡point ¡arithmeAc ¡

35 ¡

How ¡to ¡proceed? ¡

§ Who ¡should ¡decide ¡which ¡tree ¡to ¡build? ¡ § Programming ¡language ¡specificaCon ¡should ¡address ¡this ¡

• issue. ¡

§ Maybe ¡allow ¡user ¡opAons ¡ ¡ § E.g., ¡icc ¡(Intel’s ¡C ¡compiler) ¡supports ¡ ¡

§ –fp-­‑model ¡precise ¡ § –fp-­‑model ¡source ¡ ¡

38 ¡

252-­‑210: ¡Compiler ¡Design ¡ ¡ 1.2 ¡Admin ¡issues ¡ ¡

Thomas ¡R. ¡Gross ¡ ¡ Computer ¡Science ¡Department ¡ ETH ¡Zurich, ¡Switzerland ¡

Topics ¡for ¡this ¡class ¡

§ Compiler ¡design: ¡structure ¡of ¡a ¡simple ¡compiler ¡ § So_ware ¡engineering: ¡ ¡

§ Design ¡of ¡a ¡non-­‑trivial ¡system ¡ § Solware ¡reuse ¡

§ Homework ¡(design ¡and ¡implementaCon ¡of ¡a ¡compiler) ¡core ¡ part ¡of ¡this ¡course ¡

40 ¡

Recall ¡

§ Compiler ¡translates ¡program ¡wriden ¡in ¡L1 ¡(PL1) ¡into ¡program ¡ wriden ¡in ¡ ¡L2 ¡(PL2) ¡

§ ¡PL1 ¡à ¡PL2 ¡

§ Languages ¡

§ Source ¡language ¡L1 ¡ § Target ¡language ¡L2 ¡ § Host ¡language ¡P ¡ ¡

§ Want ¡to ¡use ¡tools, ¡reuse ¡framework: ¡

§ P: ¡Java ¡

41 ¡

Homework ¡

§ Build ¡a ¡compiler ¡

§ 5 ¡(or ¡6) ¡easy ¡steps ¡

§ Teams ¡of ¡2 ¡persons ¡ § SCll ¡a ¡lot ¡of ¡work ¡

§ Use ¡compiler ¡framework ¡(provided ¡by ¡TAs) ¡

42 ¡

Compiler ¡target ¡

§ Resource ¡issues ¡criCcal ¡in ¡compilaCon ¡ § Use ¡real ¡machine ¡

§ Real ¡machines ¡have ¡real ¡flaws ¡ § Only ¡paper ¡designs ¡are ¡perfect ¡ § Target ¡(language): ¡x86 ¡(32-­‑bit) ¡assembler, ¡Linux ¡

§ ObjecCve ¡is ¡to ¡understand ¡issues, ¡not ¡become ¡an ¡expert ¡in ¡ x86 ¡assembly ¡language ¡programming ¡

§ Knowledge ¡from ¡“Computer ¡Architecture ¡and ¡Systems ¡Programming” ¡ sufficient ¡

45 ¡

Source ¡language ¡

§ Object-­‑oriented ¡ § Polymorphism ¡ § Class-­‑based ¡

§ Single ¡inheritance ¡

§ …. ¡subset ¡of ¡Java: ¡JavaLi ¡

§ No ¡finalizers ¡ § No ¡staAc ¡fields/methods ¡ § No ¡mulA-­‑threading ¡ § No ¡module ¡system ¡ § … ¡

48 ¡

JavaLi ¡ ¡ ¡

class Record { int j; int next() { j = j + 1; return j; } }

49 ¡

Grading ¡ ¡

§ Homework ¡done ¡in ¡teams ¡

§ Graded ¡ § Contributes ¡to ¡final ¡grade: ¡ ¡50% ¡of ¡the ¡final ¡grade ¡is ¡determined ¡by ¡the ¡ grades ¡you ¡get ¡for ¡homework ¡ § If ¡you ¡can’t ¡do ¡homework ¡by ¡due ¡date: ¡Talk ¡to ¡the ¡TAs ¡or ¡the ¡ instructor ¡before ¡the ¡deadline ¡

§ We ¡are ¡reasonable ¡

§ Final ¡exam ¡ ¡DATE ¡unknown ¡

§ 2 ¡hrs ¡ ¡ § During ¡examinaAon ¡period ¡ § Talk ¡to ¡me ¡by ¡Nov ¡15 ¡if ¡you ¡*must* ¡be ¡absent ¡

51 ¡

Homework ¡

§ Both ¡members ¡of ¡a ¡team ¡must ¡contribute ¡

§ Both ¡of ¡you ¡are ¡responsible ¡for ¡the ¡soluAon ¡you ¡turn ¡in ¡ § We ¡reserve ¡the ¡right ¡to ¡ask ¡quesAons ¡about ¡the ¡design, ¡ implementaAon, ¡tesAng ¡plan, ¡etc. ¡

§ You ¡must ¡turn ¡in ¡your ¡own ¡work. ¡

§ “Finding” ¡a ¡soluAon ¡in ¡a ¡someone ¡else’s ¡directory ¡is ¡chea-ng. ¡ ¡ § ETH ¡has ¡ ¡a ¡policy ¡on ¡cheaAng. ¡

52 ¡

53 ¡

54 ¡

Homework ¡

§ We ¡do ¡not ¡want ¡to ¡play ¡police. ¡ § Do ¡the ¡homework ¡yourself. ¡ § Discussions ¡are ¡fine ¡(and ¡encouraged) ¡– ¡copying ¡code ¡is ¡not. ¡

56 ¡

1st ¡homework ¡

§ Form ¡a ¡team ¡of ¡2 ¡persons ¡

§ Choose ¡your ¡team’s ¡name ¡wisely ¡

§ Register ¡team ¡

§ Details ¡on ¡the ¡web ¡page ¡

§ Write ¡a ¡small ¡program ¡

§ See ¡web ¡page ¡

§ No ¡team ¡partner? ¡

§ Come ¡to ¡front ¡aler ¡class ¡(today, ¡next ¡Wed) ¡ § Write ¡program ¡(above) ¡on ¡your ¡own ¡

57 ¡

Summary ¡

§ L1: ¡JavaLi ¡

§ Classes/methods ¡ § PrimiAve ¡type ¡int § Inheritance ¡(single) ¡ § NO ¡mulAple ¡inheritance, ¡NO ¡excepAons, ¡NO ¡threads, ¡NO ¡finalizer ¡

§ L2: ¡x86 ¡ ¡(32-­‑bit, ¡IA32) ¡ § P ¡-­‑-­‑ ¡compiler ¡language: ¡Java ¡ § First ¡homework ¡

§ Form ¡team ¡ ¡

58 ¡

Non-­‑topics ¡(for ¡this ¡class) ¡

§ Efficiency ¡of ¡generated ¡code ¡(in ¡L2) ¡ § Efficiency ¡of ¡compiler ¡

§ Can’t ¡make ¡stupid ¡mistakes ¡

§ Ease ¡of ¡re-­‑targeCng ¡(from ¡L2 ¡to ¡L3) ¡ § Ease ¡of ¡porCng ¡(from ¡P ¡to ¡P’) ¡

59 ¡

Literature ¡

§ Aho/Lam/Sethi/Ullman: ¡Compilers: ¡Principles, ¡Techniques, ¡ and ¡Tools, ¡2nd ¡ediCon ¡ § Muchnick: ¡Advanced ¡Compiler ¡Design ¡and ¡ImplementaCon ¡ § Books ¡on ¡paderns, ¡frameworks, ¡so_ware ¡design ¡

60 ¡