252 210 compiler design 1 1 simple compiler model 1 2
play

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


  1. 252-­‑210: ¡Compiler ¡Design ¡ ¡ 1.1 ¡Simple ¡compiler ¡model ¡ 1.2 ¡Admin ¡issues ¡ Thomas ¡R. ¡Gross ¡ ¡ Computer ¡Science ¡Department ¡ ETH ¡Zurich, ¡Switzerland ¡

  2. 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 ¡

  3. Compiler ¡model ¡ § 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) ¡ 5 ¡

  4. 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 ¡

  5. Compiler ¡design ¡ ¡ § Overriding ¡concern ¡in ¡compiler ¡construcCon: ¡ § Correctness ¡ § The ¡translated ¡program ¡P L2 ¡behaves ¡the ¡same ¡way ¡as ¡the ¡original ¡ program ¡P L1 ¡ § For ¡correct ¡programs, ¡for ¡defined ¡inputs ¡ § Correct: ¡P L1 ¡obeys ¡the ¡rules ¡of ¡L 1 ¡ § For ¡incorrect ¡programs, ¡or ¡undefined/illegal ¡inputs, ¡P L2 ¡behaves ¡in ¡a ¡ defined ¡ ¡way ¡ § Ideally ¡defined ¡by ¡L 1 , ¡someAmes ¡defined ¡by ¡L 1 ¡and ¡L 2 ¡resp. ¡the ¡target ¡machine ¡ 13 ¡

  6. Checking ¡input ¡(P L1 ) ¡ § 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 ¡

  7. 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 ¡

  8. § 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 ¡

  9. 252-­‑210: ¡Compiler ¡Design ¡ ¡ 2.0 ¡TranslaAon ¡of ¡assignment ¡statements ¡ Thomas ¡R. ¡Gross ¡ ¡ Computer ¡Science ¡Department ¡ ETH ¡Zurich, ¡Switzerland ¡

  10. 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 ¡

  11. 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 ¡

  12. 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 ¡

  13. 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 ¡

  14. Approach ¡ § Tree ¡describes ¡computaCon ¡to ¡be ¡done ¡ § Determines ¡“evaluaCon ¡order” ¡ § First ¡ ¡(C ¡* ¡D) ¡ § Then ¡add ¡product ¡to ¡B ¡ Some ¡texts ¡say ¡“Code ¡ generator ¡evaluates ¡a ¡ § Compile ¡one ¡tree ¡at ¡a ¡Cme ¡ node” ¡ § Code ¡generator ¡“visits” ¡a ¡node ¡ § Bookkeeping ¡ § (maybe) ¡Generate ¡code ¡ § Visit ¡subnodes ¡ § Bookkeeping ¡ § (maybe) ¡Generate ¡code ¡ 29 ¡

  15. Binary ¡trees ¡ § IR ¡allows ¡only ¡ binary ¡trees ¡ int A, B, C, D; A = B + C + D; 30 ¡

  16. § 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 ¡

  17. Non-­‑associaCve ¡arithmeCc ¡ § (X ¡+ fp ¡Y) ¡+ fp ¡Z ¡ ¡is ¡possibly ¡different ¡from ¡X ¡+ fp ¡(Y ¡+ fp ¡Z) ¡ ¡ ¡ § + fp ¡floaAng ¡point ¡arithmeAc ¡ 35 ¡

  18. 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 ¡

  19. 252-­‑210: ¡Compiler ¡Design ¡ ¡ 1.2 ¡Admin ¡issues ¡ ¡ Thomas ¡R. ¡Gross ¡ ¡ Computer ¡Science ¡Department ¡ ETH ¡Zurich, ¡Switzerland ¡

  20. 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 ¡

  21. Recall ¡ § Compiler ¡translates ¡program ¡wriden ¡in ¡L 1 ¡(P L1 ) ¡into ¡program ¡ wriden ¡in ¡ ¡L 2 ¡(P L2 ) ¡ § ¡P L1 ¡ à ¡P L2 ¡ § Languages ¡ § Source ¡language ¡L 1 ¡ § Target ¡language ¡L 2 ¡ § Host ¡language ¡P ¡ ¡ § Want ¡to ¡use ¡tools, ¡reuse ¡framework: ¡ § P: ¡Java ¡ 41 ¡

Recommend


More recommend