book.tex 459 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798991001011021031041051061071081091101111121131141151161171181191201211221231241251261271281291301311321331341351361371381391401411421431441451461471481491501511521531541551561571581591601611621631641651661671681691701711721731741751761771781791801811821831841851861871881891901911921931941951961971981992002012022032042052062072082092102112122132142152162172182192202212222232242252262272282292302312322332342352362372382392402412422432442452462472482492502512522532542552562572582592602612622632642652662672682692702712722732742752762772782792802812822832842852862872882892902912922932942952962972982993003013023033043053063073083093103113123133143153163173183193203213223233243253263273283293303313323333343353363373383393403413423433443453463473483493503513523533543553563573583593603613623633643653663673683693703713723733743753763773783793803813823833843853863873883893903913923933943953963973983994004014024034044054064074084094104114124134144154164174184194204214224234244254264274284294304314324334344354364374384394404414424434444454464474484494504514524534544554564574584594604614624634644654664674684694704714724734744754764774784794804814824834844854864874884894904914924934944954964974984995005015025035045055065075085095105115125135145155165175185195205215225235245255265275285295305315325335345355365375385395405415425435445455465475485495505515525535545555565575585595605615625635645655665675685695705715725735745755765775785795805815825835845855865875885895905915925935945955965975985996006016026036046056066076086096106116126136146156166176186196206216226236246256266276286296306316326336346356366376386396406416426436446456466476486496506516526536546556566576586596606616626636646656666676686696706716726736746756766776786796806816826836846856866876886896906916926936946956966976986997007017027037047057067077087097107117127137147157167177187197207217227237247257267277287297307317327337347357367377387397407417427437447457467477487497507517527537547557567577587597607617627637647657667677687697707717727737747757767777787797807817827837847857867877887897907917927937947957967977987998008018028038048058068078088098108118128138148158168178188198208218228238248258268278288298308318328338348358368378388398408418428438448458468478488498508518528538548558568578588598608618628638648658668678688698708718728738748758768778788798808818828838848858868878888898908918928938948958968978988999009019029039049059069079089099109119129139149159169179189199209219229239249259269279289299309319329339349359369379389399409419429439449459469479489499509519529539549559569579589599609619629639649659669679689699709719729739749759769779789799809819829839849859869879889899909919929939949959969979989991000100110021003100410051006100710081009101010111012101310141015101610171018101910201021102210231024102510261027102810291030103110321033103410351036103710381039104010411042104310441045104610471048104910501051105210531054105510561057105810591060106110621063106410651066106710681069107010711072107310741075107610771078107910801081108210831084108510861087108810891090109110921093109410951096109710981099110011011102110311041105110611071108110911101111111211131114111511161117111811191120112111221123112411251126112711281129113011311132113311341135113611371138113911401141114211431144114511461147114811491150115111521153115411551156115711581159116011611162116311641165116611671168116911701171117211731174117511761177117811791180118111821183118411851186118711881189119011911192119311941195119611971198119912001201120212031204120512061207120812091210121112121213121412151216121712181219122012211222122312241225122612271228122912301231123212331234123512361237123812391240124112421243124412451246124712481249125012511252125312541255125612571258125912601261126212631264126512661267126812691270127112721273127412751276127712781279128012811282128312841285128612871288128912901291129212931294129512961297129812991300130113021303130413051306130713081309131013111312131313141315131613171318131913201321132213231324132513261327132813291330133113321333133413351336133713381339134013411342134313441345134613471348134913501351135213531354135513561357135813591360136113621363136413651366136713681369137013711372137313741375137613771378137913801381138213831384138513861387138813891390139113921393139413951396139713981399140014011402140314041405140614071408140914101411141214131414141514161417141814191420142114221423142414251426142714281429143014311432143314341435143614371438143914401441144214431444144514461447144814491450145114521453145414551456145714581459146014611462146314641465146614671468146914701471147214731474147514761477147814791480148114821483148414851486148714881489149014911492149314941495149614971498149915001501150215031504150515061507150815091510151115121513151415151516151715181519152015211522152315241525152615271528152915301531153215331534153515361537153815391540154115421543154415451546154715481549155015511552155315541555155615571558155915601561156215631564156515661567156815691570157115721573157415751576157715781579158015811582158315841585158615871588158915901591159215931594159515961597159815991600160116021603160416051606160716081609161016111612161316141615161616171618161916201621162216231624162516261627162816291630163116321633163416351636163716381639164016411642164316441645164616471648164916501651165216531654165516561657165816591660166116621663166416651666166716681669167016711672167316741675167616771678167916801681168216831684168516861687168816891690169116921693169416951696169716981699170017011702170317041705170617071708170917101711171217131714171517161717171817191720172117221723172417251726172717281729173017311732173317341735173617371738173917401741174217431744174517461747174817491750175117521753175417551756175717581759176017611762176317641765176617671768176917701771177217731774177517761777177817791780178117821783178417851786178717881789179017911792179317941795179617971798179918001801180218031804180518061807180818091810181118121813181418151816181718181819182018211822182318241825182618271828182918301831183218331834183518361837183818391840184118421843184418451846184718481849185018511852185318541855185618571858185918601861186218631864186518661867186818691870187118721873187418751876187718781879188018811882188318841885188618871888188918901891189218931894189518961897189818991900190119021903190419051906190719081909191019111912191319141915191619171918191919201921192219231924192519261927192819291930193119321933193419351936193719381939194019411942194319441945194619471948194919501951195219531954195519561957195819591960196119621963196419651966196719681969197019711972197319741975197619771978197919801981198219831984198519861987198819891990199119921993199419951996199719981999200020012002200320042005200620072008200920102011201220132014201520162017201820192020202120222023202420252026202720282029203020312032203320342035203620372038203920402041204220432044204520462047204820492050205120522053205420552056205720582059206020612062206320642065206620672068206920702071207220732074207520762077207820792080208120822083208420852086208720882089209020912092209320942095209620972098209921002101210221032104210521062107210821092110211121122113211421152116211721182119212021212122212321242125212621272128212921302131213221332134213521362137213821392140214121422143214421452146214721482149215021512152215321542155215621572158215921602161216221632164216521662167216821692170217121722173217421752176217721782179218021812182218321842185218621872188218921902191219221932194219521962197219821992200220122022203220422052206220722082209221022112212221322142215221622172218221922202221222222232224222522262227222822292230223122322233223422352236223722382239224022412242224322442245224622472248224922502251225222532254225522562257225822592260226122622263226422652266226722682269227022712272227322742275227622772278227922802281228222832284228522862287228822892290229122922293229422952296229722982299230023012302230323042305230623072308230923102311231223132314231523162317231823192320232123222323232423252326232723282329233023312332233323342335233623372338233923402341234223432344234523462347234823492350235123522353235423552356235723582359236023612362236323642365236623672368236923702371237223732374237523762377237823792380238123822383238423852386238723882389239023912392239323942395239623972398239924002401240224032404240524062407240824092410241124122413241424152416241724182419242024212422242324242425242624272428242924302431243224332434243524362437243824392440244124422443244424452446244724482449245024512452245324542455245624572458245924602461246224632464246524662467246824692470247124722473247424752476247724782479248024812482248324842485248624872488248924902491249224932494249524962497249824992500250125022503250425052506250725082509251025112512251325142515251625172518251925202521252225232524252525262527252825292530253125322533253425352536253725382539254025412542254325442545254625472548254925502551255225532554255525562557255825592560256125622563256425652566256725682569257025712572257325742575257625772578257925802581258225832584258525862587258825892590259125922593259425952596259725982599260026012602260326042605260626072608260926102611261226132614261526162617261826192620262126222623262426252626262726282629263026312632263326342635263626372638263926402641264226432644264526462647264826492650265126522653265426552656265726582659266026612662266326642665266626672668266926702671267226732674267526762677267826792680268126822683268426852686268726882689269026912692269326942695269626972698269927002701270227032704270527062707270827092710271127122713271427152716271727182719272027212722272327242725272627272728272927302731273227332734273527362737273827392740274127422743274427452746274727482749275027512752275327542755275627572758275927602761276227632764276527662767276827692770277127722773277427752776277727782779278027812782278327842785278627872788278927902791279227932794279527962797279827992800280128022803280428052806280728082809281028112812281328142815281628172818281928202821282228232824282528262827282828292830283128322833283428352836283728382839284028412842284328442845284628472848284928502851285228532854285528562857285828592860286128622863286428652866286728682869287028712872287328742875287628772878287928802881288228832884288528862887288828892890289128922893289428952896289728982899290029012902290329042905290629072908290929102911291229132914291529162917291829192920292129222923292429252926292729282929293029312932293329342935293629372938293929402941294229432944294529462947294829492950295129522953295429552956295729582959296029612962296329642965296629672968296929702971297229732974297529762977297829792980298129822983298429852986298729882989299029912992299329942995299629972998299930003001300230033004300530063007300830093010301130123013301430153016301730183019302030213022302330243025302630273028302930303031303230333034303530363037303830393040304130423043304430453046304730483049305030513052305330543055305630573058305930603061306230633064306530663067306830693070307130723073307430753076307730783079308030813082308330843085308630873088308930903091309230933094309530963097309830993100310131023103310431053106310731083109311031113112311331143115311631173118311931203121312231233124312531263127312831293130313131323133313431353136313731383139314031413142314331443145314631473148314931503151315231533154315531563157315831593160316131623163316431653166316731683169317031713172317331743175317631773178317931803181318231833184318531863187318831893190319131923193319431953196319731983199320032013202320332043205320632073208320932103211321232133214321532163217321832193220322132223223322432253226322732283229323032313232323332343235323632373238323932403241324232433244324532463247324832493250325132523253325432553256325732583259326032613262326332643265326632673268326932703271327232733274327532763277327832793280328132823283328432853286328732883289329032913292329332943295329632973298329933003301330233033304330533063307330833093310331133123313331433153316331733183319332033213322332333243325332633273328332933303331333233333334333533363337333833393340334133423343334433453346334733483349335033513352335333543355335633573358335933603361336233633364336533663367336833693370337133723373337433753376337733783379338033813382338333843385338633873388338933903391339233933394339533963397339833993400340134023403340434053406340734083409341034113412341334143415341634173418341934203421342234233424342534263427342834293430343134323433343434353436343734383439344034413442344334443445344634473448344934503451345234533454345534563457345834593460346134623463346434653466346734683469347034713472347334743475347634773478347934803481348234833484348534863487348834893490349134923493349434953496349734983499350035013502350335043505350635073508350935103511351235133514351535163517351835193520352135223523352435253526352735283529353035313532353335343535353635373538353935403541354235433544354535463547354835493550355135523553355435553556355735583559356035613562356335643565356635673568356935703571357235733574357535763577357835793580358135823583358435853586358735883589359035913592359335943595359635973598359936003601360236033604360536063607360836093610361136123613361436153616361736183619362036213622362336243625362636273628362936303631363236333634363536363637363836393640364136423643364436453646364736483649365036513652365336543655365636573658365936603661366236633664366536663667366836693670367136723673367436753676367736783679368036813682368336843685368636873688368936903691369236933694369536963697369836993700370137023703370437053706370737083709371037113712371337143715371637173718371937203721372237233724372537263727372837293730373137323733373437353736373737383739374037413742374337443745374637473748374937503751375237533754375537563757375837593760376137623763376437653766376737683769377037713772377337743775377637773778377937803781378237833784378537863787378837893790379137923793379437953796379737983799380038013802380338043805380638073808380938103811381238133814381538163817381838193820382138223823382438253826382738283829383038313832383338343835383638373838383938403841384238433844384538463847384838493850385138523853385438553856385738583859386038613862386338643865386638673868386938703871387238733874387538763877387838793880388138823883388438853886388738883889389038913892389338943895389638973898389939003901390239033904390539063907390839093910391139123913391439153916391739183919392039213922392339243925392639273928392939303931393239333934393539363937393839393940394139423943394439453946394739483949395039513952395339543955395639573958395939603961396239633964396539663967396839693970397139723973397439753976397739783979398039813982398339843985398639873988398939903991399239933994399539963997399839994000400140024003400440054006400740084009401040114012401340144015401640174018401940204021402240234024402540264027402840294030403140324033403440354036403740384039404040414042404340444045404640474048404940504051405240534054405540564057405840594060406140624063406440654066406740684069407040714072407340744075407640774078407940804081408240834084408540864087408840894090409140924093409440954096409740984099410041014102410341044105410641074108410941104111411241134114411541164117411841194120412141224123412441254126412741284129413041314132413341344135413641374138413941404141414241434144414541464147414841494150415141524153415441554156415741584159416041614162416341644165416641674168416941704171417241734174417541764177417841794180418141824183418441854186418741884189419041914192419341944195419641974198419942004201420242034204420542064207420842094210421142124213421442154216421742184219422042214222422342244225422642274228422942304231423242334234423542364237423842394240424142424243424442454246424742484249425042514252425342544255425642574258425942604261426242634264426542664267426842694270427142724273427442754276427742784279428042814282428342844285428642874288428942904291429242934294429542964297429842994300430143024303430443054306430743084309431043114312431343144315431643174318431943204321432243234324432543264327432843294330433143324333433443354336433743384339434043414342434343444345434643474348434943504351435243534354435543564357435843594360436143624363436443654366436743684369437043714372437343744375437643774378437943804381438243834384438543864387438843894390439143924393439443954396439743984399440044014402440344044405440644074408440944104411441244134414441544164417441844194420442144224423442444254426442744284429443044314432443344344435443644374438443944404441444244434444444544464447444844494450445144524453445444554456445744584459446044614462446344644465446644674468446944704471447244734474447544764477447844794480448144824483448444854486448744884489449044914492449344944495449644974498449945004501450245034504450545064507450845094510451145124513451445154516451745184519452045214522452345244525452645274528452945304531453245334534453545364537453845394540454145424543454445454546454745484549455045514552455345544555455645574558455945604561456245634564456545664567456845694570457145724573457445754576457745784579458045814582458345844585458645874588458945904591459245934594459545964597459845994600460146024603460446054606460746084609461046114612461346144615461646174618461946204621462246234624462546264627462846294630463146324633463446354636463746384639464046414642464346444645464646474648464946504651465246534654465546564657465846594660466146624663466446654666466746684669467046714672467346744675467646774678467946804681468246834684468546864687468846894690469146924693469446954696469746984699470047014702470347044705470647074708470947104711471247134714471547164717471847194720472147224723472447254726472747284729473047314732473347344735473647374738473947404741474247434744474547464747474847494750475147524753475447554756475747584759476047614762476347644765476647674768476947704771477247734774477547764777477847794780478147824783478447854786478747884789479047914792479347944795479647974798479948004801480248034804480548064807480848094810481148124813481448154816481748184819482048214822482348244825482648274828482948304831483248334834483548364837483848394840484148424843484448454846484748484849485048514852485348544855485648574858485948604861486248634864486548664867486848694870487148724873487448754876487748784879488048814882488348844885488648874888488948904891489248934894489548964897489848994900490149024903490449054906490749084909491049114912491349144915491649174918491949204921492249234924492549264927492849294930493149324933493449354936493749384939494049414942494349444945494649474948494949504951495249534954495549564957495849594960496149624963496449654966496749684969497049714972497349744975497649774978497949804981498249834984498549864987498849894990499149924993499449954996499749984999500050015002500350045005500650075008500950105011501250135014501550165017501850195020502150225023502450255026502750285029503050315032503350345035503650375038503950405041504250435044504550465047504850495050505150525053505450555056505750585059506050615062506350645065506650675068506950705071507250735074507550765077507850795080508150825083508450855086508750885089509050915092509350945095509650975098509951005101510251035104510551065107510851095110511151125113511451155116511751185119512051215122512351245125512651275128512951305131513251335134513551365137513851395140514151425143514451455146514751485149515051515152515351545155515651575158515951605161516251635164516551665167516851695170517151725173517451755176517751785179518051815182518351845185518651875188518951905191519251935194519551965197519851995200520152025203520452055206520752085209521052115212521352145215521652175218521952205221522252235224522552265227522852295230523152325233523452355236523752385239524052415242524352445245524652475248524952505251525252535254525552565257525852595260526152625263526452655266526752685269527052715272527352745275527652775278527952805281528252835284528552865287528852895290529152925293529452955296529752985299530053015302530353045305530653075308530953105311531253135314531553165317531853195320532153225323532453255326532753285329533053315332533353345335533653375338533953405341534253435344534553465347534853495350535153525353535453555356535753585359536053615362536353645365536653675368536953705371537253735374537553765377537853795380538153825383538453855386538753885389539053915392539353945395539653975398539954005401540254035404540554065407540854095410541154125413541454155416541754185419542054215422542354245425542654275428542954305431543254335434543554365437543854395440544154425443544454455446544754485449545054515452545354545455545654575458545954605461546254635464546554665467546854695470547154725473547454755476547754785479548054815482548354845485548654875488548954905491549254935494549554965497549854995500550155025503550455055506550755085509551055115512551355145515551655175518551955205521552255235524552555265527552855295530553155325533553455355536553755385539554055415542554355445545554655475548554955505551555255535554555555565557555855595560556155625563556455655566556755685569557055715572557355745575557655775578557955805581558255835584558555865587558855895590559155925593559455955596559755985599560056015602560356045605560656075608560956105611561256135614561556165617561856195620562156225623562456255626562756285629563056315632563356345635563656375638563956405641564256435644564556465647564856495650565156525653565456555656565756585659566056615662566356645665566656675668566956705671567256735674567556765677567856795680568156825683568456855686568756885689569056915692569356945695569656975698569957005701570257035704570557065707570857095710571157125713571457155716571757185719572057215722572357245725572657275728572957305731573257335734573557365737573857395740574157425743574457455746574757485749575057515752575357545755575657575758575957605761576257635764576557665767576857695770577157725773577457755776577757785779578057815782578357845785578657875788578957905791579257935794579557965797579857995800580158025803580458055806580758085809581058115812581358145815581658175818581958205821582258235824582558265827582858295830583158325833583458355836583758385839584058415842584358445845584658475848584958505851585258535854585558565857585858595860586158625863586458655866586758685869587058715872587358745875587658775878587958805881588258835884588558865887588858895890589158925893589458955896589758985899590059015902590359045905590659075908590959105911591259135914591559165917591859195920592159225923592459255926592759285929593059315932593359345935593659375938593959405941594259435944594559465947594859495950595159525953595459555956595759585959596059615962596359645965596659675968596959705971597259735974597559765977597859795980598159825983598459855986598759885989599059915992599359945995599659975998599960006001600260036004600560066007600860096010601160126013601460156016601760186019602060216022602360246025602660276028602960306031603260336034603560366037603860396040604160426043604460456046604760486049605060516052605360546055605660576058605960606061606260636064606560666067606860696070607160726073607460756076607760786079608060816082608360846085608660876088608960906091609260936094609560966097609860996100610161026103610461056106610761086109611061116112611361146115611661176118611961206121612261236124612561266127612861296130613161326133613461356136613761386139614061416142614361446145614661476148614961506151615261536154615561566157615861596160616161626163616461656166616761686169617061716172617361746175617661776178617961806181618261836184618561866187618861896190619161926193619461956196619761986199620062016202620362046205620662076208620962106211621262136214621562166217621862196220622162226223622462256226622762286229623062316232623362346235623662376238623962406241624262436244624562466247624862496250625162526253625462556256625762586259626062616262626362646265626662676268626962706271627262736274627562766277627862796280628162826283628462856286628762886289629062916292629362946295629662976298629963006301630263036304630563066307630863096310631163126313631463156316631763186319632063216322632363246325632663276328632963306331633263336334633563366337633863396340634163426343634463456346634763486349635063516352635363546355635663576358635963606361636263636364636563666367636863696370637163726373637463756376637763786379638063816382638363846385638663876388638963906391639263936394639563966397639863996400640164026403640464056406640764086409641064116412641364146415641664176418641964206421642264236424642564266427642864296430643164326433643464356436643764386439644064416442644364446445644664476448644964506451645264536454645564566457645864596460646164626463646464656466646764686469647064716472647364746475647664776478647964806481648264836484648564866487648864896490649164926493649464956496649764986499650065016502650365046505650665076508650965106511651265136514651565166517651865196520652165226523652465256526652765286529653065316532653365346535653665376538653965406541654265436544654565466547654865496550655165526553655465556556655765586559656065616562656365646565656665676568656965706571657265736574657565766577657865796580658165826583658465856586658765886589659065916592659365946595659665976598659966006601660266036604660566066607660866096610661166126613661466156616661766186619662066216622662366246625662666276628662966306631663266336634663566366637663866396640664166426643664466456646664766486649665066516652665366546655665666576658665966606661666266636664666566666667666866696670667166726673667466756676667766786679668066816682668366846685668666876688668966906691669266936694669566966697669866996700670167026703670467056706670767086709671067116712671367146715671667176718671967206721672267236724672567266727672867296730673167326733673467356736673767386739674067416742674367446745674667476748674967506751675267536754675567566757675867596760676167626763676467656766676767686769677067716772677367746775677667776778677967806781678267836784678567866787678867896790679167926793679467956796679767986799680068016802680368046805680668076808680968106811681268136814681568166817681868196820682168226823682468256826682768286829683068316832683368346835683668376838683968406841684268436844684568466847684868496850685168526853685468556856685768586859686068616862686368646865686668676868686968706871687268736874687568766877687868796880688168826883688468856886688768886889689068916892689368946895689668976898689969006901690269036904690569066907690869096910691169126913691469156916691769186919692069216922692369246925692669276928692969306931693269336934693569366937693869396940694169426943694469456946694769486949695069516952695369546955695669576958695969606961696269636964696569666967696869696970697169726973697469756976697769786979698069816982698369846985698669876988698969906991699269936994699569966997699869997000700170027003700470057006700770087009701070117012701370147015701670177018701970207021702270237024702570267027702870297030703170327033703470357036703770387039704070417042704370447045704670477048704970507051705270537054705570567057705870597060706170627063706470657066706770687069707070717072707370747075707670777078707970807081708270837084708570867087708870897090709170927093709470957096709770987099710071017102710371047105710671077108710971107111711271137114711571167117711871197120712171227123712471257126712771287129713071317132713371347135713671377138713971407141714271437144714571467147714871497150715171527153715471557156715771587159716071617162716371647165716671677168716971707171717271737174717571767177717871797180718171827183718471857186718771887189719071917192719371947195719671977198719972007201720272037204720572067207720872097210721172127213721472157216721772187219722072217222722372247225722672277228722972307231723272337234723572367237723872397240724172427243724472457246724772487249725072517252725372547255725672577258725972607261726272637264726572667267726872697270727172727273727472757276727772787279728072817282728372847285728672877288728972907291729272937294729572967297729872997300730173027303730473057306730773087309731073117312731373147315731673177318731973207321732273237324732573267327732873297330733173327333733473357336733773387339734073417342734373447345734673477348734973507351735273537354735573567357735873597360736173627363736473657366736773687369737073717372737373747375737673777378737973807381738273837384738573867387738873897390739173927393739473957396739773987399740074017402740374047405740674077408740974107411741274137414741574167417741874197420742174227423742474257426742774287429743074317432743374347435743674377438743974407441744274437444744574467447744874497450745174527453745474557456745774587459746074617462746374647465746674677468746974707471747274737474747574767477747874797480748174827483748474857486748774887489749074917492749374947495749674977498749975007501750275037504750575067507750875097510751175127513751475157516751775187519752075217522752375247525752675277528752975307531753275337534753575367537753875397540754175427543754475457546754775487549755075517552755375547555755675577558755975607561756275637564756575667567756875697570757175727573757475757576757775787579758075817582758375847585758675877588758975907591759275937594759575967597759875997600760176027603760476057606760776087609761076117612761376147615761676177618761976207621762276237624762576267627762876297630763176327633763476357636763776387639764076417642764376447645764676477648764976507651765276537654765576567657765876597660766176627663766476657666766776687669767076717672767376747675767676777678767976807681768276837684768576867687768876897690769176927693769476957696769776987699770077017702770377047705770677077708770977107711771277137714771577167717771877197720772177227723772477257726772777287729773077317732773377347735773677377738773977407741774277437744774577467747774877497750775177527753775477557756775777587759776077617762776377647765776677677768776977707771777277737774777577767777777877797780778177827783778477857786778777887789779077917792779377947795779677977798779978007801780278037804780578067807780878097810781178127813781478157816781778187819782078217822782378247825782678277828782978307831783278337834783578367837783878397840784178427843784478457846784778487849785078517852785378547855785678577858785978607861786278637864786578667867786878697870787178727873787478757876787778787879788078817882788378847885788678877888788978907891789278937894789578967897789878997900790179027903790479057906790779087909791079117912791379147915791679177918791979207921792279237924792579267927792879297930793179327933793479357936793779387939794079417942794379447945794679477948794979507951795279537954795579567957795879597960796179627963796479657966796779687969797079717972797379747975797679777978797979807981798279837984798579867987798879897990799179927993799479957996799779987999800080018002800380048005800680078008800980108011801280138014801580168017801880198020802180228023802480258026802780288029803080318032803380348035803680378038803980408041804280438044804580468047804880498050805180528053805480558056805780588059806080618062806380648065806680678068806980708071807280738074807580768077807880798080808180828083808480858086808780888089809080918092809380948095809680978098809981008101810281038104810581068107810881098110811181128113811481158116811781188119812081218122812381248125812681278128812981308131813281338134813581368137813881398140814181428143814481458146814781488149815081518152815381548155815681578158815981608161816281638164816581668167816881698170817181728173817481758176817781788179818081818182818381848185818681878188818981908191819281938194819581968197819881998200820182028203820482058206820782088209821082118212821382148215821682178218821982208221822282238224822582268227822882298230823182328233823482358236823782388239824082418242824382448245824682478248824982508251825282538254825582568257825882598260826182628263826482658266826782688269827082718272827382748275827682778278827982808281828282838284828582868287828882898290829182928293829482958296829782988299830083018302830383048305830683078308830983108311831283138314831583168317831883198320832183228323832483258326832783288329833083318332833383348335833683378338833983408341834283438344834583468347834883498350835183528353835483558356835783588359836083618362836383648365836683678368836983708371837283738374837583768377837883798380838183828383838483858386838783888389839083918392839383948395839683978398839984008401840284038404840584068407840884098410841184128413841484158416841784188419842084218422842384248425842684278428842984308431843284338434843584368437843884398440844184428443844484458446844784488449845084518452845384548455845684578458845984608461846284638464846584668467846884698470847184728473847484758476847784788479848084818482848384848485848684878488848984908491849284938494849584968497849884998500850185028503850485058506850785088509851085118512851385148515851685178518851985208521852285238524852585268527852885298530853185328533853485358536853785388539854085418542854385448545854685478548854985508551855285538554855585568557855885598560856185628563856485658566856785688569857085718572857385748575857685778578857985808581858285838584858585868587858885898590859185928593859485958596859785988599860086018602860386048605860686078608860986108611861286138614861586168617861886198620862186228623862486258626862786288629863086318632863386348635863686378638863986408641864286438644864586468647864886498650865186528653865486558656865786588659866086618662866386648665866686678668866986708671867286738674867586768677867886798680868186828683868486858686868786888689869086918692869386948695869686978698869987008701870287038704870587068707870887098710871187128713871487158716871787188719872087218722872387248725872687278728872987308731873287338734873587368737873887398740874187428743874487458746874787488749875087518752875387548755875687578758875987608761876287638764876587668767876887698770877187728773877487758776877787788779878087818782878387848785878687878788878987908791879287938794879587968797879887998800880188028803880488058806880788088809881088118812881388148815881688178818881988208821882288238824882588268827882888298830883188328833883488358836883788388839884088418842884388448845884688478848884988508851885288538854885588568857885888598860886188628863886488658866886788688869887088718872887388748875887688778878887988808881888288838884888588868887888888898890889188928893889488958896889788988899890089018902890389048905890689078908890989108911891289138914891589168917891889198920892189228923892489258926892789288929893089318932893389348935893689378938893989408941894289438944894589468947894889498950895189528953895489558956895789588959896089618962896389648965896689678968896989708971897289738974897589768977897889798980898189828983898489858986898789888989899089918992899389948995899689978998899990009001900290039004900590069007900890099010901190129013901490159016901790189019902090219022902390249025902690279028902990309031903290339034903590369037903890399040904190429043904490459046904790489049905090519052905390549055905690579058905990609061906290639064906590669067906890699070907190729073907490759076907790789079908090819082908390849085908690879088908990909091909290939094909590969097909890999100910191029103910491059106910791089109911091119112911391149115911691179118911991209121912291239124912591269127912891299130913191329133913491359136913791389139914091419142914391449145914691479148914991509151915291539154915591569157915891599160916191629163916491659166916791689169917091719172917391749175917691779178917991809181918291839184918591869187918891899190919191929193919491959196919791989199920092019202920392049205920692079208920992109211921292139214921592169217921892199220922192229223922492259226922792289229923092319232923392349235923692379238923992409241924292439244924592469247924892499250925192529253925492559256925792589259926092619262926392649265926692679268926992709271927292739274927592769277927892799280928192829283928492859286928792889289929092919292929392949295929692979298929993009301930293039304930593069307930893099310931193129313931493159316931793189319932093219322932393249325932693279328932993309331933293339334933593369337933893399340934193429343934493459346934793489349935093519352935393549355935693579358935993609361936293639364936593669367936893699370937193729373937493759376937793789379938093819382938393849385938693879388938993909391939293939394939593969397939893999400940194029403940494059406940794089409941094119412941394149415941694179418941994209421942294239424942594269427942894299430943194329433943494359436943794389439944094419442944394449445944694479448944994509451945294539454945594569457945894599460946194629463946494659466946794689469947094719472947394749475947694779478947994809481948294839484948594869487948894899490949194929493949494959496949794989499950095019502950395049505950695079508950995109511951295139514951595169517951895199520952195229523952495259526952795289529953095319532953395349535953695379538953995409541954295439544954595469547954895499550955195529553955495559556955795589559956095619562956395649565956695679568956995709571957295739574957595769577957895799580958195829583958495859586958795889589959095919592959395949595959695979598959996009601960296039604960596069607960896099610961196129613961496159616961796189619962096219622962396249625962696279628962996309631963296339634963596369637963896399640964196429643964496459646964796489649965096519652965396549655965696579658965996609661966296639664966596669667966896699670967196729673967496759676967796789679968096819682968396849685968696879688968996909691969296939694969596969697969896999700970197029703970497059706970797089709971097119712971397149715971697179718971997209721972297239724972597269727972897299730973197329733973497359736973797389739974097419742974397449745974697479748974997509751975297539754975597569757975897599760976197629763976497659766976797689769977097719772977397749775977697779778977997809781978297839784978597869787978897899790979197929793979497959796979797989799980098019802980398049805980698079808980998109811981298139814981598169817981898199820982198229823982498259826982798289829983098319832983398349835983698379838983998409841984298439844984598469847984898499850985198529853985498559856985798589859986098619862986398649865986698679868986998709871987298739874987598769877987898799880988198829883988498859886988798889889989098919892989398949895989698979898989999009901990299039904990599069907990899099910991199129913991499159916991799189919992099219922992399249925992699279928992999309931993299339934993599369937993899399940994199429943994499459946994799489949995099519952995399549955995699579958995999609961996299639964996599669967996899699970997199729973997499759976997799789979998099819982998399849985998699879988998999909991999299939994999599969997999899991000010001100021000310004100051000610007100081000910010100111001210013100141001510016100171001810019100201002110022100231002410025100261002710028100291003010031100321003310034100351003610037100381003910040100411004210043100441004510046100471004810049100501005110052100531005410055100561005710058100591006010061100621006310064100651006610067100681006910070100711007210073100741007510076100771007810079100801008110082100831008410085100861008710088100891009010091100921009310094100951009610097100981009910100101011010210103101041010510106101071010810109101101011110112101131011410115101161011710118101191012010121101221012310124101251012610127101281012910130101311013210133101341013510136101371013810139101401014110142101431014410145101461014710148101491015010151101521015310154101551015610157101581015910160101611016210163101641016510166101671016810169101701017110172101731017410175101761017710178101791018010181101821018310184101851018610187101881018910190101911019210193101941019510196101971019810199102001020110202102031020410205102061020710208102091021010211102121021310214102151021610217102181021910220102211022210223102241022510226102271022810229102301023110232102331023410235102361023710238102391024010241102421024310244102451024610247102481024910250102511025210253102541025510256102571025810259102601026110262102631026410265102661026710268102691027010271102721027310274102751027610277102781027910280102811028210283102841028510286102871028810289102901029110292102931029410295102961029710298102991030010301103021030310304103051030610307103081030910310103111031210313103141031510316103171031810319103201032110322103231032410325103261032710328103291033010331103321033310334103351033610337103381033910340103411034210343103441034510346103471034810349103501035110352103531035410355103561035710358103591036010361103621036310364103651036610367103681036910370103711037210373103741037510376103771037810379103801038110382103831038410385103861038710388103891039010391103921039310394103951039610397103981039910400104011040210403104041040510406104071040810409104101041110412104131041410415104161041710418104191042010421104221042310424104251042610427104281042910430104311043210433104341043510436104371043810439104401044110442104431044410445104461044710448104491045010451104521045310454104551045610457104581045910460104611046210463104641046510466104671046810469104701047110472104731047410475104761047710478104791048010481104821048310484104851048610487104881048910490104911049210493104941049510496104971049810499105001050110502105031050410505105061050710508105091051010511105121051310514105151051610517105181051910520105211052210523105241052510526105271052810529105301053110532105331053410535105361053710538105391054010541105421054310544105451054610547105481054910550105511055210553105541055510556105571055810559105601056110562105631056410565105661056710568105691057010571105721057310574105751057610577105781057910580105811058210583105841058510586105871058810589105901059110592105931059410595105961059710598105991060010601106021060310604106051060610607106081060910610106111061210613106141061510616106171061810619106201062110622106231062410625106261062710628106291063010631106321063310634106351063610637106381063910640106411064210643106441064510646106471064810649106501065110652106531065410655106561065710658106591066010661106621066310664106651066610667106681066910670106711067210673106741067510676106771067810679106801068110682106831068410685106861068710688106891069010691106921069310694106951069610697106981069910700107011070210703107041070510706107071070810709107101071110712107131071410715107161071710718107191072010721107221072310724107251072610727107281072910730107311073210733107341073510736107371073810739107401074110742107431074410745107461074710748107491075010751107521075310754107551075610757107581075910760107611076210763107641076510766107671076810769107701077110772107731077410775107761077710778107791078010781107821078310784107851078610787107881078910790107911079210793107941079510796107971079810799108001080110802108031080410805108061080710808108091081010811108121081310814108151081610817108181081910820108211082210823108241082510826108271082810829108301083110832108331083410835108361083710838108391084010841108421084310844108451084610847108481084910850108511085210853108541085510856108571085810859108601086110862108631086410865108661086710868108691087010871108721087310874108751087610877108781087910880108811088210883108841088510886108871088810889108901089110892108931089410895108961089710898108991090010901109021090310904109051090610907109081090910910109111091210913109141091510916109171091810919109201092110922109231092410925109261092710928109291093010931109321093310934109351093610937109381093910940109411094210943109441094510946109471094810949109501095110952109531095410955109561095710958109591096010961109621096310964109651096610967109681096910970109711097210973109741097510976109771097810979109801098110982109831098410985109861098710988109891099010991109921099310994109951099610997109981099911000110011100211003110041100511006110071100811009110101101111012110131101411015110161101711018110191102011021110221102311024110251102611027110281102911030110311103211033110341103511036110371103811039110401104111042110431104411045110461104711048110491105011051110521105311054110551105611057110581105911060110611106211063110641106511066110671106811069110701107111072110731107411075110761107711078110791108011081110821108311084110851108611087110881108911090110911109211093110941109511096110971109811099111001110111102111031110411105111061110711108111091111011111111121111311114111151111611117111181111911120111211112211123111241112511126111271112811129111301113111132111331113411135111361113711138111391114011141111421114311144111451114611147111481114911150111511115211153111541115511156111571115811159111601116111162111631116411165111661116711168111691117011171111721117311174111751117611177111781117911180111811118211183111841118511186111871118811189111901119111192111931119411195111961119711198111991120011201112021120311204112051120611207112081120911210112111121211213112141121511216112171121811219112201122111222112231122411225112261122711228112291123011231112321123311234112351123611237112381123911240112411124211243112441124511246112471124811249112501125111252112531125411255112561125711258112591126011261112621126311264112651126611267112681126911270112711127211273112741127511276112771127811279112801128111282112831128411285112861128711288112891129011291112921129311294112951129611297112981129911300113011130211303113041130511306113071130811309113101131111312113131131411315113161131711318113191132011321113221132311324113251132611327113281132911330113311133211333113341133511336113371133811339113401134111342113431134411345113461134711348113491135011351113521135311354113551135611357113581135911360113611136211363113641136511366113671136811369113701137111372113731137411375113761137711378113791138011381113821138311384113851138611387113881138911390113911139211393113941139511396113971139811399114001140111402114031140411405114061140711408114091141011411114121141311414114151141611417114181141911420114211142211423114241142511426114271142811429114301143111432114331143411435114361143711438114391144011441114421144311444114451144611447114481144911450114511145211453114541145511456114571145811459114601146111462114631146411465114661146711468114691147011471114721147311474114751147611477114781147911480114811148211483114841148511486114871148811489114901149111492114931149411495114961149711498114991150011501115021150311504115051150611507115081150911510115111151211513115141151511516115171151811519115201152111522115231152411525115261152711528115291153011531115321153311534115351153611537115381153911540115411154211543115441154511546115471154811549115501155111552115531155411555115561155711558115591156011561115621156311564115651156611567115681156911570115711157211573115741157511576115771157811579115801158111582115831158411585115861158711588115891159011591115921159311594115951159611597115981159911600116011160211603116041160511606116071160811609116101161111612116131161411615116161161711618116191162011621116221162311624116251162611627116281162911630116311163211633116341163511636116371163811639116401164111642116431164411645116461164711648116491165011651116521165311654116551165611657116581165911660116611166211663116641166511666116671166811669116701167111672116731167411675116761167711678116791168011681116821168311684116851168611687116881168911690116911169211693116941169511696116971169811699117001170111702117031170411705117061170711708117091171011711117121171311714117151171611717117181171911720117211172211723117241172511726117271172811729117301173111732117331173411735117361173711738117391174011741117421174311744117451174611747117481174911750117511175211753117541175511756117571175811759117601176111762117631176411765117661176711768117691177011771117721177311774117751177611777117781177911780117811178211783117841178511786117871178811789117901179111792117931179411795117961179711798117991180011801118021180311804118051180611807118081180911810118111181211813118141181511816118171181811819118201182111822118231182411825118261182711828118291183011831118321183311834118351183611837118381183911840118411184211843118441184511846118471184811849118501185111852118531185411855118561185711858118591186011861118621186311864118651186611867118681186911870118711187211873118741187511876118771187811879118801188111882118831188411885118861188711888118891189011891118921189311894118951189611897118981189911900119011190211903119041190511906119071190811909119101191111912119131191411915119161191711918119191192011921119221192311924119251192611927119281192911930119311193211933119341193511936119371193811939119401194111942119431194411945119461194711948119491195011951119521195311954119551195611957119581195911960119611196211963119641196511966119671196811969119701197111972119731197411975119761197711978119791198011981119821198311984119851198611987119881198911990119911199211993119941199511996119971199811999120001200112002120031200412005120061200712008120091201012011120121201312014120151201612017120181201912020120211202212023120241202512026120271202812029120301203112032120331203412035
  1. % Why direct style instead of continuation passing style?
  2. %% Student project ideas:
  3. %% * high-level optimizations like procedure inlining, etc.
  4. %% * closure optimization
  5. %% * adding letrec to the language
  6. %% (Thought: in the book and regular course, replace top-level defines
  7. %% with letrec.)
  8. %% * alternative back ends (ARM, LLVM)
  9. %% * alternative calling convention (a la Dybvig)
  10. %% * lazy evaluation
  11. %% * gradual typing
  12. %% * continuations (frames in heap a la SML or segmented stack a la Dybvig)
  13. %% * exceptions
  14. %% * self hosting
  15. %% * I/O
  16. %% * foreign function interface
  17. %% * quasi-quote and unquote
  18. %% * macros (too difficult?)
  19. %% * alternative garbage collector
  20. %% * alternative register allocator
  21. %% * parametric polymorphism
  22. %% * type classes (too difficulty?)
  23. %% * loops (too easy? combine with something else?)
  24. %% * loop optimization (fusion, etc.)
  25. %% * deforestation
  26. %% * records and subtyping
  27. %% * object-oriented features
  28. %% - objects, object types, and structural subtyping (e.g. Abadi & Cardelli)
  29. %% - class-based objects and nominal subtyping (e.g. Featherweight Java)
  30. %% * multi-threading, fork join, futures, implicit parallelism
  31. %% * dataflow analysis, type analysis and specialization
  32. \documentclass[11pt]{book}
  33. \usepackage[T1]{fontenc}
  34. \usepackage[utf8]{inputenc}
  35. \usepackage{lmodern}
  36. \usepackage{hyperref}
  37. \usepackage{graphicx}
  38. \usepackage[english]{babel}
  39. \usepackage{listings}
  40. \usepackage{amsmath}
  41. \usepackage{amsthm}
  42. \usepackage{amssymb}
  43. \usepackage{natbib}
  44. \usepackage{stmaryrd}
  45. \usepackage{xypic}
  46. \usepackage{semantic}
  47. \usepackage{wrapfig}
  48. \usepackage{tcolorbox}
  49. \usepackage{multirow}
  50. \usepackage{color}
  51. \usepackage{upquote}
  52. \usepackage{makeidx}
  53. \makeindex
  54. \definecolor{lightgray}{gray}{1}
  55. \newcommand{\black}[1]{{\color{black} #1}}
  56. %\newcommand{\gray}[1]{{\color{lightgray} #1}}
  57. \newcommand{\gray}[1]{{\color{gray} #1}}
  58. %% For pictures
  59. \usepackage{tikz}
  60. \usetikzlibrary{arrows.meta}
  61. \tikzset{baseline=(current bounding box.center), >/.tip={Triangle[scale=1.4]}}
  62. % Computer Modern is already the default. -Jeremy
  63. %\renewcommand{\ttdefault}{cmtt}
  64. \definecolor{comment-red}{rgb}{0.8,0,0}
  65. \if01
  66. \newcommand{\rn}[1]{{\color{comment-red}{(RRN: #1)}}}
  67. \newcommand{\margincomment}[1]{\marginpar{\color{comment-red}\tiny #1}}
  68. \else
  69. \newcommand{\rn}[1]{}
  70. \newcommand{\margincomment}[1]{}
  71. \fi
  72. \lstset{%
  73. language=Lisp,
  74. basicstyle=\ttfamily\small,
  75. morekeywords={seq,assign,program,block,define,lambda,match,goto,if,else,then,struct,Integer,Boolean,Vector,Void,Any,while,begin,define,public,override,class},
  76. deletekeywords={read,mapping,vector},
  77. escapechar=|,
  78. columns=flexible,
  79. moredelim=[is][\color{red}]{~}{~},
  80. showstringspaces=false
  81. }
  82. \newtheorem{theorem}{Theorem}
  83. \newtheorem{lemma}[theorem]{Lemma}
  84. \newtheorem{corollary}[theorem]{Corollary}
  85. \newtheorem{proposition}[theorem]{Proposition}
  86. \newtheorem{constraint}[theorem]{Constraint}
  87. \newtheorem{definition}[theorem]{Definition}
  88. \newtheorem{exercise}[theorem]{Exercise}
  89. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  90. % 'dedication' environment: To add a dedication paragraph at the start of book %
  91. % Source: http://www.tug.org/pipermail/texhax/2010-June/015184.html %
  92. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  93. \newenvironment{dedication}
  94. {
  95. \cleardoublepage
  96. \thispagestyle{empty}
  97. \vspace*{\stretch{1}}
  98. \hfill\begin{minipage}[t]{0.66\textwidth}
  99. \raggedright
  100. }
  101. {
  102. \end{minipage}
  103. \vspace*{\stretch{3}}
  104. \clearpage
  105. }
  106. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  107. % Chapter quote at the start of chapter %
  108. % Source: http://tex.stackexchange.com/a/53380 %
  109. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  110. \makeatletter
  111. \renewcommand{\@chapapp}{}% Not necessary...
  112. \newenvironment{chapquote}[2][2em]
  113. {\setlength{\@tempdima}{#1}%
  114. \def\chapquote@author{#2}%
  115. \parshape 1 \@tempdima \dimexpr\textwidth-2\@tempdima\relax%
  116. \itshape}
  117. {\par\normalfont\hfill--\ \chapquote@author\hspace*{\@tempdima}\par\bigskip}
  118. \makeatother
  119. \input{defs}
  120. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  121. \title{\Huge \textbf{Essentials of Compilation} \\
  122. \huge The Incremental, Nano-Pass Approach}
  123. \author{\textsc{Jeremy G. Siek} \\
  124. %\thanks{\url{http://homes.soic.indiana.edu/jsiek/}} \\
  125. Indiana University \\
  126. \\
  127. with contributions from: \\
  128. Carl Factora \\
  129. Andre Kuhlenschmidt \\
  130. Ryan R. Newton \\
  131. Ryan Scott \\
  132. Cameron Swords \\
  133. Michael M. Vitousek \\
  134. Michael Vollmer
  135. }
  136. \begin{document}
  137. \frontmatter
  138. \maketitle
  139. \begin{dedication}
  140. This book is dedicated to the programming language wonks at Indiana
  141. University.
  142. \end{dedication}
  143. \tableofcontents
  144. \listoffigures
  145. %\listoftables
  146. \mainmatter
  147. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  148. \chapter*{Preface}
  149. The tradition of compiler writing at Indiana University goes back to
  150. research and courses on programming languages by Professor Daniel
  151. Friedman in the 1970's and 1980's. Friedman conducted research on lazy
  152. evaluation~\citep{Friedman:1976aa} in the context of
  153. Lisp~\citep{McCarthy:1960dz} and then studied
  154. continuations~\citep{Felleisen:kx} and
  155. macros~\citep{Kohlbecker:1986dk} in the context of the
  156. Scheme~\citep{Sussman:1975ab}, a dialect of Lisp. One of the students
  157. of those courses, Kent Dybvig, went on to build Chez
  158. Scheme~\citep{Dybvig:2006aa}, a production-quality and efficient
  159. compiler for Scheme. After completing his Ph.D. at the University of
  160. North Carolina, he returned to teach at Indiana University.
  161. Throughout the 1990's and 2000's, Professor Dybvig continued
  162. development of Chez Scheme and taught the compiler course.
  163. The compiler course evolved to incorporate novel pedagogical ideas
  164. while also including elements of effective real-world compilers. One
  165. of Friedman's ideas was to split the compiler into many small
  166. ``passes'' so that the code for each pass would be easy to understood
  167. in isolation. In contrast, most compilers of the time were organized
  168. into only a few monolithic passes for reasons of compile-time
  169. efficiency. Another idea, called ``the game'', was to test the code
  170. generated by each pass on interpreters for each intermediate language,
  171. thereby helping to pinpoint errors in individual passes.
  172. %
  173. Dybvig, with later help from his students Dipanwita Sarkar and Andrew
  174. Keep, developed infrastructure to support this approach and evolved
  175. the course, first to use smaller micro-passes and then into even
  176. smaller nano-passes~\citep{Sarkar:2004fk,Keep:2012aa}. I was a student
  177. in this compiler course in the early 2000's as part of my
  178. Ph.D. studies at Indiana University. Needless to say, I enjoyed the
  179. course immensely!
  180. During that time, another graduate student named Abdulaziz Ghuloum
  181. observed that the front-to-back organization of the course made it
  182. difficult for students to understand the rationale for the compiler
  183. design. Ghuloum proposed an incremental approach in which the students
  184. build the compiler in stages; they start by implementing a complete
  185. compiler for a very small subset of the input language and in each
  186. subsequent stage they add a language feature and add or modify passes
  187. to handle the new feature~\citep{Ghuloum:2006bh}. In this way, the
  188. students see how the language features motivate aspects of the
  189. compiler design.
  190. After graduating from Indiana University in 2005, I went on to teach
  191. at the University of Colorado. I adapted the nano-pass and incremental
  192. approaches to compiling a subset of the Python
  193. language~\citep{Siek:2012ab}. Python and Scheme are quite different
  194. on the surface but there is a large overlap in the compiler techniques
  195. required for the two languages. Thus, I was able to teach much of the
  196. same content from the Indiana compiler course. I very much enjoyed
  197. teaching the course organized in this way, and even better, many of
  198. the students learned a lot and got excited about compilers.
  199. I returned to Indiana University in 2013. In my absence the compiler
  200. course had switched from the front-to-back organization to a
  201. back-to-front organization~\cite{Dybvig:2010aa}. Seeing how well the
  202. incremental approach worked at Colorado, I started porting and
  203. adapting the structure of the Colorado course back into the land of
  204. Scheme. In the meantime Indiana University had moved on from Scheme to
  205. Racket~\citep{plt-tr}, so the course is now about compiling a subset
  206. of Racket (and Typed Racket) to the x86 assembly language.
  207. This is the textbook for the incremental version of the compiler
  208. course at Indiana University (Spring 2016 - present). With this book
  209. I hope to make the Indiana compiler course available to people that
  210. have not had the chance to study compilers at Indiana University.
  211. %% I have captured what
  212. %% I think are the most important topics from \cite{Dybvig:2010aa} but
  213. %% have omitted topics that are less interesting conceptually. I have
  214. %% also made simplifications to reduce complexity. In this way, this
  215. %% book leans more towards pedagogy than towards the efficiency of the
  216. %% generated code. Also, the book differs in places where we I the
  217. %% opportunity to make the topics more fun, such as in relating register
  218. %% allocation to Sudoku (Chapter~\ref{ch:register-allocation-r1}).
  219. \section*{Prerequisites}
  220. The material in this book is challenging but rewarding. It is meant to
  221. prepare students for a lifelong career in programming languages.
  222. The book uses the Racket language both for the implementation of the
  223. compiler and for the language that is compiled, so a student should be
  224. proficient with Racket (or Scheme) prior to reading this book. There
  225. are many excellent resources for learning Scheme and
  226. Racket~\citep{Dybvig:1987aa,Abelson:1996uq,Friedman:1996aa,Felleisen:2001aa,Felleisen:2013aa,Flatt:2014aa}.
  227. It is helpful but not necessary for the student to have prior exposure
  228. to the x86 assembly language~\citep{Intel:2015aa}, as one might obtain
  229. from a computer systems
  230. course~\citep{Bryant:2010aa}. This book introduces the
  231. parts of x86-64 assembly language that are needed.
  232. %
  233. We follow the System V calling
  234. conventions~\citep{Bryant:2005aa,Matz:2013aa}, which means that the
  235. assembly code that we generate will work properly with our runtime
  236. system (written in C) when it is compiled using the GNU C compiler
  237. (\code{gcc}) on the Linux and MacOS operating systems. (Minor
  238. adjustments are needed for MacOS which we note as they arise.)
  239. %
  240. When running on the Microsoft Windows operating system, the GNU C
  241. compiler follows the Microsoft x64 calling
  242. convention~\citep{Microsoft:2018aa,Microsoft:2020aa}. So the assembly
  243. code that we generate will \emph{not} work properly with our runtime
  244. system on Windows. One option to consider for using a Windows computer
  245. is to run a virtual machine with Linux as the guest operating system.
  246. %\section*{Structure of book}
  247. % You might want to add short description about each chapter in this book.
  248. %\section*{About the companion website}
  249. %The website\footnote{\url{https://github.com/amberj/latex-book-template}} for %this file contains:
  250. %\begin{itemize}
  251. % \item A link to (freely downlodable) latest version of this document.
  252. % \item Link to download LaTeX source for this document.
  253. % \item Miscellaneous material (e.g. suggested readings etc).
  254. %\end{itemize}
  255. \section*{Acknowledgments}
  256. Many people have contributed to the ideas, techniques, and
  257. organization of this book and have taught courses based on it. Many
  258. of the compiler design decisions in this book are drawn from the
  259. assignment descriptions of \cite{Dybvig:2010aa}. We also would like
  260. to thank John Clements, Bor-Yuh Evan Chang, Daniel P. Friedman, Ronald
  261. Garcia, Abdulaziz Ghuloum, Jay McCarthy, Nate Nystrom, Dipanwita
  262. Sarkar, Oscar Waddell, and Michael Wollowski.
  263. \mbox{}\\
  264. \noindent Jeremy G. Siek \\
  265. \noindent \url{http://homes.soic.indiana.edu/jsiek} \\
  266. %\noindent Spring 2016
  267. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  268. \chapter{Preliminaries}
  269. \label{ch:trees-recur}
  270. In this chapter we review the basic tools that are needed to implement
  271. a compiler. Programs are typically input by a programmer as text,
  272. i.e., a sequence of characters. The program-as-text representation is
  273. called \emph{concrete syntax}. We use concrete syntax to concisely
  274. write down and talk about programs. Inside the compiler, we use
  275. \emph{abstract syntax trees} (ASTs) to represent programs in a way
  276. that efficiently supports the operations that the compiler needs to
  277. perform.\index{concrete syntax}\index{abstract syntax}\index{abstract
  278. syntax tree}\index{AST}\index{program}\index{parse} The translation
  279. from concrete syntax to abstract syntax is a process called
  280. \emph{parsing}~\citep{Aho:1986qf}. We do not cover the theory and
  281. implementation of parsing in this book. A parser is provided in the
  282. supporting materials for translating from concrete to abstract syntax.
  283. ASTs can be represented in many different ways inside the compiler,
  284. depending on the programming language used to write the compiler.
  285. %
  286. We use Racket's
  287. \href{https://docs.racket-lang.org/guide/define-struct.html}{\code{struct}}
  288. feature to represent ASTs (Section~\ref{sec:ast}). We use grammars to
  289. define the abstract syntax of programming languages
  290. (Section~\ref{sec:grammar}) and pattern matching to inspect individual
  291. nodes in an AST (Section~\ref{sec:pattern-matching}). We use
  292. recursive functions to construct and deconstruct entire ASTs
  293. (Section~\ref{sec:recursion}). This chapter provides an brief
  294. introduction to these ideas. \index{struct}
  295. \section{Abstract Syntax Trees and Racket Structures}
  296. \label{sec:ast}
  297. Compilers use abstract syntax trees to represent programs because they
  298. often need to ask questions like: for a given part of a program, what
  299. kind of language feature is it? What are its sub-parts? Consider the
  300. program on the left and its AST on the right. This program is an
  301. addition and it has two sub-parts, a read operation and a
  302. negation. The negation has another sub-part, the integer constant
  303. \code{8}. By using a tree to represent the program, we can easily
  304. follow the links to go from one part of a program to its sub-parts.
  305. \begin{center}
  306. \begin{minipage}{0.4\textwidth}
  307. \begin{lstlisting}
  308. (+ (read) (- 8))
  309. \end{lstlisting}
  310. \end{minipage}
  311. \begin{minipage}{0.4\textwidth}
  312. \begin{equation}
  313. \begin{tikzpicture}
  314. \node[draw, circle] (plus) at (0 , 0) {\key{+}};
  315. \node[draw, circle] (read) at (-1, -1.5) {{\footnotesize\key{read}}};
  316. \node[draw, circle] (minus) at (1 , -1.5) {$\key{-}$};
  317. \node[draw, circle] (8) at (1 , -3) {\key{8}};
  318. \draw[->] (plus) to (read);
  319. \draw[->] (plus) to (minus);
  320. \draw[->] (minus) to (8);
  321. \end{tikzpicture}
  322. \label{eq:arith-prog}
  323. \end{equation}
  324. \end{minipage}
  325. \end{center}
  326. We use the standard terminology for trees to describe ASTs: each
  327. circle above is called a \emph{node}. The arrows connect a node to its
  328. \emph{children} (which are also nodes). The top-most node is the
  329. \emph{root}. Every node except for the root has a \emph{parent} (the
  330. node it is the child of). If a node has no children, it is a
  331. \emph{leaf} node. Otherwise it is an \emph{internal} node.
  332. \index{node}
  333. \index{children}
  334. \index{root}
  335. \index{parent}
  336. \index{leaf}
  337. \index{internal node}
  338. %% Recall that an \emph{symbolic expression} (S-expression) is either
  339. %% \begin{enumerate}
  340. %% \item an atom, or
  341. %% \item a pair of two S-expressions, written $(e_1 \key{.} e_2)$,
  342. %% where $e_1$ and $e_2$ are each an S-expression.
  343. %% \end{enumerate}
  344. %% An \emph{atom} can be a symbol, such as \code{`hello}, a number, the
  345. %% null value \code{'()}, etc. We can create an S-expression in Racket
  346. %% simply by writing a backquote (called a quasi-quote in Racket)
  347. %% followed by the textual representation of the S-expression. It is
  348. %% quite common to use S-expressions to represent a list, such as $a, b
  349. %% ,c$ in the following way:
  350. %% \begin{lstlisting}
  351. %% `(a . (b . (c . ())))
  352. %% \end{lstlisting}
  353. %% Each element of the list is in the first slot of a pair, and the
  354. %% second slot is either the rest of the list or the null value, to mark
  355. %% the end of the list. Such lists are so common that Racket provides
  356. %% special notation for them that removes the need for the periods
  357. %% and so many parenthesis:
  358. %% \begin{lstlisting}
  359. %% `(a b c)
  360. %% \end{lstlisting}
  361. %% The following expression creates an S-expression that represents AST
  362. %% \eqref{eq:arith-prog}.
  363. %% \begin{lstlisting}
  364. %% `(+ (read) (- 8))
  365. %% \end{lstlisting}
  366. %% When using S-expressions to represent ASTs, the convention is to
  367. %% represent each AST node as a list and to put the operation symbol at
  368. %% the front of the list. The rest of the list contains the children. So
  369. %% in the above case, the root AST node has operation \code{`+} and its
  370. %% two children are \code{`(read)} and \code{`(- 8)}, just as in the
  371. %% diagram \eqref{eq:arith-prog}.
  372. %% To build larger S-expressions one often needs to splice together
  373. %% several smaller S-expressions. Racket provides the comma operator to
  374. %% splice an S-expression into a larger one. For example, instead of
  375. %% creating the S-expression for AST \eqref{eq:arith-prog} all at once,
  376. %% we could have first created an S-expression for AST
  377. %% \eqref{eq:arith-neg8} and then spliced that into the addition
  378. %% S-expression.
  379. %% \begin{lstlisting}
  380. %% (define ast1.4 `(- 8))
  381. %% (define ast1.1 `(+ (read) ,ast1.4))
  382. %% \end{lstlisting}
  383. %% In general, the Racket expression that follows the comma (splice)
  384. %% can be any expression that produces an S-expression.
  385. We define a Racket \code{struct} for each kind of node. For this
  386. chapter we require just two kinds of nodes: one for integer constants
  387. and one for primitive operations. The following is the \code{struct}
  388. definition for integer constants.
  389. \begin{lstlisting}
  390. (struct Int (value))
  391. \end{lstlisting}
  392. An integer node includes just one thing: the integer value.
  393. To create a AST node for the integer $8$, we write \code{(Int 8)}.
  394. \begin{lstlisting}
  395. (define eight (Int 8))
  396. \end{lstlisting}
  397. We say that the value created by \code{(Int 8)} is an
  398. \emph{instance} of the \code{Int} structure.
  399. The following is the \code{struct} definition for primitives operations.
  400. \begin{lstlisting}
  401. (struct Prim (op args))
  402. \end{lstlisting}
  403. A primitive operation node includes an operator symbol \code{op}
  404. and a list of children \code{args}. For example, to create
  405. an AST that negates the number $8$, we write \code{(Prim '- (list eight))}.
  406. \begin{lstlisting}
  407. (define neg-eight (Prim '- (list eight)))
  408. \end{lstlisting}
  409. Primitive operations may have zero or more children. The \code{read}
  410. operator has zero children:
  411. \begin{lstlisting}
  412. (define rd (Prim 'read '()))
  413. \end{lstlisting}
  414. whereas the addition operator has two children:
  415. \begin{lstlisting}
  416. (define ast1.1 (Prim '+ (list rd neg-eight)))
  417. \end{lstlisting}
  418. We have made a design choice regarding the \code{Prim} structure.
  419. Instead of using one structure for many different operations
  420. (\code{read}, \code{+}, and \code{-}), we could have instead defined a
  421. structure for each operation, as follows.
  422. \begin{lstlisting}
  423. (struct Read ())
  424. (struct Add (left right))
  425. (struct Neg (value))
  426. \end{lstlisting}
  427. The reason we choose to use just one structure is that in many parts
  428. of the compiler the code for the different primitive operators is the
  429. same, so we might as well just write that code once, which is enabled
  430. by using a single structure.
  431. When compiling a program such as \eqref{eq:arith-prog}, we need to
  432. know that the operation associated with the root node is addition and
  433. we need to be able to access its two children. Racket provides pattern
  434. matching over structures to support these kinds of queries, as we
  435. see in Section~\ref{sec:pattern-matching}.
  436. In this book, we often write down the concrete syntax of a program
  437. even when we really have in mind the AST because the concrete syntax
  438. is more concise. We recommend that, in your mind, you always think of
  439. programs as abstract syntax trees.
  440. \section{Grammars}
  441. \label{sec:grammar}
  442. \index{integer}
  443. \index{literal}
  444. \index{constant}
  445. A programming language can be thought of as a \emph{set} of programs.
  446. The set is typically infinite (one can always create larger and larger
  447. programs), so one cannot simply describe a language by listing all of
  448. the programs in the language. Instead we write down a set of rules, a
  449. \emph{grammar}, for building programs. Grammars are often used to
  450. define the concrete syntax of a language, but they can also be used to
  451. describe the abstract syntax. We write our rules in a variant of
  452. Backus-Naur Form (BNF)~\citep{Backus:1960aa,Knuth:1964aa}.
  453. \index{Backus-Naur Form}\index{BNF}
  454. As an example, we describe a small language, named $R_0$, that consists of
  455. integers and arithmetic operations.
  456. \index{grammar}
  457. The first grammar rule for the abstract syntax of $R_0$ says that an
  458. instance of the \code{Int} structure is an expression:
  459. \begin{equation}
  460. \Exp ::= \INT{\Int} \label{eq:arith-int}
  461. \end{equation}
  462. %
  463. Each rule has a left-hand-side and a right-hand-side. The way to read
  464. a rule is that if you have an AST node that matches the
  465. right-hand-side, then you can categorize it according to the
  466. left-hand-side.
  467. %
  468. A name such as $\Exp$ that is defined by the grammar rules is a
  469. \emph{non-terminal}. \index{non-terminal}
  470. %
  471. The name $\Int$ is a also a non-terminal, but instead of defining it
  472. with a grammar rule, we define it with the following explanation. We
  473. make the simplifying design decision that all of the languages in this
  474. book only handle machine-representable integers. On most modern
  475. machines this corresponds to integers represented with 64-bits, i.e.,
  476. the in range $-2^{63}$ to $2^{63}-1$. We restrict this range further
  477. to match the Racket \texttt{fixnum} datatype, which allows 63-bit
  478. integers on a 64-bit machine. So an $\Int$ is a sequence of decimals
  479. ($0$ to $9$), possibly starting with $-$ (for negative integers), such
  480. that the sequence of decimals represent an integer in range $-2^{62}$
  481. to $2^{62}-1$.
  482. The second grammar rule is the \texttt{read} operation that receives
  483. an input integer from the user of the program.
  484. \begin{equation}
  485. \Exp ::= \READ{} \label{eq:arith-read}
  486. \end{equation}
  487. The third rule says that, given an $\Exp$ node, you can build another
  488. $\Exp$ node by negating it.
  489. \begin{equation}
  490. \Exp ::= \NEG{\Exp} \label{eq:arith-neg}
  491. \end{equation}
  492. Symbols in typewriter font such as \key{-} and \key{read} are
  493. \emph{terminal} symbols and must literally appear in the program for
  494. the rule to be applicable.
  495. \index{terminal}
  496. We can apply these rules to build ASTs in the $R_0$ language. By rule
  497. \eqref{eq:arith-int}, \texttt{(Int 8)} is an $\Exp$, then by rule
  498. \eqref{eq:arith-neg}, the following AST is an $\Exp$.
  499. \begin{center}
  500. \begin{minipage}{0.4\textwidth}
  501. \begin{lstlisting}
  502. (Prim '- (list (Int 8)))
  503. \end{lstlisting}
  504. \end{minipage}
  505. \begin{minipage}{0.25\textwidth}
  506. \begin{equation}
  507. \begin{tikzpicture}
  508. \node[draw, circle] (minus) at (0, 0) {$\text{--}$};
  509. \node[draw, circle] (8) at (0, -1.2) {$8$};
  510. \draw[->] (minus) to (8);
  511. \end{tikzpicture}
  512. \label{eq:arith-neg8}
  513. \end{equation}
  514. \end{minipage}
  515. \end{center}
  516. The next grammar rule defines addition expressions:
  517. \begin{equation}
  518. \Exp ::= \ADD{\Exp}{\Exp} \label{eq:arith-add}
  519. \end{equation}
  520. We can now justify that the AST \eqref{eq:arith-prog} is an $\Exp$ in
  521. $R_0$. We know that \lstinline{(Prim 'read '())} is an $\Exp$ by rule
  522. \eqref{eq:arith-read} and we have already categorized \code{(Prim '-
  523. (list (Int 8)))} as an $\Exp$, so we apply rule \eqref{eq:arith-add}
  524. to show that
  525. \begin{lstlisting}
  526. (Prim '+ (list (Prim 'read '()) (Prim '- (list (Int 8)))))
  527. \end{lstlisting}
  528. is an $\Exp$ in the $R_0$ language.
  529. If you have an AST for which the above rules do not apply, then the
  530. AST is not in $R_0$. For example, the program \code{(- (read) (+ 8))}
  531. is not in $R_0$ because there are no rules for \code{+} with only one
  532. argument, nor for \key{-} with two arguments. Whenever we define a
  533. language with a grammar, the language only includes those programs
  534. that are justified by the rules.
  535. The last grammar rule for $R_0$ states that there is a \code{Program}
  536. node to mark the top of the whole program:
  537. \[
  538. R_0 ::= \PROGRAM{\code{'()}}{\Exp}
  539. \]
  540. The \code{Program} structure is defined as follows
  541. \begin{lstlisting}
  542. (struct Program (info body))
  543. \end{lstlisting}
  544. where \code{body} is an expression. In later chapters, the \code{info}
  545. part will be used to store auxiliary information but for now it is
  546. just the empty list.
  547. It is common to have many grammar rules with the same left-hand side
  548. but different right-hand sides, such as the rules for $\Exp$ in the
  549. grammar of $R_0$. As a short-hand, a vertical bar can be used to
  550. combine several right-hand-sides into a single rule.
  551. We collect all of the grammar rules for the abstract syntax of $R_0$
  552. in Figure~\ref{fig:r0-syntax}. The concrete syntax for $R_0$ is
  553. defined in Figure~\ref{fig:r0-concrete-syntax}.
  554. The \code{read-program} function provided in \code{utilities.rkt} of
  555. the support materials reads a program in from a file (the sequence of
  556. characters in the concrete syntax of Racket) and parses it into an
  557. abstract syntax tree. See the description of \code{read-program} in
  558. Appendix~\ref{appendix:utilities} for more details.
  559. \begin{figure}[tp]
  560. \fbox{
  561. \begin{minipage}{0.96\textwidth}
  562. \[
  563. \begin{array}{rcl}
  564. \begin{array}{rcl}
  565. \Exp &::=& \Int \mid \LP\key{read}\RP \mid \LP\key{-}\;\Exp\RP \mid \LP\key{+} \; \Exp\;\Exp\RP\\
  566. R_0 &::=& \Exp
  567. \end{array}
  568. \end{array}
  569. \]
  570. \end{minipage}
  571. }
  572. \caption{The concrete syntax of $R_0$.}
  573. \label{fig:r0-concrete-syntax}
  574. \end{figure}
  575. \begin{figure}[tp]
  576. \fbox{
  577. \begin{minipage}{0.96\textwidth}
  578. \[
  579. \begin{array}{rcl}
  580. \Exp &::=& \INT{\Int} \mid \READ{} \mid \NEG{\Exp} \\
  581. &\mid& \ADD{\Exp}{\Exp} \\
  582. R_0 &::=& \PROGRAM{\code{'()}}{\Exp}
  583. \end{array}
  584. \]
  585. \end{minipage}
  586. }
  587. \caption{The abstract syntax of $R_0$.}
  588. \label{fig:r0-syntax}
  589. \end{figure}
  590. \section{Pattern Matching}
  591. \label{sec:pattern-matching}
  592. As mentioned in Section~\ref{sec:ast}, compilers often need to access
  593. the parts of an AST node. Racket provides the \texttt{match} form to
  594. access the parts of a structure. Consider the following example and
  595. the output on the right. \index{match} \index{pattern matching}
  596. \begin{center}
  597. \begin{minipage}{0.5\textwidth}
  598. \begin{lstlisting}
  599. (match ast1.1
  600. [(Prim op (list child1 child2))
  601. (print op)])
  602. \end{lstlisting}
  603. \end{minipage}
  604. \vrule
  605. \begin{minipage}{0.25\textwidth}
  606. \begin{lstlisting}
  607. '+
  608. \end{lstlisting}
  609. \end{minipage}
  610. \end{center}
  611. In the above example, the \texttt{match} form takes the AST
  612. \eqref{eq:arith-prog} and binds its parts to the three pattern
  613. variables \texttt{op}, \texttt{child1}, and \texttt{child2}. In
  614. general, a match clause consists of a \emph{pattern} and a
  615. \emph{body}.
  616. \index{pattern}
  617. Patterns are recursively defined to be either a pattern
  618. variable, a structure name followed by a pattern for each of the
  619. structure's arguments, or an S-expression (symbols, lists, etc.).
  620. (See Chapter 12 of The Racket
  621. Guide\footnote{\url{https://docs.racket-lang.org/guide/match.html}}
  622. and Chapter 9 of The Racket
  623. Reference\footnote{\url{https://docs.racket-lang.org/reference/match.html}}
  624. for a complete description of \code{match}.)
  625. %
  626. The body of a match clause may contain arbitrary Racket code. The
  627. pattern variables can be used in the scope of the body, such as
  628. \code{op} in \code{(print op)}.
  629. A \code{match} form may contain several clauses, as in the following
  630. function \code{leaf?} that recognizes when an $R_0$ node is a leaf in
  631. the AST. The \code{match} proceeds through the clauses in order,
  632. checking whether the pattern can match the input AST. The body of the
  633. first clause that matches is executed. The output of \code{leaf?} for
  634. several ASTs is shown on the right.
  635. \begin{center}
  636. \begin{minipage}{0.6\textwidth}
  637. \begin{lstlisting}
  638. (define (leaf? arith)
  639. (match arith
  640. [(Int n) #t]
  641. [(Prim 'read '()) #t]
  642. [(Prim '- (list e1)) #f]
  643. [(Prim '+ (list e1 e2)) #f]))
  644. (leaf? (Prim 'read '()))
  645. (leaf? (Prim '- (list (Int 8))))
  646. (leaf? (Int 8))
  647. \end{lstlisting}
  648. \end{minipage}
  649. \vrule
  650. \begin{minipage}{0.25\textwidth}
  651. \begin{lstlisting}
  652. #t
  653. #f
  654. #t
  655. \end{lstlisting}
  656. \end{minipage}
  657. \end{center}
  658. When writing a \code{match}, we refer to the grammar definition to
  659. identify which non-terminal we are expecting to match against, then we
  660. make sure that 1) we have one clause for each alternative of that
  661. non-terminal and 2) that the pattern in each clause corresponds to the
  662. corresponding right-hand side of a grammar rule. For the \code{match}
  663. in the \code{leaf?} function, we refer to the grammar for $R_0$ in
  664. Figure~\ref{fig:r0-syntax}. The $\Exp$ non-terminal has 4
  665. alternatives, so the \code{match} has 4 clauses. The pattern in each
  666. clause corresponds to the right-hand side of a grammar rule. For
  667. example, the pattern \code{(Prim '+ (list e1 e2))} corresponds to the
  668. right-hand side $\ADD{\Exp}{\Exp}$. When translating from grammars to
  669. patterns, replace non-terminals such as $\Exp$ with pattern variables
  670. of your choice (e.g. \code{e1} and \code{e2}).
  671. \section{Recursive Functions}
  672. \label{sec:recursion}
  673. \index{recursive function}
  674. Programs are inherently recursive. For example, an $R_0$ expression is
  675. often made of smaller expressions. Thus, the natural way to process an
  676. entire program is with a recursive function. As a first example of
  677. such a recursive function, we define \texttt{exp?} below, which takes
  678. an arbitrary value and determines whether or not it is an $R_0$
  679. expression.
  680. %
  681. We say that a function is defined by \emph{structural recursion} when
  682. it is defined using a sequence of match clauses that correspond to a
  683. grammar, and the body of each clause makes a recursive call on each
  684. child node.\footnote{This principle of structuring code according to
  685. the data definition is advocated in the book \emph{How to Design
  686. Programs}\url{http://www.ccs.neu.edu/home/matthias/HtDP2e/}.}.
  687. Below we also define a second function, named \code{R0?}, that
  688. determines whether an AST is an $R_0$ program. In general we can
  689. expect to write one recursive function to handle each non-terminal in
  690. a grammar.\index{structural recursion}
  691. %
  692. \begin{center}
  693. \begin{minipage}{0.7\textwidth}
  694. \begin{lstlisting}
  695. (define (exp? ast)
  696. (match ast
  697. [(Int n) #t]
  698. [(Prim 'read '()) #t]
  699. [(Prim '- (list e)) (exp? e)]
  700. [(Prim '+ (list e1 e2))
  701. (and (exp? e1) (exp? e2))]
  702. [else #f]))
  703. (define (R0? ast)
  704. (match ast
  705. [(Program '() e) (exp? e)]
  706. [else #f]))
  707. (R0? (Program '() ast1.1)
  708. (R0? (Program '()
  709. (Prim '- (list (Prim 'read '())
  710. (Prim '+ (list (Num 8)))))))
  711. \end{lstlisting}
  712. \end{minipage}
  713. \vrule
  714. \begin{minipage}{0.25\textwidth}
  715. \begin{lstlisting}
  716. #t
  717. #f
  718. \end{lstlisting}
  719. \end{minipage}
  720. \end{center}
  721. You may be tempted to merge the two functions into one, like this:
  722. \begin{center}
  723. \begin{minipage}{0.5\textwidth}
  724. \begin{lstlisting}
  725. (define (R0? ast)
  726. (match ast
  727. [(Int n) #t]
  728. [(Prim 'read '()) #t]
  729. [(Prim '- (list e)) (R0? e)]
  730. [(Prim '+ (list e1 e2)) (and (R0? e1) (R0? e2))]
  731. [(Program '() e) (R0? e)]
  732. [else #f]))
  733. \end{lstlisting}
  734. \end{minipage}
  735. \end{center}
  736. %
  737. Sometimes such a trick will save a few lines of code, especially when
  738. it comes to the \code{Program} wrapper. Yet this style is generally
  739. \emph{not} recommended because it can get you into trouble.
  740. %
  741. For example, the above function is subtly wrong:
  742. \lstinline{(R0? (Program '() (Program '() (Int 3))))}
  743. would return true, when it should return false.
  744. \section{Interpreters}
  745. \label{sec:interp-R0}
  746. \index{interpreter}
  747. In general, the intended behavior of a program is defined by the
  748. specification of the language. For example, the Scheme language is
  749. defined in the report by \cite{SPERBER:2009aa}. The Racket language is
  750. defined in its reference manual~\citep{plt-tr}. In this book we use
  751. interpreters to specify each language that we consider. An interpreter
  752. that is designated as the definition of a language is called a
  753. \emph{definitional interpreter}~\citep{reynolds72:_def_interp}.
  754. \index{definitional interpreter} We warm up by creating a definitional
  755. interpreter for the $R_0$ language, which serves as a second example
  756. of structural recursion. The \texttt{interp-R0} function is defined in
  757. Figure~\ref{fig:interp-R0}. The body of the function is a match on the
  758. input program followed by a call to the \lstinline{interp-exp} helper
  759. function, which in turn has one match clause per grammar rule for
  760. $R_0$ expressions.
  761. \begin{figure}[tp]
  762. \begin{lstlisting}
  763. (define (interp-exp e)
  764. (match e
  765. [(Int n) n]
  766. [(Prim 'read '())
  767. (define r (read))
  768. (cond [(fixnum? r) r]
  769. [else (error 'interp-R0 "expected an integer" r)])]
  770. [(Prim '- (list e))
  771. (define v (interp-exp e))
  772. (fx- 0 v)]
  773. [(Prim '+ (list e1 e2))
  774. (define v1 (interp-exp e1))
  775. (define v2 (interp-exp e2))
  776. (fx+ v1 v2)]
  777. ))
  778. (define (interp-R0 p)
  779. (match p
  780. [(Program '() e) (interp-exp e)]
  781. ))
  782. \end{lstlisting}
  783. \caption{Interpreter for the $R_0$ language.}
  784. \label{fig:interp-R0}
  785. \end{figure}
  786. Let us consider the result of interpreting a few $R_0$ programs. The
  787. following program adds two integers.
  788. \begin{lstlisting}
  789. (+ 10 32)
  790. \end{lstlisting}
  791. The result is \key{42}. We wrote the above program in concrete syntax,
  792. whereas the parsed abstract syntax is:
  793. \begin{lstlisting}
  794. (Program '() (Prim '+ (list (Int 10) (Int 32))))
  795. \end{lstlisting}
  796. The next example demonstrates that expressions may be nested within
  797. each other, in this case nesting several additions and negations.
  798. \begin{lstlisting}
  799. (+ 10 (- (+ 12 20)))
  800. \end{lstlisting}
  801. What is the result of the above program?
  802. As mentioned previously, the $R_0$ language does not support
  803. arbitrarily-large integers, but only $63$-bit integers, so we
  804. interpret the arithmetic operations of $R_0$ using fixnum arithmetic
  805. in Racket.
  806. Suppose
  807. \[
  808. n = 999999999999999999
  809. \]
  810. which indeed fits in $63$-bits. What happens when we run the
  811. following program in our interpreter?
  812. \begin{lstlisting}
  813. (+ (+ (+ |$n$| |$n$|) (+ |$n$| |$n$|)) (+ (+ |$n$| |$n$|) (+ |$n$| |$n$|)))))
  814. \end{lstlisting}
  815. It produces an error:
  816. \begin{lstlisting}
  817. fx+: result is not a fixnum
  818. \end{lstlisting}
  819. We establish the convention that if running the definitional
  820. interpreter on a program produces an error, then the meaning of that
  821. program is \emph{unspecified}. That means a compiler for the language
  822. is under no obligations regarding that program; it may or may not
  823. produce an executable, and if it does, that executable can do
  824. anything. This convention applies to the languages defined in this
  825. book, as a way to simplify the student's task of implementing them,
  826. but this convention is not applicable to all programming languages.
  827. \index{unspecified behavior}
  828. Moving on to the last feature of the $R_0$ language, the \key{read}
  829. operation prompts the user of the program for an integer. Recall that
  830. program \eqref{eq:arith-prog} performs a \key{read} and then subtracts
  831. \code{8}. So if we run
  832. \begin{lstlisting}
  833. (interp-R0 (Program '() ast1.1))
  834. \end{lstlisting}
  835. and if the input is \code{50}, then we get the answer to life, the
  836. universe, and everything: \code{42}!\footnote{\emph{The Hitchhiker's
  837. Guide to the Galaxy} by Douglas Adams.}
  838. We include the \key{read} operation in $R_0$ so a clever student
  839. cannot implement a compiler for $R_0$ that simply runs the interpreter
  840. during compilation to obtain the output and then generates the trivial
  841. code to produce the output. (Yes, a clever student did this in the
  842. first instance of this course.)
  843. The job of a compiler is to translate a program in one language into a
  844. program in another language so that the output program behaves the
  845. same way as the input program does according to its definitional
  846. interpreter. This idea is depicted in the following diagram. Suppose
  847. we have two languages, $\mathcal{L}_1$ and $\mathcal{L}_2$, and an
  848. interpreter for each language. Suppose that the compiler translates
  849. program $P_1$ in language $\mathcal{L}_1$ into program $P_2$ in
  850. language $\mathcal{L}_2$. Then interpreting $P_1$ and $P_2$ on their
  851. respective interpreters with input $i$ should yield the same output
  852. $o$.
  853. \begin{equation} \label{eq:compile-correct}
  854. \begin{tikzpicture}[baseline=(current bounding box.center)]
  855. \node (p1) at (0, 0) {$P_1$};
  856. \node (p2) at (3, 0) {$P_2$};
  857. \node (o) at (3, -2.5) {$o$};
  858. \path[->] (p1) edge [above] node {compile} (p2);
  859. \path[->] (p2) edge [right] node {interp-$\mathcal{L}_2$($i$)} (o);
  860. \path[->] (p1) edge [left] node {interp-$\mathcal{L}_1$($i$)} (o);
  861. \end{tikzpicture}
  862. \end{equation}
  863. In the next section we see our first example of a compiler.
  864. \section{Example Compiler: a Partial Evaluator}
  865. \label{sec:partial-evaluation}
  866. In this section we consider a compiler that translates $R_0$ programs
  867. into $R_0$ programs that may be more efficient, that is, this compiler
  868. is an optimizer. This optimizer eagerly computes the parts of the
  869. program that do not depend on any inputs, a process known as
  870. \emph{partial evaluation}~\cite{Jones:1993uq}.
  871. \index{partial evaluation}
  872. For example, given the following program
  873. \begin{lstlisting}
  874. (+ (read) (- (+ 5 3)))
  875. \end{lstlisting}
  876. our compiler will translate it into the program
  877. \begin{lstlisting}
  878. (+ (read) -8)
  879. \end{lstlisting}
  880. Figure~\ref{fig:pe-arith} gives the code for a simple partial
  881. evaluator for the $R_0$ language. The output of the partial evaluator
  882. is an $R_0$ program. In Figure~\ref{fig:pe-arith}, the structural
  883. recursion over $\Exp$ is captured in the \code{pe-exp} function
  884. whereas the code for partially evaluating the negation and addition
  885. operations is factored into two separate helper functions:
  886. \code{pe-neg} and \code{pe-add}. The input to these helper
  887. functions is the output of partially evaluating the children.
  888. \begin{figure}[tp]
  889. \begin{lstlisting}
  890. (define (pe-neg r)
  891. (match r
  892. [(Int n) (Int (fx- 0 n))]
  893. [else (Prim '- (list r))]))
  894. (define (pe-add r1 r2)
  895. (match* (r1 r2)
  896. [((Int n1) (Int n2)) (Int (fx+ n1 n2))]
  897. [(_ _) (Prim '+ (list r1 r2))]))
  898. (define (pe-exp e)
  899. (match e
  900. [(Int n) (Int n)]
  901. [(Prim 'read '()) (Prim 'read '())]
  902. [(Prim '- (list e1)) (pe-neg (pe-exp e1))]
  903. [(Prim '+ (list e1 e2)) (pe-add (pe-exp e1) (pe-exp e2))]
  904. ))
  905. (define (pe-R0 p)
  906. (match p
  907. [(Program '() e) (Program '() (pe-exp e))]
  908. ))
  909. \end{lstlisting}
  910. \caption{A partial evaluator for $R_0$ expressions.}
  911. \label{fig:pe-arith}
  912. \end{figure}
  913. The \texttt{pe-neg} and \texttt{pe-add} functions check whether their
  914. arguments are integers and if they are, perform the appropriate
  915. arithmetic. Otherwise, they create an AST node for the operation
  916. (either negation or addition).
  917. To gain some confidence that the partial evaluator is correct, we can
  918. test whether it produces programs that get the same result as the
  919. input programs. That is, we can test whether it satisfies Diagram
  920. \eqref{eq:compile-correct}. The following code runs the partial
  921. evaluator on several examples and tests the output program. The
  922. \texttt{parse-program} and \texttt{assert} functions are defined in
  923. Appendix~\ref{appendix:utilities}.\\
  924. \begin{minipage}{1.0\textwidth}
  925. \begin{lstlisting}
  926. (define (test-pe p)
  927. (assert "testing pe-R0"
  928. (equal? (interp-R0 p) (interp-R0 (pe-R0 p)))))
  929. (test-pe (parse-program `(program () (+ 10 (- (+ 5 3))))))
  930. (test-pe (parse-program `(program () (+ 1 (+ 3 1)))))
  931. (test-pe (parse-program `(program () (- (+ 3 (- 5))))))
  932. \end{lstlisting}
  933. \end{minipage}
  934. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  935. \chapter{Integers and Variables}
  936. \label{ch:int-exp}
  937. This chapter is about compiling the subset of Racket that includes
  938. integer arithmetic and local variable binding, which we name $R_1$, to
  939. x86-64 assembly code~\citep{Intel:2015aa}. Henceforth we refer
  940. to x86-64 simply as x86. The chapter begins with a description of the
  941. $R_1$ language (Section~\ref{sec:s0}) followed by a description of x86
  942. (Section~\ref{sec:x86}). The x86 assembly language is large, so we
  943. discuss only what is needed for compiling $R_1$. We introduce more of
  944. x86 in later chapters. Once we have introduced $R_1$ and x86, we
  945. reflect on their differences and come up with a plan to break down the
  946. translation from $R_1$ to x86 into a handful of steps
  947. (Section~\ref{sec:plan-s0-x86}). The rest of the sections in this
  948. chapter give detailed hints regarding each step
  949. (Sections~\ref{sec:uniquify-s0} through \ref{sec:patch-s0}). We hope
  950. to give enough hints that the well-prepared reader, together with a
  951. few friends, can implement a compiler from $R_1$ to x86 in a couple
  952. weeks while at the same time leaving room for some fun and creativity.
  953. To give the reader a feeling for the scale of this first compiler, the
  954. instructor solution for the $R_1$ compiler is less than 500 lines of
  955. code.
  956. \section{The $R_1$ Language}
  957. \label{sec:s0}
  958. \index{variable}
  959. The $R_1$ language extends the $R_0$ language with variable
  960. definitions. The concrete syntax of the $R_1$ language is defined by
  961. the grammar in Figure~\ref{fig:r1-concrete-syntax} and the abstract
  962. syntax is defined in Figure~\ref{fig:r1-syntax}. The non-terminal
  963. \Var{} may be any Racket identifier. As in $R_0$, \key{read} is a
  964. nullary operator, \key{-} is a unary operator, and \key{+} is a binary
  965. operator. Similar to $R_0$, the abstract syntax of $R_1$ includes the
  966. \key{Program} struct to mark the top of the program.
  967. %% The $\itm{info}$
  968. %% field of the \key{Program} structure contains an \emph{association
  969. %% list} (a list of key-value pairs) that is used to communicate
  970. %% auxiliary data from one compiler pass the next.
  971. Despite the simplicity of the $R_1$ language, it is rich enough to
  972. exhibit several compilation techniques.
  973. \begin{figure}[tp]
  974. \centering
  975. \fbox{
  976. \begin{minipage}{0.96\textwidth}
  977. \[
  978. \begin{array}{rcl}
  979. \Exp &::=& \Int \mid \CREAD{} \mid \CNEG{\Exp} \mid \CADD{\Exp}{\Exp}\\
  980. &\mid& \Var \mid \CLET{\Var}{\Exp}{\Exp} \\
  981. R_1 &::=& \Exp
  982. \end{array}
  983. \]
  984. \end{minipage}
  985. }
  986. \caption{The concrete syntax of $R_1$.}
  987. \label{fig:r1-concrete-syntax}
  988. \end{figure}
  989. \begin{figure}[tp]
  990. \centering
  991. \fbox{
  992. \begin{minipage}{0.96\textwidth}
  993. \[
  994. \begin{array}{rcl}
  995. \Exp &::=& \INT{\Int} \mid \READ{} \\
  996. &\mid& \NEG{\Exp} \mid \ADD{\Exp}{\Exp} \\
  997. &\mid& \VAR{\Var} \mid \LET{\Var}{\Exp}{\Exp} \\
  998. R_1 &::=& \PROGRAM{\code{'()}}{\Exp}
  999. \end{array}
  1000. \]
  1001. \end{minipage}
  1002. }
  1003. \caption{The abstract syntax of $R_1$.}
  1004. \label{fig:r1-syntax}
  1005. \end{figure}
  1006. Let us dive further into the syntax and semantics of the $R_1$
  1007. language. The \key{Let} feature defines a variable for use within its
  1008. body and initializes the variable with the value of an expression.
  1009. The abstract syntax for \key{Let} is defined in Figure~\ref{fig:r1-syntax}.
  1010. The concrete syntax for \key{Let} is
  1011. \begin{lstlisting}
  1012. (let ([|$\itm{var}$| |$\itm{exp}$|]) |$\itm{exp}$|)
  1013. \end{lstlisting}
  1014. For example, the following program initializes \code{x} to $32$ and then
  1015. evaluates the body \code{(+ 10 x)}, producing $42$.
  1016. \begin{lstlisting}
  1017. (let ([x (+ 12 20)]) (+ 10 x))
  1018. \end{lstlisting}
  1019. When there are multiple \key{let}'s for the same variable, the closest
  1020. enclosing \key{let} is used. That is, variable definitions overshadow
  1021. prior definitions. Consider the following program with two \key{let}'s
  1022. that define variables named \code{x}. Can you figure out the result?
  1023. \begin{lstlisting}
  1024. (let ([x 32]) (+ (let ([x 10]) x) x))
  1025. \end{lstlisting}
  1026. For the purposes of depicting which variable uses correspond to which
  1027. definitions, the following shows the \code{x}'s annotated with
  1028. subscripts to distinguish them. Double check that your answer for the
  1029. above is the same as your answer for this annotated version of the
  1030. program.
  1031. \begin{lstlisting}
  1032. (let ([x|$_1$| 32]) (+ (let ([x|$_2$| 10]) x|$_2$|) x|$_1$|))
  1033. \end{lstlisting}
  1034. The initializing expression is always evaluated before the body of the
  1035. \key{let}, so in the following, the \key{read} for \code{x} is
  1036. performed before the \key{read} for \code{y}. Given the input
  1037. $52$ then $10$, the following produces $42$ (not $-42$).
  1038. \begin{lstlisting}
  1039. (let ([x (read)]) (let ([y (read)]) (+ x (- y))))
  1040. \end{lstlisting}
  1041. \subsection{Extensible Interpreters via Method Overriding}
  1042. To prepare for discussing the interpreter for $R_1$, we need to
  1043. explain why we choose to implement the interpreter using
  1044. object-oriented programming, that is, as a collection of methods
  1045. inside of a class. Throughout this book we define many interpreters,
  1046. one for each of the languages that we study. Because each language
  1047. builds on the prior one, there is a lot of commonality between their
  1048. interpreters. We want to write down those common parts just once
  1049. instead of many times. A naive approach would be to have, for example,
  1050. the interpreter for $R_2$ handle all of the new features in that
  1051. language and then have a default case that dispatches to the
  1052. interpreter for $R_1$. The following code sketches this idea.
  1053. \begin{center}
  1054. \begin{minipage}{0.45\textwidth}
  1055. \begin{lstlisting}
  1056. (define (interp-R1 e)
  1057. (match e
  1058. [(Prim '- (list e))
  1059. (define v (interp-R1 e))
  1060. (fx- 0 v)]
  1061. ...
  1062. ))
  1063. \end{lstlisting}
  1064. \end{minipage}
  1065. \begin{minipage}{0.45\textwidth}
  1066. \begin{lstlisting}
  1067. (define (interp-R2 e)
  1068. (match e
  1069. [(If cnd thn els)
  1070. (define b (interp-R2 cnd))
  1071. (match b
  1072. [#t (interp-R2 thn)]
  1073. [#f (interp-R2 els)])]
  1074. ...
  1075. [else (interp-R1 e)]
  1076. ))
  1077. \end{lstlisting}
  1078. \end{minipage}
  1079. \end{center}
  1080. The problem with this approach is that it does not handle situations
  1081. in which an $R_2$ feature, like \code{If}, is nested inside an $R_1$
  1082. feature, like the \code{-} operator, as in the following program.
  1083. \begin{lstlisting}
  1084. (Prim '- (list (If (Bool #t) (Int 42) (Int 0))))
  1085. \end{lstlisting}
  1086. If we invoke \code{interp-R2} on this program, it dispatches to
  1087. \code{interp-R1} to handle the \code{-} operator, but then it
  1088. recurisvely calls \code{interp-R1} again on the argument of \code{-},
  1089. which is an \code{If}. But there is no case for \code{If} in
  1090. \code{interp-R1}, so we get an error!
  1091. To make our intepreters extensible we need something called \emph{open
  1092. recursion}\index{open recursion}. That is, a recursive call should
  1093. always invoke the ``top'' interpreter, even if the recursive call is
  1094. made from interpreters that are lower down. Object-oriented languages
  1095. provide open recursion in the form of method overriding\index{method
  1096. overriding}. The following code sketches this idea for interpreting
  1097. $R_1$ and $R_2$ using the
  1098. \href{https://docs.racket-lang.org/guide/classes.html}{\code{class}}
  1099. \index{class} feature of Racket. We define one class for each
  1100. language and place a method for interpreting expressions inside each
  1101. class. The class for $R_2$ inherits from the class for $R_1$ and the
  1102. method \code{interp-exp} for $R_2$ overrides the \code{interp-exp} for
  1103. $R_1$. Note that the default case in \code{interp-exp} for $R_2$ uses
  1104. \code{super} to invoke \code{interp-exp}, and because $R_2$ inherits
  1105. from $R_1$, that dispatches to the \code{interp-exp} for $R_1$.
  1106. \begin{center}
  1107. \begin{minipage}{0.45\textwidth}
  1108. \begin{lstlisting}
  1109. (define interp-R1-class
  1110. (class object%
  1111. (define/public (interp-exp e)
  1112. (match e
  1113. [(Prim '- (list e))
  1114. (define v (interp-exp e))
  1115. (fx- 0 v)]
  1116. ...
  1117. ))
  1118. ...
  1119. ))
  1120. \end{lstlisting}
  1121. \end{minipage}
  1122. \begin{minipage}{0.45\textwidth}
  1123. \begin{lstlisting}
  1124. (define interp-R2-class
  1125. (class interp-R1-class
  1126. (define/override (interp-exp e)
  1127. (match e
  1128. [(If cnd thn els)
  1129. (define b (interp-exp cnd))
  1130. (match b
  1131. [#t (interp-exp thn)]
  1132. [#f (interp-exp els)])]
  1133. ...
  1134. [else (super interp-exp e)]
  1135. ))
  1136. ...
  1137. ))
  1138. \end{lstlisting}
  1139. \end{minipage}
  1140. \end{center}
  1141. Getting back to the troublesome example, repeated here:
  1142. \begin{lstlisting}
  1143. (define e0 (Prim '- (list (If (Bool #t) (Int 42) (Int 0)))))
  1144. \end{lstlisting}
  1145. We can invoke the \code{interp-exp} method for $R_2$ on this
  1146. expression by creating an object of the $R_2$ class and sending it the
  1147. \code{interp-exp} method with the argument \code{e0}.
  1148. \begin{lstlisting}
  1149. (send (new interp-R2-class) interp-exp e0)
  1150. \end{lstlisting}
  1151. This will again hit the default case of \code{interp-exp} in $R_2$ and
  1152. dispatch to the \code{interp-exp} method for $R_1$, which will handle
  1153. the \code{-} operator. But then for the recursive method call, it will
  1154. dispatch back to \code{interp-exp} for $R_2$, where the \code{If} will
  1155. be correctly handled. Thus, method overriding gives us the open
  1156. recursion that we need to implement our interpreters in an extensible
  1157. way.
  1158. \newpage
  1159. \subsection{Definitional Interpreter for $R_1$}
  1160. \begin{wrapfigure}[25]{r}[1.0in]{0.6\textwidth}
  1161. \small
  1162. \begin{tcolorbox}[title=Association Lists as Dictionaries]
  1163. An \emph{association list} (alist) is a list of key-value pairs.
  1164. For example, we can map people to their ages with an alist.
  1165. \index{alist}\index{association list}
  1166. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  1167. (define ages
  1168. '((jane . 25) (sam . 24) (kate . 45)))
  1169. \end{lstlisting}
  1170. The \emph{dictionary} interface is for mapping keys to values.
  1171. Every alist implements this interface. \index{dictionary} The package
  1172. \href{https://docs.racket-lang.org/reference/dicts.html}{\code{racket/dict}}
  1173. provides many functions for working with dictionaries. Here
  1174. are a few of them:
  1175. \begin{description}
  1176. \item[$\LP\key{dict-ref}\,\itm{dict}\,\itm{key}\RP$]
  1177. returns the value associated with the given $\itm{key}$.
  1178. \item[$\LP\key{dict-set}\,\itm{dict}\,\itm{key}\,\itm{val}\RP$]
  1179. returns a new dictionary that maps $\itm{key}$ to $\itm{val}$
  1180. but otherwise is the same as $\itm{dict}$.
  1181. \item[$\LP\code{in-dict}\,\itm{dict}\RP$] returns the
  1182. \href{https://docs.racket-lang.org/reference/sequences.html}{sequence}
  1183. of keys and values in $\itm{dict}$. For example, the following
  1184. creates a new alist in which the ages are incremented.
  1185. \end{description}
  1186. \vspace{-10pt}
  1187. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  1188. (for/list ([(k v) (in-dict ages)])
  1189. (cons k (add1 v)))
  1190. \end{lstlisting}
  1191. \end{tcolorbox}
  1192. \end{wrapfigure}
  1193. Now that we have explained why we use classes and methods to implement
  1194. interpreters, we turn to the discussion of the actual interpreter for
  1195. $R_1$. Figure~\ref{fig:interp-R1} shows the definitional interpreter
  1196. for the $R_1$ language. It is similar to the interpreter for $R_0$ but
  1197. it adds two new \key{match} clauses for variables and for \key{let}.
  1198. For \key{let}, we need a way to communicate the value of a variable to
  1199. all the uses of a variable. To accomplish this, we maintain a mapping
  1200. from variables to values. Throughout the compiler we often need to map
  1201. variables to information about them. We refer to these mappings as
  1202. \emph{environments}\index{environment}
  1203. \footnote{Another common term for environment in the compiler
  1204. literature is \emph{symbol table}\index{symbol table}.}.
  1205. For simplicity, we use an
  1206. association list (alist) to represent the environment. The sidebar to
  1207. the right gives a brief introduction to alists and the
  1208. \code{racket/dict} package. The \code{interp-R1} function takes the
  1209. current environment, \code{env}, as an extra parameter. When the
  1210. interpreter encounters a variable, it finds the corresponding value
  1211. using the \code{dict-ref} function. When the interpreter encounters a
  1212. \key{Let}, it evaluates the initializing expression, extends the
  1213. environment with the result value bound to the variable, using
  1214. \code{dict-set}, then evaluates the body of the \key{Let}.
  1215. \begin{figure}[tp]
  1216. \begin{lstlisting}
  1217. (define interp-R1-class
  1218. (class object%
  1219. (super-new)
  1220. (define/public ((interp-exp env) e)
  1221. (match e
  1222. [(Int n) n]
  1223. [(Prim 'read '())
  1224. (define r (read))
  1225. (cond [(fixnum? r) r]
  1226. [else (error 'interp-exp "expected an integer" r)])]
  1227. [(Prim '- (list e))
  1228. (define v ((interp-exp env) e))
  1229. (fx- 0 v)]
  1230. [(Prim '+ (list e1 e2))
  1231. (define v1 ((interp-exp env) e1))
  1232. (define v2 ((interp-exp env) e2))
  1233. (fx+ v1 v2)]
  1234. [(Var x) (dict-ref env x)]
  1235. [(Let x e body)
  1236. (define new-env (dict-set env x ((interp-exp env) e)))
  1237. ((interp-exp new-env) body)]
  1238. ))
  1239. (define/public (interp-program p)
  1240. (match p
  1241. [(Program '() e) ((interp-exp '()) e)]
  1242. ))
  1243. ))
  1244. (define (interp-R1 p)
  1245. (send (new interp-R1-class) interp-program p))
  1246. \end{lstlisting}
  1247. \caption{Interpreter for the $R_1$ language.}
  1248. \label{fig:interp-R1}
  1249. \end{figure}
  1250. The goal for this chapter is to implement a compiler that translates
  1251. any program $P_1$ written in the $R_1$ language into an x86 assembly
  1252. program $P_2$ such that $P_2$ exhibits the same behavior when run on a
  1253. computer as the $P_1$ program interpreted by \code{interp-R1}. That
  1254. is, they both output the same integer $n$. We depict this correctness
  1255. criteria in the following diagram.
  1256. \[
  1257. \begin{tikzpicture}[baseline=(current bounding box.center)]
  1258. \node (p1) at (0, 0) {$P_1$};
  1259. \node (p2) at (4, 0) {$P_2$};
  1260. \node (o) at (4, -2) {$n$};
  1261. \path[->] (p1) edge [above] node {\footnotesize compile} (p2);
  1262. \path[->] (p1) edge [left] node {\footnotesize interp-$R_1$} (o);
  1263. \path[->] (p2) edge [right] node {\footnotesize interp-x86} (o);
  1264. \end{tikzpicture}
  1265. \]
  1266. In the next section we introduce enough of the x86 assembly
  1267. language to compile $R_1$.
  1268. \section{The x86$_0$ Assembly Language}
  1269. \label{sec:x86}
  1270. \index{x86}
  1271. Figure~\ref{fig:x86-0-concrete} defines the concrete syntax for the subset of
  1272. the x86 assembly language needed for this chapter, which we call x86$_0$.
  1273. %
  1274. An x86 program begins with a \code{main} label followed by a sequence
  1275. of instructions. In the grammar, ellipses such as $\ldots$ are used to
  1276. indicate a sequence of items, e.g., $\Instr \ldots$ is a sequence of
  1277. instructions.\index{instruction}
  1278. %
  1279. An x86 program is stored in the computer's memory and the computer has
  1280. a \emph{program counter} (PC)\index{program counter}\index{PC}
  1281. that points to the address of the next
  1282. instruction to be executed. For most instructions, once the
  1283. instruction is executed, the program counter is incremented to point
  1284. to the immediately following instruction in memory. Most x86
  1285. instructions take two operands, where each operand is either an
  1286. integer constant (called \emph{immediate value}\index{immediate value}),
  1287. a \emph{register}\index{register}, or a memory location.
  1288. A register is a special kind of variable. Each
  1289. one holds a 64-bit value; there are 16 registers in the computer and
  1290. their names are given in Figure~\ref{fig:x86-0-concrete}. The computer's memory
  1291. as a mapping of 64-bit addresses to 64-bit values%
  1292. \footnote{This simple story suffices for describing how sequential
  1293. programs access memory but is not sufficient for multi-threaded
  1294. programs. However, multi-threaded execution is beyond the scope of
  1295. this book.}.
  1296. %
  1297. We use the AT\&T syntax expected by the GNU assembler, which comes
  1298. with the \key{gcc} compiler that we use for compiling assembly code to
  1299. machine code.
  1300. %
  1301. Appendix~\ref{sec:x86-quick-reference} is a quick-reference for all of
  1302. the x86 instructions used in this book.
  1303. % to do: finish treatment of imulq
  1304. % it's needed for vector's in R6/R7
  1305. \newcommand{\allregisters}{\key{rsp} \mid \key{rbp} \mid \key{rax} \mid \key{rbx} \mid \key{rcx}
  1306. \mid \key{rdx} \mid \key{rsi} \mid \key{rdi} \mid \\
  1307. && \key{r8} \mid \key{r9} \mid \key{r10}
  1308. \mid \key{r11} \mid \key{r12} \mid \key{r13}
  1309. \mid \key{r14} \mid \key{r15}}
  1310. \begin{figure}[tp]
  1311. \fbox{
  1312. \begin{minipage}{0.96\textwidth}
  1313. \[
  1314. \begin{array}{lcl}
  1315. \Reg &::=& \allregisters{} \\
  1316. \Arg &::=& \key{\$}\Int \mid \key{\%}\Reg \mid \Int\key{(}\key{\%}\Reg\key{)}\\
  1317. \Instr &::=& \key{addq} \; \Arg\key{,} \Arg \mid
  1318. \key{subq} \; \Arg\key{,} \Arg \mid
  1319. \key{negq} \; \Arg \mid \key{movq} \; \Arg\key{,} \Arg \mid \\
  1320. && \key{callq} \; \mathit{label} \mid
  1321. \key{pushq}\;\Arg \mid \key{popq}\;\Arg \mid \key{retq} \mid \key{jmp}\,\itm{label} \\
  1322. && \itm{label}\key{:}\; \Instr \\
  1323. x86_0 &::= & \key{.globl main}\\
  1324. & & \key{main:} \; \Instr\ldots
  1325. \end{array}
  1326. \]
  1327. \end{minipage}
  1328. }
  1329. \caption{The syntax of the x86$_0$ assembly language (AT\&T syntax).}
  1330. \label{fig:x86-0-concrete}
  1331. \end{figure}
  1332. An immediate value is written using the notation \key{\$}$n$ where $n$
  1333. is an integer.
  1334. %
  1335. A register is written with a \key{\%} followed by the register name,
  1336. such as \key{\%rax}.
  1337. %
  1338. An access to memory is specified using the syntax $n(\key{\%}r)$,
  1339. which obtains the address stored in register $r$ and then adds $n$
  1340. bytes to the address. The resulting address is used to either load or
  1341. store to memory depending on whether it occurs as a source or
  1342. destination argument of an instruction.
  1343. An arithmetic instruction such as $\key{addq}\,s\key{,}\,d$ reads from the
  1344. source $s$ and destination $d$, applies the arithmetic operation, then
  1345. writes the result back to the destination $d$.
  1346. %
  1347. The move instruction $\key{movq}\,s\key{,}\,d$ reads from $s$ and
  1348. stores the result in $d$.
  1349. %
  1350. The $\key{callq}\,\itm{label}$ instruction executes the procedure
  1351. specified by the label and $\key{retq}$ returns from a procedure to
  1352. its caller. The abstract syntax for \code{callq} includes an extra
  1353. integer field that represents the arity (number of parameters) of the
  1354. function being called.
  1355. %
  1356. We discuss procedure calls in more detail later in this
  1357. chapter and in Chapter~\ref{ch:functions}. The
  1358. $\key{jmp}\,\itm{label}$ instruction updates the program counter to
  1359. the address of the instruction after the specified label.
  1360. Figure~\ref{fig:p0-x86} depicts an x86 program that is equivalent
  1361. to \code{(+ 10 32)}. The \key{globl} directive says that the
  1362. \key{main} procedure is externally visible, which is necessary so
  1363. that the operating system can call it. The label \key{main:}
  1364. indicates the beginning of the \key{main} procedure which is where
  1365. the operating system starts executing this program. The instruction
  1366. \lstinline{movq $10, %rax} puts $10$ into register \key{rax}. The
  1367. following instruction \lstinline{addq $32, %rax} adds $32$ to the
  1368. $10$ in \key{rax} and puts the result, $42$, back into
  1369. \key{rax}.
  1370. %
  1371. The last instruction, \key{retq}, finishes the \key{main} function by
  1372. returning the integer in \key{rax} to the operating system. The
  1373. operating system interprets this integer as the program's exit
  1374. code. By convention, an exit code of 0 indicates that a program
  1375. completed successfully, and all other exit codes indicate various
  1376. errors. Nevertheless, we return the result of the program as the exit
  1377. code.
  1378. %\begin{wrapfigure}{r}{2.25in}
  1379. \begin{figure}[tbp]
  1380. \begin{lstlisting}
  1381. .globl main
  1382. main:
  1383. movq $10, %rax
  1384. addq $32, %rax
  1385. retq
  1386. \end{lstlisting}
  1387. \caption{An x86 program equivalent to \code{(+ 10 32)}.}
  1388. \label{fig:p0-x86}
  1389. %\end{wrapfigure}
  1390. \end{figure}
  1391. Unfortunately, x86 varies in a couple ways depending on what operating
  1392. system it is assembled in. The code examples shown here are correct on
  1393. Linux and most Unix-like platforms, but when assembled on Mac OS X,
  1394. labels like \key{main} must be prefixed with an underscore, as in
  1395. \key{\_main}.
  1396. We exhibit the use of memory for storing intermediate results in the
  1397. next example. Figure~\ref{fig:p1-x86} lists an x86 program that is
  1398. equivalent to \code{(+ 52 (- 10))}. This program uses a region of
  1399. memory called the \emph{procedure call stack} (or \emph{stack} for
  1400. short). \index{stack}\index{procedure call stack} The stack consists
  1401. of a separate \emph{frame}\index{frame} for each procedure call. The
  1402. memory layout for an individual frame is shown in
  1403. Figure~\ref{fig:frame}. The register \key{rsp} is called the
  1404. \emph{stack pointer}\index{stack pointer} and points to the item at
  1405. the top of the stack. The stack grows downward in memory, so we
  1406. increase the size of the stack by subtracting from the stack pointer.
  1407. In the context of a procedure call, the \emph{return
  1408. address}\index{return address} is the instruction after the call
  1409. instruction on the caller side. The function call instruction,
  1410. \code{callq}, pushes the return address onto the stack. The register
  1411. \key{rbp} is the \emph{base pointer}\index{base pointer} and is used
  1412. to access variables associated with the current procedure call. The
  1413. base pointer of the caller is pushed onto the stack after the return
  1414. address. We number the variables from $1$ to $n$. Variable $1$ is
  1415. stored at address $-8\key{(\%rbp)}$, variable $2$ at
  1416. $-16\key{(\%rbp)}$, etc.
  1417. \begin{figure}[tbp]
  1418. \begin{lstlisting}
  1419. start:
  1420. movq $10, -8(%rbp)
  1421. negq -8(%rbp)
  1422. movq -8(%rbp), %rax
  1423. addq $52, %rax
  1424. jmp conclusion
  1425. .globl main
  1426. main:
  1427. pushq %rbp
  1428. movq %rsp, %rbp
  1429. subq $16, %rsp
  1430. jmp start
  1431. conclusion:
  1432. addq $16, %rsp
  1433. popq %rbp
  1434. retq
  1435. \end{lstlisting}
  1436. \caption{An x86 program equivalent to \code{(+ 10 32)}.}
  1437. \label{fig:p1-x86}
  1438. \end{figure}
  1439. \begin{figure}[tbp]
  1440. \centering
  1441. \begin{tabular}{|r|l|} \hline
  1442. Position & Contents \\ \hline
  1443. 8(\key{\%rbp}) & return address \\
  1444. 0(\key{\%rbp}) & old \key{rbp} \\
  1445. -8(\key{\%rbp}) & variable $1$ \\
  1446. -16(\key{\%rbp}) & variable $2$ \\
  1447. \ldots & \ldots \\
  1448. 0(\key{\%rsp}) & variable $n$\\ \hline
  1449. \end{tabular}
  1450. \caption{Memory layout of a frame.}
  1451. \label{fig:frame}
  1452. \end{figure}
  1453. Getting back to the program in Figure~\ref{fig:p1-x86}, consider how
  1454. control is transferred from the operating system to the \code{main}
  1455. function. The operating system issues a \code{callq main} instruction
  1456. which pushes its return address on the stack and then jumps to
  1457. \code{main}. In x86-64, the stack pointer \code{rsp} must be divisible
  1458. by 16 bytes prior to the execution of any \code{callq} instruction, so
  1459. when control arrives at \code{main}, the \code{rsp} is 8 bytes out of
  1460. alignment (because the \code{callq} pushed the return address). The
  1461. first three instructions are the typical \emph{prelude}\index{prelude}
  1462. for a procedure. The instruction \code{pushq \%rbp} saves the base
  1463. pointer for the caller onto the stack and subtracts $8$ from the stack
  1464. pointer. At this point the stack pointer is back to being 16-byte
  1465. aligned. The second instruction \code{movq \%rsp, \%rbp} changes the
  1466. base pointer so that it points the location of the old base
  1467. pointer. The instruction \code{subq \$16, \%rsp} moves the stack
  1468. pointer down to make enough room for storing variables. This program
  1469. needs one variable ($8$ bytes) but we round up to 16 bytes to maintain
  1470. the 16-byte alignment of the \code{rsp}. With the \code{rsp} aligned,
  1471. we are ready to make calls to other functions. The last instruction of
  1472. the prelude is \code{jmp start}, which transfers control to the
  1473. instructions that were generated from the Racket expression \code{(+
  1474. 10 32)}.
  1475. The four instructions under the label \code{start} carry out the work
  1476. of computing \code{(+ 52 (- 10)))}.
  1477. %
  1478. The first instruction \code{movq \$10, -8(\%rbp)} stores $10$ in
  1479. variable $1$.
  1480. %
  1481. The instruction \code{negq -8(\%rbp)} changes variable $1$ to $-10$.
  1482. %
  1483. The following instruction moves the $-10$ from variable $1$ into the
  1484. \code{rax} register. Finally, \code{addq \$52, \%rax} adds $52$ to
  1485. the value in \code{rax}, updating its contents to $42$.
  1486. The three instructions under the label \code{conclusion} are the
  1487. typical \emph{conclusion}\index{conclusion} of a procedure. The first
  1488. two instructions are necessary to get the state of the machine back to
  1489. where it was at the beginning of the procedure. The instruction
  1490. \key{addq \$16, \%rsp} moves the stack pointer back to point at the
  1491. old base pointer. The amount added here needs to match the amount that
  1492. was subtracted in the prelude of the procedure. Then \key{popq \%rbp}
  1493. returns the old base pointer to \key{rbp} and adds $8$ to the stack
  1494. pointer. The last instruction, \key{retq}, jumps back to the
  1495. procedure that called this one and adds 8 to the stack pointer, which
  1496. returns the stack pointer to where it was prior to the procedure call.
  1497. The compiler needs a convenient representation for manipulating x86
  1498. programs, so we define an abstract syntax for x86 in
  1499. Figure~\ref{fig:x86-0-ast}. We refer to this language as x86$_0$ with
  1500. a subscript $0$ because later we introduce extended versions of this
  1501. assembly language. The main difference compared to the concrete syntax
  1502. of x86 (Figure~\ref{fig:x86-0-concrete}) is that it does not allow
  1503. labeled instructions to appear anywhere, but instead organizes
  1504. instructions into a group called a
  1505. \emph{block}\index{block}\index{basic block} and associates a label
  1506. with every block, which is why the \key{CFG} struct (for control-flow
  1507. graph) includes an alist mapping labels to blocks. The reason for this
  1508. organization becomes apparent in Chapter~\ref{ch:bool-types} when we
  1509. introduce conditional branching. The \code{Block} structure includes
  1510. an $\itm{info}$ field that is not needed for this chapter, but will
  1511. become useful in Chapter~\ref{ch:register-allocation-r1}. For now,
  1512. the $\itm{info}$ field should just contain an empty list. Also,
  1513. regarding the abstract syntax for \code{callq}, the \code{Callq}
  1514. struct includes an integer for representing the arity of the function,
  1515. i.e., the number of arguments, which is helpful to know during
  1516. register allocation (Chapter~\ref{ch:register-allocation-r1}).
  1517. \begin{figure}[tp]
  1518. \fbox{
  1519. \begin{minipage}{0.96\textwidth}
  1520. \small
  1521. \[
  1522. \begin{array}{lcl}
  1523. \Reg &::=& \allregisters{} \\
  1524. \Arg &::=& \IMM{\Int} \mid \REG{\Reg}
  1525. \mid \DEREF{\Reg}{\Int} \\
  1526. \Instr &::=& \BININSTR{\code{'addq}}{\Arg}{\Arg}
  1527. \mid \BININSTR{\code{'subq}}{\Arg}{\Arg} \\
  1528. &\mid& \BININSTR{\code{'movq}}{\Arg}{\Arg}
  1529. \mid \UNIINSTR{\code{'negq}}{\Arg}\\
  1530. &\mid& \CALLQ{\itm{label}}{\itm{int}} \mid \RETQ{}
  1531. \mid \PUSHQ{\Arg} \mid \POPQ{\Arg} \mid \JMP{\itm{label}} \\
  1532. \Block &::= & \BLOCK{\itm{info}}{\Instr\ldots} \\
  1533. x86_0 &::= & \PROGRAM{\itm{info}}{\CFG{\key{(}\itm{label} \,\key{.}\, \Block \key{)}\ldots}}
  1534. \end{array}
  1535. \]
  1536. \end{minipage}
  1537. }
  1538. \caption{The abstract syntax of x86$_0$ assembly.}
  1539. \label{fig:x86-0-ast}
  1540. \end{figure}
  1541. \section{Planning the trip to x86 via the $C_0$ language}
  1542. \label{sec:plan-s0-x86}
  1543. To compile one language to another it helps to focus on the
  1544. differences between the two languages because the compiler will need
  1545. to bridge those differences. What are the differences between $R_1$
  1546. and x86 assembly? Here are some of the most important ones:
  1547. \begin{enumerate}
  1548. \item[(a)] x86 arithmetic instructions typically have two arguments
  1549. and update the second argument in place. In contrast, $R_1$
  1550. arithmetic operations take two arguments and produce a new value.
  1551. An x86 instruction may have at most one memory-accessing argument.
  1552. Furthermore, some instructions place special restrictions on their
  1553. arguments.
  1554. \item[(b)] An argument of an $R_1$ operator can be any expression,
  1555. whereas x86 instructions restrict their arguments to be integers
  1556. constants, registers, and memory locations.
  1557. \item[(c)] The order of execution in x86 is explicit in the syntax: a
  1558. sequence of instructions and jumps to labeled positions, whereas in
  1559. $R_1$ the order of evaluation is a left-to-right depth-first
  1560. traversal of the abstract syntax tree.
  1561. \item[(d)] An $R_1$ program can have any number of variables whereas
  1562. x86 has 16 registers and the procedure calls stack.
  1563. \item[(e)] Variables in $R_1$ can overshadow other variables with the
  1564. same name. The registers and memory locations of x86 all have unique
  1565. names or addresses.
  1566. \end{enumerate}
  1567. We ease the challenge of compiling from $R_1$ to x86 by breaking down
  1568. the problem into several steps, dealing with the above differences one
  1569. at a time. Each of these steps is called a \emph{pass} of the
  1570. compiler.\index{pass}\index{compiler pass}
  1571. %
  1572. This terminology comes from each step traverses (i.e. passes over) the
  1573. AST of the program.
  1574. %
  1575. We begin by sketching how we might implement each pass, and give them
  1576. names. We then figure out an ordering of the passes and the
  1577. input/output language for each pass. The very first pass has $R_1$ as
  1578. its input language and the last pass has x86 as its output
  1579. language. In between we can choose whichever language is most
  1580. convenient for expressing the output of each pass, whether that be
  1581. $R_1$, x86, or new \emph{intermediate languages} of our own design.
  1582. Finally, to implement each pass we write one recursive function per
  1583. non-terminal in the grammar of the input language of the pass.
  1584. \index{intermediate language}
  1585. \begin{description}
  1586. \item[Pass \key{select-instructions}] To handle the difference between
  1587. $R_1$ operations and x86 instructions we convert each $R_1$
  1588. operation to a short sequence of instructions that accomplishes the
  1589. same task.
  1590. \item[Pass \key{remove-complex-opera*}] To ensure that each
  1591. subexpression (i.e. operator and operand, and hence the name
  1592. \key{opera*}) is an \emph{atomic} expression (a variable or
  1593. integer), we introduce temporary variables to hold the results
  1594. of subexpressions.\index{atomic expression}
  1595. \item[Pass \key{explicate-control}] To make the execution order of the
  1596. program explicit, we convert from the abstract syntax tree
  1597. representation into a control-flow graph in which each node
  1598. contains a sequence of statements and the edges between nodes say
  1599. where to go at the end of the sequence.
  1600. \item[Pass \key{assign-homes}] To handle the difference between the
  1601. variables in $R_1$ versus the registers and stack locations in x86,
  1602. we map each variable to a register or stack location.
  1603. \item[Pass \key{uniquify}] This pass deals with the shadowing of variables
  1604. by renaming every variable to a unique name, so that shadowing no
  1605. longer occurs.
  1606. \end{description}
  1607. The next question is: in what order should we apply these passes? This
  1608. question can be challenging because it is difficult to know ahead of
  1609. time which orders will be better (easier to implement, produce more
  1610. efficient code, etc.) so oftentimes trial-and-error is
  1611. involved. Nevertheless, we can try to plan ahead and make educated
  1612. choices regarding the ordering.
  1613. Let us consider the ordering of \key{uniquify} and
  1614. \key{remove-complex-opera*}. The assignment of subexpressions to
  1615. temporary variables involves introducing new variables and moving
  1616. subexpressions, which might change the shadowing of variables and
  1617. inadvertently change the behavior of the program. But if we apply
  1618. \key{uniquify} first, this will not be an issue. Of course, this means
  1619. that in \key{remove-complex-opera*}, we need to ensure that the
  1620. temporary variables that it creates are unique.
  1621. What should be the ordering of \key{explicate-control} with respect to
  1622. \key{uniquify}? The \key{uniquify} pass should come first because
  1623. \key{explicate-control} changes all the \key{let}-bound variables to
  1624. become local variables whose scope is the entire program, which would
  1625. confuse variables with the same name.
  1626. %
  1627. Likewise, we place \key{explicate-control} after
  1628. \key{remove-complex-opera*} because \key{explicate-control} removes
  1629. the \key{let} form, but it is convenient to use \key{let} in the
  1630. output of \key{remove-complex-opera*}.
  1631. %
  1632. Regarding \key{assign-homes}, it is helpful to place
  1633. \key{explicate-control} first because \key{explicate-control} changes
  1634. \key{let}-bound variables into program-scope variables. This means
  1635. that the \key{assign-homes} pass can read off the variables from the
  1636. $\itm{info}$ of the \key{Program} AST node instead of traversing the
  1637. entire program in search of \key{let}-bound variables.
  1638. Last, we need to decide on the ordering of \key{select-instructions}
  1639. and \key{assign-homes}. These two passes are intertwined, creating a
  1640. Gordian Knot. To do a good job of assigning homes, it is helpful to
  1641. have already determined which instructions will be used, because x86
  1642. instructions have restrictions about which of their arguments can be
  1643. registers versus stack locations. One might want to give preferential
  1644. treatment to variables that occur in register-argument positions. On
  1645. the other hand, it may turn out to be impossible to make sure that all
  1646. such variables are assigned to registers, and then one must redo the
  1647. selection of instructions. Some compilers handle this problem by
  1648. iteratively repeating these two passes until a good solution is found.
  1649. We use a simpler approach in which \key{select-instructions}
  1650. comes first, followed by the \key{assign-homes}, then a third
  1651. pass named \key{patch-instructions} that uses a reserved register to
  1652. patch-up outstanding problems regarding instructions with too many
  1653. memory accesses. The disadvantage of this approach is some programs
  1654. may not execute as efficiently as they would if we used the iterative
  1655. approach and used all of the registers for variables.
  1656. \begin{figure}[tbp]
  1657. \begin{tikzpicture}[baseline=(current bounding box.center)]
  1658. \node (R1) at (0,2) {\large $R_1$};
  1659. \node (R1-2) at (3,2) {\large $R_1$};
  1660. \node (R1-3) at (6,2) {\large $R_1^{\dagger}$};
  1661. %\node (C0-1) at (6,0) {\large $C_0$};
  1662. \node (C0-2) at (3,0) {\large $C_0$};
  1663. \node (x86-2) at (3,-2) {\large $\text{x86}^{*}_0$};
  1664. \node (x86-3) at (6,-2) {\large $\text{x86}^{*}_0$};
  1665. \node (x86-4) at (9,-2) {\large $\text{x86}_0$};
  1666. \node (x86-5) at (12,-2) {\large $\text{x86}^{\dagger}_0$};
  1667. \path[->,bend left=15] (R1) edge [above] node {\ttfamily\footnotesize uniquify} (R1-2);
  1668. \path[->,bend left=15] (R1-2) edge [above] node {\ttfamily\footnotesize remove-complex.} (R1-3);
  1669. \path[->,bend left=15] (R1-3) edge [right] node {\ttfamily\footnotesize explicate-control} (C0-2);
  1670. \path[->,bend right=15] (C0-2) edge [left] node {\ttfamily\footnotesize select-instr.} (x86-2);
  1671. \path[->,bend left=15] (x86-2) edge [above] node {\ttfamily\footnotesize assign-homes} (x86-3);
  1672. \path[->,bend left=15] (x86-3) edge [above] node {\ttfamily\footnotesize patch-instr.} (x86-4);
  1673. \path[->,bend left=15] (x86-4) edge [above] node {\ttfamily\footnotesize print-x86} (x86-5);
  1674. \end{tikzpicture}
  1675. \caption{Overview of the passes for compiling $R_1$. }
  1676. \label{fig:R1-passes}
  1677. \end{figure}
  1678. Figure~\ref{fig:R1-passes} presents the ordering of the compiler
  1679. passes in the form of a graph. Each pass is an edge and the
  1680. input/output language of each pass is a node in the graph. The output
  1681. of \key{uniquify} and \key{remove-complex-opera*} are programs that
  1682. are still in the $R_1$ language, but the output of the pass
  1683. \key{explicate-control} is in a different language $C_0$ that is
  1684. designed to make the order of evaluation explicit in its syntax, which
  1685. we introduce in the next section. The \key{select-instruction} pass
  1686. translates from $C_0$ to a variant of x86. The \key{assign-homes} and
  1687. \key{patch-instructions} passes input and output variants of x86
  1688. assembly. The last pass in Figure~\ref{fig:R1-passes} is
  1689. \key{print-x86}, which converts from the abstract syntax of
  1690. $\text{x86}_0$ to the concrete syntax of x86.
  1691. In the next sections we discuss the $C_0$ language and the
  1692. $\text{x86}^{*}_0$ and $\text{x86}^{\dagger}_0$ dialects of x86. The
  1693. remainder of this chapter gives hints regarding the implementation of
  1694. each of the compiler passes in Figure~\ref{fig:R1-passes}.
  1695. \subsection{The $C_0$ Intermediate Language}
  1696. The output of \key{explicate-control} is similar to the $C$
  1697. language~\citep{Kernighan:1988nx} in that it has separate syntactic
  1698. categories for expressions and statements, so we name it $C_0$. The
  1699. abstract syntax for $C_0$ is defined in Figure~\ref{fig:c0-syntax}.
  1700. (The concrete syntax for $C_0$ is in the Appendix,
  1701. Figure~\ref{fig:c0-concrete-syntax}.)
  1702. %
  1703. The $C_0$ language supports the same operators as $R_1$ but the
  1704. arguments of operators are restricted to atomic expressions (variables
  1705. and integers), thanks to the \key{remove-complex-opera*} pass. Instead
  1706. of \key{Let} expressions, $C_0$ has assignment statements which can be
  1707. executed in sequence using the \key{Seq} form. A sequence of
  1708. statements always ends with \key{Return}, a guarantee that is baked
  1709. into the grammar rules for the \itm{tail} non-terminal. The naming of
  1710. this non-terminal comes from the term \emph{tail position}\index{tail position},
  1711. which refers to an expression that is the last one to execute within a
  1712. function. (An expression in tail position may contain subexpressions,
  1713. and those may or may not be in tail position depending on the kind of
  1714. expression.)
  1715. A $C_0$ program consists of a control-flow graph (represented as an
  1716. alist mapping labels to tails). This is more general than
  1717. necessary for the present chapter, as we do not yet need to introduce
  1718. \key{goto} for jumping to labels, but it saves us from having to
  1719. change the syntax of the program construct in
  1720. Chapter~\ref{ch:bool-types}. For now there will be just one label,
  1721. \key{start}, and the whole program is its tail.
  1722. %
  1723. The $\itm{info}$ field of the \key{Program} form, after the
  1724. \key{explicate-control} pass, contains a mapping from the symbol
  1725. \key{locals} to a list of variables, that is, a list of all the
  1726. variables used in the program. At the start of the program, these
  1727. variables are uninitialized; they become initialized on their first
  1728. assignment.
  1729. \begin{figure}[tbp]
  1730. \fbox{
  1731. \begin{minipage}{0.96\textwidth}
  1732. \[
  1733. \begin{array}{lcl}
  1734. \Atm &::=& \INT{\Int} \mid \VAR{\Var} \\
  1735. \Exp &::=& \Atm \mid \READ{} \mid \NEG{\Atm} \\
  1736. &\mid& \ADD{\Atm}{\Atm}\\
  1737. \Stmt &::=& \ASSIGN{\VAR{\Var}}{\Exp} \\
  1738. \Tail &::= & \RETURN{\Exp} \mid \SEQ{\Stmt}{\Tail} \\
  1739. C_0 & ::= & \PROGRAM{\itm{info}}{\CFG{\key{(}\itm{label}\,\key{.}\,\Tail\key{)}\ldots}}
  1740. \end{array}
  1741. \]
  1742. \end{minipage}
  1743. }
  1744. \caption{The abstract syntax of the $C_0$ intermediate language.}
  1745. \label{fig:c0-syntax}
  1746. \end{figure}
  1747. \subsection{The dialects of x86}
  1748. The x86$^{*}_0$ language, pronounced ``pseudo x86'', is the output of
  1749. the pass \key{select-instructions}. It extends x86$_0$ with an
  1750. unbounded number of program-scope variables and has looser rules
  1751. regarding instruction arguments. The x86$^{\dagger}$ language, the
  1752. output of \key{print-x86}, is the concrete syntax for x86.
  1753. \section{Uniquify Variables}
  1754. \label{sec:uniquify-s0}
  1755. The \code{uniquify} pass compiles arbitrary $R_1$ programs into $R_1$
  1756. programs in which every \key{let} uses a unique variable name. For
  1757. example, the \code{uniquify} pass should translate the program on the
  1758. left into the program on the right. \\
  1759. \begin{tabular}{lll}
  1760. \begin{minipage}{0.4\textwidth}
  1761. \begin{lstlisting}
  1762. (let ([x 32])
  1763. (+ (let ([x 10]) x) x))
  1764. \end{lstlisting}
  1765. \end{minipage}
  1766. &
  1767. $\Rightarrow$
  1768. &
  1769. \begin{minipage}{0.4\textwidth}
  1770. \begin{lstlisting}
  1771. (let ([x.1 32])
  1772. (+ (let ([x.2 10]) x.2) x.1))
  1773. \end{lstlisting}
  1774. \end{minipage}
  1775. \end{tabular} \\
  1776. %
  1777. The following is another example translation, this time of a program
  1778. with a \key{let} nested inside the initializing expression of another
  1779. \key{let}.\\
  1780. \begin{tabular}{lll}
  1781. \begin{minipage}{0.4\textwidth}
  1782. \begin{lstlisting}
  1783. (let ([x (let ([x 4])
  1784. (+ x 1))])
  1785. (+ x 2))
  1786. \end{lstlisting}
  1787. \end{minipage}
  1788. &
  1789. $\Rightarrow$
  1790. &
  1791. \begin{minipage}{0.4\textwidth}
  1792. \begin{lstlisting}
  1793. (let ([x.2 (let ([x.1 4])
  1794. (+ x.1 1))])
  1795. (+ x.2 2))
  1796. \end{lstlisting}
  1797. \end{minipage}
  1798. \end{tabular}
  1799. We recommend implementing \code{uniquify} by creating a function named
  1800. \code{uniquify-exp} that is structurally recursive function and mostly
  1801. just copies the input program. However, when encountering a \key{let},
  1802. it should generate a unique name for the variable (the Racket function
  1803. \code{gensym} is handy for this) and associate the old name with the
  1804. new unique name in an alist. The \code{uniquify-exp}
  1805. function will need to access this alist when it gets to a
  1806. variable reference, so we add another parameter to \code{uniquify-exp}
  1807. for the alist.
  1808. The skeleton of the \code{uniquify-exp} function is shown in
  1809. Figure~\ref{fig:uniquify-s0}. The function is curried so that it is
  1810. convenient to partially apply it to a symbol table and then apply it
  1811. to different expressions, as in the last clause for primitive
  1812. operations in Figure~\ref{fig:uniquify-s0}. The \href{https://docs.racket-lang.org/reference/for.html#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._for%2Flist%29%29}{\key{for/list}}
  1813. form is useful for applying a function to each element of a list to produce
  1814. a new list.
  1815. \index{for/list}
  1816. \begin{exercise}
  1817. \normalfont % I don't like the italics for exercises. -Jeremy
  1818. Complete the \code{uniquify} pass by filling in the blanks, that is,
  1819. implement the clauses for variables and for the \key{let} form.
  1820. \end{exercise}
  1821. \begin{figure}[tbp]
  1822. \begin{lstlisting}
  1823. (define (uniquify-exp symtab)
  1824. (lambda (e)
  1825. (match e
  1826. [(Var x) ___]
  1827. [(Int n) (Int n)]
  1828. [(Let x e body) ___]
  1829. [(Prim op es)
  1830. (Prim op (for/list ([e es]) ((uniquify-exp symtab) e)))]
  1831. )))
  1832. (define (uniquify p)
  1833. (match p
  1834. [(Program '() e)
  1835. (Program '() ((uniquify-exp '()) e))]
  1836. )))
  1837. \end{lstlisting}
  1838. \caption{Skeleton for the \key{uniquify} pass.}
  1839. \label{fig:uniquify-s0}
  1840. \end{figure}
  1841. \begin{exercise}
  1842. \normalfont % I don't like the italics for exercises. -Jeremy
  1843. Test your \key{uniquify} pass by creating five example $R_1$ programs
  1844. and checking whether the output programs produce the same result as
  1845. the input programs. The $R_1$ programs should be designed to test the
  1846. most interesting parts of the \key{uniquify} pass, that is, the
  1847. programs should include \key{let} forms, variables, and variables that
  1848. overshadow each other. The five programs should be in a subdirectory
  1849. named \key{tests} and they should have the same file name except for a
  1850. different integer at the end of the name, followed by the ending
  1851. \key{.rkt}. Use the \key{interp-tests} function
  1852. (Appendix~\ref{appendix:utilities}) from \key{utilities.rkt} to test
  1853. your \key{uniquify} pass on the example programs. See the
  1854. \key{run-tests.rkt} script in the support code for an example of how
  1855. to use \key{interp-tests}. The support code is in a \code{github}
  1856. repository at the following URL:
  1857. \begin{center}\footnotesize
  1858. \url{https://github.com/IUCompilerCourse/public-student-support-code}
  1859. \end{center}
  1860. \end{exercise}
  1861. \section{Remove Complex Operands}
  1862. \label{sec:remove-complex-opera-R1}
  1863. The \code{remove-complex-opera*} pass compiles $R_1$ programs into
  1864. $R_1$ programs in which the arguments of operations are atomic
  1865. expressions. Put another way, this pass removes complex
  1866. operands\index{complex operand}, such as the expression \code{(- 10)}
  1867. in the program below. This is accomplished by introducing a new
  1868. \key{let}-bound variable, binding the complex operand to the new
  1869. variable, and then using the new variable in place of the complex
  1870. operand, as shown in the output of \code{remove-complex-opera*} on the
  1871. right.\\
  1872. \begin{tabular}{lll}
  1873. \begin{minipage}{0.4\textwidth}
  1874. % s0_19.rkt
  1875. \begin{lstlisting}
  1876. (+ 52 (- 10))
  1877. \end{lstlisting}
  1878. \end{minipage}
  1879. &
  1880. $\Rightarrow$
  1881. &
  1882. \begin{minipage}{0.4\textwidth}
  1883. \begin{lstlisting}
  1884. (let ([tmp.1 (- 10)])
  1885. (+ 52 tmp.1))
  1886. \end{lstlisting}
  1887. \end{minipage}
  1888. \end{tabular}
  1889. \begin{figure}[tp]
  1890. \centering
  1891. \fbox{
  1892. \begin{minipage}{0.96\textwidth}
  1893. \[
  1894. \begin{array}{rcl}
  1895. \Atm &::=& \INT{\Int} \mid \VAR{\Var} \\
  1896. \Exp &::=& \Atm \mid \READ{} \\
  1897. &\mid& \NEG{\Atm} \mid \ADD{\Atm}{\Atm} \\
  1898. &\mid& \LET{\Var}{\Exp}{\Exp} \\
  1899. R^{\dagger}_1 &::=& \PROGRAM{\code{'()}}{\Exp}
  1900. \end{array}
  1901. \]
  1902. \end{minipage}
  1903. }
  1904. \caption{$R_1^{\dagger}$ is $R_1$ in administrative normal form (ANF).}
  1905. \label{fig:r1-anf-syntax}
  1906. \end{figure}
  1907. Figure~\ref{fig:r1-anf-syntax} presents the grammar for the output of
  1908. this pass, language $R_1^{\dagger}$. The main difference is that
  1909. operator arguments are required to be atomic expressions. In the
  1910. literature, this is called \emph{administrative normal form}, or ANF
  1911. for short~\citep{Danvy:1991fk,Flanagan:1993cg}.
  1912. \index{administrative normal form}
  1913. \index{ANF}
  1914. We recommend implementing this pass with two mutually recursive
  1915. functions, \code{rco-atom} and \code{rco-exp}. The idea is to apply
  1916. \code{rco-atom} to subexpressions that are required to be atomic and
  1917. to apply \code{rco-exp} to subexpressions that can be atomic or
  1918. complex (see Figure~\ref{fig:r1-anf-syntax}). Both functions take an
  1919. $R_1$ expression as input. The \code{rco-exp} function returns an
  1920. expression. The \code{rco-atom} function returns two things: an
  1921. atomic expression and alist mapping temporary variables to complex
  1922. subexpressions. You can return multiple things from a function using
  1923. Racket's \key{values} form and you can receive multiple things from a
  1924. function call using the \key{define-values} form. If you are not
  1925. familiar with these features, review the Racket documentation. Also,
  1926. the \href{https://docs.racket-lang.org/reference/for.html#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._for%2Flists%29%29}{\code{for/lists}}
  1927. form is useful for applying a function to each
  1928. element of a list, in the case where the function returns multiple
  1929. values.
  1930. \index{for/lists}
  1931. The following shows the output of \code{rco-atom} on the expression
  1932. \code{(- 10)} (using concrete syntax to be concise).
  1933. \begin{tabular}{lll}
  1934. \begin{minipage}{0.4\textwidth}
  1935. \begin{lstlisting}
  1936. (- 10)
  1937. \end{lstlisting}
  1938. \end{minipage}
  1939. &
  1940. $\Rightarrow$
  1941. &
  1942. \begin{minipage}{0.4\textwidth}
  1943. \begin{lstlisting}
  1944. tmp.1
  1945. ((tmp.1 . (- 10)))
  1946. \end{lstlisting}
  1947. \end{minipage}
  1948. \end{tabular}
  1949. Take special care of programs such as the next one that \key{let}-bind
  1950. variables with integers or other variables. You should leave them
  1951. unchanged, as shown in to the program on the right \\
  1952. \begin{tabular}{lll}
  1953. \begin{minipage}{0.4\textwidth}
  1954. % s0_20.rkt
  1955. \begin{lstlisting}
  1956. (let ([a 42])
  1957. (let ([b a])
  1958. b))
  1959. \end{lstlisting}
  1960. \end{minipage}
  1961. &
  1962. $\Rightarrow$
  1963. &
  1964. \begin{minipage}{0.4\textwidth}
  1965. \begin{lstlisting}
  1966. (let ([a 42])
  1967. (let ([b a])
  1968. b))
  1969. \end{lstlisting}
  1970. \end{minipage}
  1971. \end{tabular} \\
  1972. A careless implementation of \key{rco-exp} and \key{rco-atom} might
  1973. produce the following output.\\
  1974. \begin{minipage}{0.4\textwidth}
  1975. \begin{lstlisting}
  1976. (let ([tmp.1 42])
  1977. (let ([a tmp.1])
  1978. (let ([tmp.2 a])
  1979. (let ([b tmp.2])
  1980. b))))
  1981. \end{lstlisting}
  1982. \end{minipage}
  1983. \begin{exercise}
  1984. \normalfont Implement the \code{remove-complex-opera*} pass.
  1985. Test the new pass on all of the example programs that you created to test the
  1986. \key{uniquify} pass and create three new example programs that are
  1987. designed to exercise the interesting code in the
  1988. \code{remove-complex-opera*} pass. Use the \key{interp-tests} function
  1989. (Appendix~\ref{appendix:utilities}) from \key{utilities.rkt} to test
  1990. your passes on the example programs.
  1991. \end{exercise}
  1992. \section{Explicate Control}
  1993. \label{sec:explicate-control-r1}
  1994. The \code{explicate-control} pass compiles $R_1$ programs into $C_0$
  1995. programs that make the order of execution explicit in their
  1996. syntax. For now this amounts to flattening \key{let} constructs into a
  1997. sequence of assignment statements. For example, consider the following
  1998. $R_1$ program.\\
  1999. % s0_11.rkt
  2000. \begin{minipage}{0.96\textwidth}
  2001. \begin{lstlisting}
  2002. (let ([y (let ([x 20])
  2003. (+ x (let ([x 22]) x)))])
  2004. y)
  2005. \end{lstlisting}
  2006. \end{minipage}\\
  2007. %
  2008. The output of the previous pass and of \code{explicate-control} is
  2009. shown below. Recall that the right-hand-side of a \key{let} executes
  2010. before its body, so the order of evaluation for this program is to
  2011. assign \code{20} to \code{x.1}, assign \code{22} to \code{x.2}, assign
  2012. \code{(+ x.1 x.2)} to \code{y}, then return \code{y}. Indeed, the
  2013. output of \code{explicate-control} makes this ordering explicit.\\
  2014. \begin{tabular}{lll}
  2015. \begin{minipage}{0.4\textwidth}
  2016. \begin{lstlisting}
  2017. (let ([y (let ([x.1 20])
  2018. (let ([x.2 22])
  2019. (+ x.1 x.2)))])
  2020. y)
  2021. \end{lstlisting}
  2022. \end{minipage}
  2023. &
  2024. $\Rightarrow$
  2025. &
  2026. \begin{minipage}{0.4\textwidth}
  2027. \begin{lstlisting}
  2028. start:
  2029. x.1 = 20;
  2030. x.2 = 22;
  2031. y = (+ x.1 x.2);
  2032. return y;
  2033. \end{lstlisting}
  2034. \end{minipage}
  2035. \end{tabular}
  2036. We recommend implementing \code{explicate-control} using two mutually
  2037. recursive functions: \code{explicate-tail} and
  2038. \code{explicate-assign}. The first function should be applied to
  2039. expressions in tail position whereas the second should be applied to
  2040. expressions that occur on the right-hand-side of a \key{let}.
  2041. %
  2042. The \code{explicate-tail} function takes an $R_1$ expression as input
  2043. and produces a $C_0$ $\Tail$ (see Figure~\ref{fig:c0-syntax}).
  2044. %
  2045. The \code{explicate-assign} function takes an $R_1$ expression, the
  2046. variable that it is to be assigned to, and $C_0$ code (a $\Tail$) that
  2047. should come after the assignment (e.g., the code generated for the
  2048. body of the \key{let}) and returns a $\Tail$. The
  2049. \code{explicate-assign} function is in accumulator-passing style in
  2050. that its third parameter is some $C_0$ code that it adds to and
  2051. returns. The reader might be tempted to instead organize
  2052. \code{explicate-assign} in a more direct fashion, without the third
  2053. parameter and perhaps using \code{append} to combine statements. We
  2054. warn against that alternative because the accumulator-passing style is
  2055. key to how we generate high-quality code for conditional expressions
  2056. in Chapter~\ref{ch:bool-types}.
  2057. The top-level \code{explicate-control} function should invoke
  2058. \code{explicate-tail} on the body of the \key{Program} AST node.
  2059. \section{Select Instructions}
  2060. \label{sec:select-r1}
  2061. \index{instruction selection}
  2062. In the \code{select-instructions} pass we begin the work of
  2063. translating from $C_0$ to $\text{x86}^{*}_0$. The target language of
  2064. this pass is a variant of x86 that still uses variables, so we add an
  2065. AST node of the form $\VAR{\itm{var}}$ to the $\text{x86}_0$ abstract
  2066. syntax of Figure~\ref{fig:x86-0-ast}. We recommend implementing the
  2067. \code{select-instructions} in terms of three auxiliary functions, one
  2068. for each of the non-terminals of $C_0$: $\Atm$, $\Stmt$, and $\Tail$.
  2069. The cases for $\Atm$ are straightforward, variables stay
  2070. the same and integer constants are changed to immediates:
  2071. $\INT{n}$ changes to $\IMM{n}$.
  2072. Next we consider the cases for $\Stmt$, starting with arithmetic
  2073. operations. For example, in $C_0$ an addition operation can take the
  2074. form below, to the left of the $\Rightarrow$. To translate to x86, we
  2075. need to use the \key{addq} instruction which does an in-place
  2076. update. So we must first move \code{10} to \code{x}. \\
  2077. \begin{tabular}{lll}
  2078. \begin{minipage}{0.4\textwidth}
  2079. \begin{lstlisting}
  2080. x = (+ 10 32);
  2081. \end{lstlisting}
  2082. \end{minipage}
  2083. &
  2084. $\Rightarrow$
  2085. &
  2086. \begin{minipage}{0.4\textwidth}
  2087. \begin{lstlisting}
  2088. movq $10, x
  2089. addq $32, x
  2090. \end{lstlisting}
  2091. \end{minipage}
  2092. \end{tabular} \\
  2093. %
  2094. There are cases that require special care to avoid generating
  2095. needlessly complicated code. If one of the arguments of the addition
  2096. is the same as the left-hand side of the assignment, then there is no
  2097. need for the extra move instruction. For example, the following
  2098. assignment statement can be translated into a single \key{addq}
  2099. instruction.\\
  2100. \begin{tabular}{lll}
  2101. \begin{minipage}{0.4\textwidth}
  2102. \begin{lstlisting}
  2103. x = (+ 10 x);
  2104. \end{lstlisting}
  2105. \end{minipage}
  2106. &
  2107. $\Rightarrow$
  2108. &
  2109. \begin{minipage}{0.4\textwidth}
  2110. \begin{lstlisting}
  2111. addq $10, x
  2112. \end{lstlisting}
  2113. \end{minipage}
  2114. \end{tabular} \\
  2115. The \key{read} operation does not have a direct counterpart in x86
  2116. assembly, so we have instead implemented this functionality in the C
  2117. language~\citep{Kernighan:1988nx}, with the function \code{read\_int}
  2118. in the file \code{runtime.c}. In general, we refer to all of the
  2119. functionality in this file as the \emph{runtime system}\index{runtime system},
  2120. or simply the \emph{runtime} for short. When compiling your generated x86
  2121. assembly code, you need to compile \code{runtime.c} to \code{runtime.o} (an
  2122. ``object file'', using \code{gcc} option \code{-c}) and link it into
  2123. the executable. For our purposes of code generation, all you need to
  2124. do is translate an assignment of \key{read} into some variable
  2125. $\itm{lhs}$ (for left-hand side) into a call to the \code{read\_int}
  2126. function followed by a move from \code{rax} to the left-hand side.
  2127. The move from \code{rax} is needed because the return value from
  2128. \code{read\_int} goes into \code{rax}, as is the case in general. \\
  2129. \begin{tabular}{lll}
  2130. \begin{minipage}{0.3\textwidth}
  2131. \begin{lstlisting}
  2132. |$\itm{var}$| = (read);
  2133. \end{lstlisting}
  2134. \end{minipage}
  2135. &
  2136. $\Rightarrow$
  2137. &
  2138. \begin{minipage}{0.3\textwidth}
  2139. \begin{lstlisting}
  2140. callq read_int
  2141. movq %rax, |$\itm{var}$|
  2142. \end{lstlisting}
  2143. \end{minipage}
  2144. \end{tabular} \\
  2145. There are two cases for the $\Tail$ non-terminal: \key{Return} and
  2146. \key{Seq}. Regarding \key{Return}, we recommend treating it as an
  2147. assignment to the \key{rax} register followed by a jump to the
  2148. conclusion of the program (so the conclusion needs to be labeled).
  2149. For $\SEQ{s}{t}$, you can translate the statement $s$ and tail $t$
  2150. recursively and append the resulting instructions.
  2151. \begin{exercise}
  2152. \normalfont
  2153. Implement the \key{select-instructions} pass and test it on all of the
  2154. example programs that you created for the previous passes and create
  2155. three new example programs that are designed to exercise all of the
  2156. interesting code in this pass. Use the \key{interp-tests} function
  2157. (Appendix~\ref{appendix:utilities}) from \key{utilities.rkt} to test
  2158. your passes on the example programs.
  2159. \end{exercise}
  2160. \section{Assign Homes}
  2161. \label{sec:assign-r1}
  2162. The \key{assign-homes} pass compiles $\text{x86}^{*}_0$ programs to
  2163. $\text{x86}^{*}_0$ programs that no longer use program variables.
  2164. Thus, the \key{assign-homes} pass is responsible for placing all of
  2165. the program variables in registers or on the stack. For runtime
  2166. efficiency, it is better to place variables in registers, but as there
  2167. are only 16 registers, some programs must necessarily resort to
  2168. placing some variables on the stack. In this chapter we focus on the
  2169. mechanics of placing variables on the stack. We study an algorithm for
  2170. placing variables in registers in
  2171. Chapter~\ref{ch:register-allocation-r1}.
  2172. Consider again the following $R_1$ program.
  2173. % s0_20.rkt
  2174. \begin{lstlisting}
  2175. (let ([a 42])
  2176. (let ([b a])
  2177. b))
  2178. \end{lstlisting}
  2179. For reference, we repeat the output of \code{select-instructions} on
  2180. the left and show the output of \code{assign-homes} on the right.
  2181. %
  2182. %% Recall that \key{explicate-control} associated the list of
  2183. %% variables with the \code{locals} symbol in the program's $\itm{info}$
  2184. %% field, so \code{assign-homes} has convenient access to the them.
  2185. %
  2186. In this example, we assign variable \code{a} to stack location
  2187. \code{-8(\%rbp)} and variable \code{b} to location
  2188. \code{-16(\%rbp)}.\\
  2189. \begin{tabular}{l}
  2190. \begin{minipage}{0.4\textwidth}
  2191. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  2192. locals-types:
  2193. a : 'Integer, b : 'Integer
  2194. start:
  2195. movq $42, a
  2196. movq a, b
  2197. movq b, %rax
  2198. jmp conclusion
  2199. \end{lstlisting}
  2200. \end{minipage}
  2201. {$\Rightarrow$}
  2202. \begin{minipage}{0.4\textwidth}
  2203. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  2204. stack-space: 16
  2205. start:
  2206. movq $42, -8(%rbp)
  2207. movq -8(%rbp), -16(%rbp)
  2208. movq -16(%rbp), %rax
  2209. jmp conclusion
  2210. \end{lstlisting}
  2211. \end{minipage}
  2212. \end{tabular} \\
  2213. In the output of \code{select-instructions}, there is a entry for
  2214. \code{locals-types} in the $\itm{info}$ of the \code{Program} node,
  2215. which is needed here so that we have the list of variables that should
  2216. be assigned to homes. The support code computes the
  2217. \code{locals-types} entry. In particular, \code{type-check-C0}
  2218. installs it in the $\itm{info}$ field of the \code{Program} node.
  2219. When using \code{interp-tests} or \code{compiler-tests} (see Appendix,
  2220. Section~\ref{appendix:utilities}), specify \code{type-check-C0} as the
  2221. type checker to use after \code{explicate-control}.
  2222. In the process of assigning variables to stack locations, it is
  2223. convenient for you to compute and store the size of the frame (in
  2224. bytes) in the $\itm{info}$ field of the \key{Program} node, with the
  2225. key \code{stack-space}, which is needed later to generate the
  2226. conclusion of the \code{main} procedure. The x86-64 standard requires
  2227. the frame size to be a multiple of 16 bytes. \index{frame}
  2228. \begin{exercise}
  2229. \normalfont Implement the \key{assign-homes} pass and test it on all
  2230. of the example programs that you created for the previous passes pass.
  2231. We recommend that \key{assign-homes} take an extra parameter that is a
  2232. mapping of variable names to homes (stack locations for now). Use the
  2233. \key{interp-tests} function (Appendix~\ref{appendix:utilities}) from
  2234. \key{utilities.rkt} to test your passes on the example programs.
  2235. \end{exercise}
  2236. \section{Patch Instructions}
  2237. \label{sec:patch-s0}
  2238. The \code{patch-instructions} pass compiles $\text{x86}^{*}_0$
  2239. programs to $\text{x86}_0$ programs by making sure that each
  2240. instruction adheres to the restrictions of the x86 assembly language.
  2241. In particular, at most one argument of an instruction may be a memory
  2242. reference.
  2243. We return to the following running example.
  2244. % s0_20.rkt
  2245. \begin{lstlisting}
  2246. (let ([a 42])
  2247. (let ([b a])
  2248. b))
  2249. \end{lstlisting}
  2250. After the \key{assign-homes} pass, the above program has been translated to
  2251. the following. \\
  2252. \begin{minipage}{0.5\textwidth}
  2253. \begin{lstlisting}
  2254. stack-space: 16
  2255. start:
  2256. movq $42, -8(%rbp)
  2257. movq -8(%rbp), -16(%rbp)
  2258. movq -16(%rbp), %rax
  2259. jmp conclusion
  2260. \end{lstlisting}
  2261. \end{minipage}\\
  2262. The second \key{movq} instruction is problematic because both
  2263. arguments are stack locations. We suggest fixing this problem by
  2264. moving from the source location to the register \key{rax} and then
  2265. from \key{rax} to the destination location, as follows.
  2266. \begin{lstlisting}
  2267. movq -8(%rbp), %rax
  2268. movq %rax, -16(%rbp)
  2269. \end{lstlisting}
  2270. \begin{exercise}
  2271. \normalfont
  2272. Implement the \key{patch-instructions} pass and test it on all of the
  2273. example programs that you created for the previous passes and create
  2274. three new example programs that are designed to exercise all of the
  2275. interesting code in this pass. Use the \key{interp-tests} function
  2276. (Appendix~\ref{appendix:utilities}) from \key{utilities.rkt} to test
  2277. your passes on the example programs.
  2278. \end{exercise}
  2279. \section{Print x86}
  2280. \label{sec:print-x86}
  2281. The last step of the compiler from $R_1$ to x86 is to convert the
  2282. $\text{x86}_0$ AST (defined in Figure~\ref{fig:x86-0-ast}) to the
  2283. string representation (defined in Figure~\ref{fig:x86-0-concrete}). The Racket
  2284. \key{format} and \key{string-append} functions are useful in this
  2285. regard. The main work that this step needs to perform is to create the
  2286. \key{main} function and the standard instructions for its prelude and
  2287. conclusion, as shown in Figure~\ref{fig:p1-x86} of
  2288. Section~\ref{sec:x86}. You need to know the number of stack-allocated
  2289. variables, so we suggest computing it in the \key{assign-homes} pass
  2290. (Section~\ref{sec:assign-r1}) and storing it in the $\itm{info}$ field
  2291. of the \key{program} node.
  2292. %% Your compiled code should print the result of the program's execution
  2293. %% by using the \code{print\_int} function provided in
  2294. %% \code{runtime.c}. If your compiler has been implemented correctly so
  2295. %% far, this final result should be stored in the \key{rax} register.
  2296. %% We'll talk more about how to perform function calls with arguments in
  2297. %% general later on, but for now, place the following after the compiled
  2298. %% code for the $R_1$ program but before the conclusion:
  2299. %% \begin{lstlisting}
  2300. %% movq %rax, %rdi
  2301. %% callq print_int
  2302. %% \end{lstlisting}
  2303. %% These lines move the value in \key{rax} into the \key{rdi} register, which
  2304. %% stores the first argument to be passed into \key{print\_int}.
  2305. If you want your program to run on Mac OS X, your code needs to
  2306. determine whether or not it is running on a Mac, and prefix
  2307. underscores to labels like \key{main}. You can determine the platform
  2308. with the Racket call \code{(system-type 'os)}, which returns
  2309. \code{'macosx}, \code{'unix}, or \code{'windows}.
  2310. %% In addition to
  2311. %% placing underscores on \key{main}, you need to put them in front of
  2312. %% \key{callq} labels (so \code{callq print\_int} becomes \code{callq
  2313. %% \_print\_int}).
  2314. \begin{exercise}
  2315. \normalfont Implement the \key{print-x86} pass and test it on all of
  2316. the example programs that you created for the previous passes. Use the
  2317. \key{compiler-tests} function (Appendix~\ref{appendix:utilities}) from
  2318. \key{utilities.rkt} to test your complete compiler on the example
  2319. programs. See the \key{run-tests.rkt} script in the student support
  2320. code for an example of how to use \key{compiler-tests}. Also, remember
  2321. to compile the provided \key{runtime.c} file to \key{runtime.o} using
  2322. \key{gcc}.
  2323. \end{exercise}
  2324. \section{Challenge: Partial Evaluator for $R_1$}
  2325. \label{sec:pe-R1}
  2326. \index{partial evaluation}
  2327. This section describes optional challenge exercises that involve
  2328. adapting and improving the partial evaluator for $R_0$ that was
  2329. introduced in Section~\ref{sec:partial-evaluation}.
  2330. \begin{exercise}\label{ex:pe-R1}
  2331. \normalfont
  2332. Adapt the partial evaluator from Section~\ref{sec:partial-evaluation}
  2333. (Figure~\ref{fig:pe-arith}) so that it applies to $R_1$ programs
  2334. instead of $R_0$ programs. Recall that $R_1$ adds \key{let} binding
  2335. and variables to the $R_0$ language, so you will need to add cases for
  2336. them in the \code{pe-exp} function. Also, note that the \key{program}
  2337. form changes slightly to include an $\itm{info}$ field. Once
  2338. complete, add the partial evaluation pass to the front of your
  2339. compiler and make sure that your compiler still passes all of the
  2340. tests.
  2341. \end{exercise}
  2342. The next exercise builds on Exercise~\ref{ex:pe-R1}.
  2343. \begin{exercise}
  2344. \normalfont
  2345. Improve on the partial evaluator by replacing the \code{pe-neg} and
  2346. \code{pe-add} auxiliary functions with functions that know more about
  2347. arithmetic. For example, your partial evaluator should translate
  2348. \begin{lstlisting}
  2349. (+ 1 (+ (read) 1))
  2350. \end{lstlisting}
  2351. into
  2352. \begin{lstlisting}
  2353. (+ 2 (read))
  2354. \end{lstlisting}
  2355. To accomplish this, the \code{pe-exp} function should produce output
  2356. in the form of the $\itm{residual}$ non-terminal of the following
  2357. grammar.
  2358. \[
  2359. \begin{array}{lcl}
  2360. \itm{inert} &::=& \Var \mid (\key{read}) \mid (\key{-} \;(\key{read}))
  2361. \mid (\key{+} \; \itm{inert} \; \itm{inert})\\
  2362. \itm{residual} &::=& \Int \mid (\key{+}\; \Int\; \itm{inert}) \mid \itm{inert}
  2363. \end{array}
  2364. \]
  2365. The \code{pe-add} and \code{pe-neg} functions may therefore assume
  2366. that their inputs are $\itm{residual}$ expressions and they should
  2367. return $\itm{residual}$ expressions. Once the improvements are
  2368. complete, make sure that your compiler still passes all of the tests.
  2369. After all, fast code is useless if it produces incorrect results!
  2370. \end{exercise}
  2371. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  2372. \chapter{Register Allocation}
  2373. \label{ch:register-allocation-r1}
  2374. \index{register allocation}
  2375. In Chapter~\ref{ch:int-exp} we placed all variables on the stack to
  2376. make our life easier. However, we can improve the performance of the
  2377. generated code if we instead place some variables into registers. The
  2378. CPU can access a register in a single cycle, whereas accessing the
  2379. stack takes many cycles if the relevant data is in cache or many more
  2380. to access main memory if the data is not in cache.
  2381. Figure~\ref{fig:reg-eg} shows a program with four variables that
  2382. serves as a running example. We show the source program and also the
  2383. output of instruction selection. At that point the program is almost
  2384. x86 assembly but not quite; it still contains variables instead of
  2385. stack locations or registers.
  2386. \begin{figure}
  2387. \begin{minipage}{0.45\textwidth}
  2388. Example $R_1$ program:
  2389. % s0_28.rkt
  2390. \begin{lstlisting}
  2391. (let ([v 1])
  2392. (let ([w 42])
  2393. (let ([x (+ v 7)])
  2394. (let ([y x])
  2395. (let ([z (+ x w)])
  2396. (+ z (- y)))))))
  2397. \end{lstlisting}
  2398. \end{minipage}
  2399. \begin{minipage}{0.45\textwidth}
  2400. After instruction selection:
  2401. \begin{lstlisting}
  2402. locals-types:
  2403. x : Integer, y : Integer,
  2404. z : Integer, t : Integer,
  2405. v : Integer, w : Integer
  2406. start:
  2407. movq $1, v
  2408. movq $42, w
  2409. movq v, x
  2410. addq $7, x
  2411. movq x, y
  2412. movq x, z
  2413. addq w, z
  2414. movq y, t
  2415. negq t
  2416. movq z, %rax
  2417. addq t, %rax
  2418. jmp conclusion
  2419. \end{lstlisting}
  2420. \end{minipage}
  2421. \caption{A running example program for register allocation.}
  2422. \label{fig:reg-eg}
  2423. \end{figure}
  2424. The goal of register allocation is to fit as many variables into
  2425. registers as possible. A program sometimes has more variables than
  2426. registers, so we cannot always map each variable to a different
  2427. register. Fortunately, it is common for different variables to be
  2428. needed during different periods of time during program execution, and
  2429. in such cases several variables can be mapped to the same register.
  2430. Consider variables \code{x} and \code{y} in Figure~\ref{fig:reg-eg}.
  2431. After the variable \code{x} is moved to \code{z} it is no longer
  2432. needed. Variable \code{y}, on the other hand, is used only after this
  2433. point, so \code{x} and \code{y} could share the same register. The
  2434. topic of Section~\ref{sec:liveness-analysis-r1} is how to compute
  2435. where a variable is needed. Once we have that information, we compute
  2436. which variables are needed at the same time, i.e., which ones
  2437. \emph{interfere} with each other, and represent this relation as an
  2438. undirected graph whose vertices are variables and edges indicate when
  2439. two variables interfere (Section~\ref{sec:build-interference}). We
  2440. then model register allocation as a graph coloring problem, which we
  2441. discuss in Section~\ref{sec:graph-coloring}.
  2442. If we run out of registers despite these efforts, we place the
  2443. remaining variables on the stack, similar to what we did in
  2444. Chapter~\ref{ch:int-exp}. It is common to use the verb \emph{spill}
  2445. for assigning a variable to a stack location. The decision to spill a
  2446. variable is handled as part of the graph coloring process described in
  2447. Section~\ref{sec:graph-coloring}.
  2448. We make the simplifying assumption that each variable is assigned to
  2449. one location (a register or stack address). A more sophisticated
  2450. approach is to assign a variable to one or more locations in different
  2451. regions of the program. For example, if a variable is used many times
  2452. in short sequence and then only used again after many other
  2453. instructions, it could be more efficient to assign the variable to a
  2454. register during the initial sequence and then move it to the stack for
  2455. the rest of its lifetime. We refer the interested reader to
  2456. \citet{Cooper:1998ly} and \citet{Cooper:2011aa} for more information
  2457. about that approach.
  2458. % discuss prioritizing variables based on how much they are used.
  2459. \section{Registers and Calling Conventions}
  2460. \label{sec:calling-conventions}
  2461. \index{calling conventions}
  2462. As we perform register allocation, we need to be aware of the
  2463. \emph{calling conventions} \index{calling conventions} that govern how
  2464. functions calls are performed in x86. Function calls require
  2465. coordination between the caller and the callee, which is often
  2466. assembly code written by different programmers or generated by
  2467. different compilers. Here we follow the System V calling conventions
  2468. that are used by the \code{gcc} compiler on Linux and
  2469. MacOS~\citep{Bryant:2005aa,Matz:2013aa}.
  2470. %
  2471. Even though $R_1$ does not include programmer-defined functions, our
  2472. generated code will 1) include a \code{main} function that the
  2473. operating system will call to initiate execution, and 2) make calls to
  2474. the \code{read\_int} function in our runtime system.
  2475. The calling conventions include rules about how functions share the
  2476. use of registers. In particular, the caller is responsible for freeing
  2477. up some registers prior to the function call for use by the callee.
  2478. These are called the \emph{caller-saved registers}
  2479. \index{caller-saved registers}
  2480. and they are
  2481. \begin{lstlisting}
  2482. rax rcx rdx rsi rdi r8 r9 r10 r11
  2483. \end{lstlisting}
  2484. On the other hand, the callee is responsible for preserving the values
  2485. of the \emph{callee-saved registers}, \index{callee-saved registers}
  2486. which are
  2487. \begin{lstlisting}
  2488. rsp rbp rbx r12 r13 r14 r15
  2489. \end{lstlisting}
  2490. We can think about this caller/callee convention from two points of
  2491. view, the caller view and the callee view:
  2492. \begin{itemize}
  2493. \item The caller should assume that all the caller-saved registers get
  2494. overwritten with arbitrary values by the callee. On the other hand,
  2495. the caller can safely assume that all the callee-saved registers
  2496. contain the same values after the call that they did before the
  2497. call.
  2498. \item The callee can freely use any of the caller-saved registers.
  2499. However, if the callee wants to use a callee-saved register, the
  2500. callee must arrange to put the original value back in the register
  2501. prior to returning to the caller, which is usually accomplished by
  2502. saving the value to the stack in the prelude of the function and
  2503. restoring the value in the conclusion of the function.
  2504. \end{itemize}
  2505. In x86, registers are also used for passing arguments to a function
  2506. and for the return value. In particular, the first six arguments of a
  2507. function are passed in the following six registers, in the order
  2508. given.
  2509. \begin{lstlisting}
  2510. rdi rsi rdx rcx r8 r9
  2511. \end{lstlisting}
  2512. If there are more than six arguments, then the convention is to use
  2513. space on the frame of the caller for the rest of the
  2514. arguments. However, in Chapter~\ref{ch:functions} we arrange to never
  2515. need more than six arguments. For now, the only function we care about
  2516. is \code{read\_int} and it takes zero argument.
  2517. %
  2518. The register \code{rax} is for the return value of a function.
  2519. The next question is how these calling conventions impact register
  2520. allocation. Consider the $R_1$ program in
  2521. Figure~\ref{fig:example-calling-conventions}. We first analyze this
  2522. example from the caller point of view and then from the callee point
  2523. of view.
  2524. The program makes two calls to the \code{read} function. Also, the
  2525. variable \code{x} is in-use during the second call to \code{read}, so
  2526. we need to make sure that the value in \code{x} does not get
  2527. accidentally wiped out by the call to \code{read}. One obvious
  2528. approach is to save all the values in caller-saved registers to the
  2529. stack prior to each function call, and restore them after each
  2530. call. That way, if the register allocator chooses to assign \code{x}
  2531. to a caller-saved register, its value will be preserved across the
  2532. call to \code{read}. However, the disadvantage of this approach is
  2533. that saving and restoring to the stack is relatively slow. If \code{x}
  2534. is not used many times, it may be better to assign \code{x} to a stack
  2535. location in the first place. Or better yet, if we can arrange for
  2536. \code{x} to be placed in a callee-saved register, then it won't need
  2537. to be saved and restored during function calls.
  2538. The approach that we recommend for variables that are in-use during a
  2539. function call is to either assign them to callee-saved registers or to
  2540. spill them to the stack. On the other hand, for variables that are not
  2541. in-use during a function call, we try the following alternatives in
  2542. order 1) look for an available caller-saved register (to leave room
  2543. for other variables in the callee-saved register), 2) look for a
  2544. callee-saved register, and 3) spill the variable to the stack.
  2545. It is straightforward to implement this approach in a graph coloring
  2546. register allocator. First, we know which variables are in-use during
  2547. every function call because we compute that information for every
  2548. instruction (Section~\ref{sec:liveness-analysis-r1}). Second, when we
  2549. build the interference graph (Section~\ref{sec:build-interference}),
  2550. we can place an edge between each of these variables and the
  2551. caller-saved registers in the interference graph. This will prevent
  2552. the graph coloring algorithm from assigning those variables to
  2553. caller-saved registers.
  2554. Returning to the example in
  2555. Figure~\ref{fig:example-calling-conventions}, let us analyze the
  2556. generated x86 code on the right-hand side, focusing on the
  2557. \code{start} block. Notice that variable \code{x} is assigned to
  2558. \code{rbx}, a callee-saved register. Thus, it is already in a safe
  2559. place during the second call to \code{read\_int}. Next, notice that
  2560. variable \code{y} is assigned to \code{rcx}, a caller-saved register,
  2561. because there are no function calls in the remainder of the block.
  2562. Next we analyze the example from the callee point of view, focusing on
  2563. the prelude and conclusion of the \code{main} function. As usual the
  2564. prelude begins with saving the \code{rbp} register to the stack and
  2565. setting the \code{rbp} to the current stack pointer. We now know why
  2566. it is necessary to save the \code{rbp}: it is a callee-saved register.
  2567. The prelude then pushes \code{rbx} to the stack because 1) \code{rbx}
  2568. is also a callee-saved register and 2) \code{rbx} is assigned to a
  2569. variable (\code{x}). There are several more callee-saved register that
  2570. are not saved in the prelude because they were not assigned to
  2571. variables. The prelude subtracts 8 bytes from the \code{rsp} to make
  2572. it 16-byte aligned and then jumps to the \code{start} block. Shifting
  2573. attention to the \code{conclusion}, we see that \code{rbx} is restored
  2574. from the stack with a \code{popq} instruction.
  2575. \index{prelude}\index{conclusion}
  2576. \begin{figure}[tp]
  2577. \begin{minipage}{0.45\textwidth}
  2578. Example $R_1$ program:
  2579. %s0_14.rkt
  2580. \begin{lstlisting}
  2581. (let ([x (read)])
  2582. (let ([y (read)])
  2583. (+ (+ x y) 42)))
  2584. \end{lstlisting}
  2585. \end{minipage}
  2586. \begin{minipage}{0.45\textwidth}
  2587. Generated x86 assembly:
  2588. \begin{lstlisting}
  2589. start:
  2590. callq read_int
  2591. movq %rax, %rbx
  2592. callq read_int
  2593. movq %rax, %rcx
  2594. addq %rcx, %rbx
  2595. movq %rbx, %rax
  2596. addq $42, %rax
  2597. jmp _conclusion
  2598. .globl main
  2599. main:
  2600. pushq %rbp
  2601. movq %rsp, %rbp
  2602. pushq %rbx
  2603. subq $8, %rsp
  2604. jmp start
  2605. conclusion:
  2606. addq $8, %rsp
  2607. popq %rbx
  2608. popq %rbp
  2609. retq
  2610. \end{lstlisting}
  2611. \end{minipage}
  2612. \caption{An example with function calls.}
  2613. \label{fig:example-calling-conventions}
  2614. \end{figure}
  2615. \section{Liveness Analysis}
  2616. \label{sec:liveness-analysis-r1}
  2617. \index{liveness analysis}
  2618. A variable or register is \emph{live} at a program point if its
  2619. current value is used at some later point in the program. We
  2620. refer to variables and registers collectively as \emph{locations}.
  2621. %
  2622. Consider the following code fragment in which there are two writes to
  2623. \code{b}. Are \code{a} and \code{b} both live at the same time?
  2624. \begin{lstlisting}[numbers=left,numberstyle=\tiny]
  2625. movq $5, a
  2626. movq $30, b
  2627. movq a, c
  2628. movq $10, b
  2629. addq b, c
  2630. \end{lstlisting}
  2631. The answer is no because the integer \code{30} written to \code{b} on
  2632. line 2 is never used. The variable \code{b} is read on line 5 and
  2633. there is an intervening write to \code{b} on line 4, so the read on
  2634. line 5 receives the value written on line 4, not line 2.
  2635. \begin{wrapfigure}[19]{l}[1.0in]{0.6\textwidth}
  2636. \small
  2637. \begin{tcolorbox}[title=\href{https://docs.racket-lang.org/reference/sets.html}{The Racket Set Package}]
  2638. A \emph{set} is an unordered collection of elements without duplicates.
  2639. \index{set}
  2640. \begin{description}
  2641. \item[$\LP\code{set}\,v\,\ldots\RP$] constructs a set containing the specified elements.
  2642. \item[$\LP\code{set-union}\,set_1\,set_2\RP$] returns the union of the two sets.
  2643. \item[$\LP\code{set-subtract}\,set_1\,set_2\RP$] returns the difference of the two sets.
  2644. \item[$\LP\code{set-member?}\,set\,v\RP$] is element $v$ in $set$?
  2645. \item[$\LP\code{set-count}\,set\RP$] how many unique elements are in $set$?
  2646. \item[$\LP\code{set->list}\,set\RP$] converts the set to a list.
  2647. \end{description}
  2648. \end{tcolorbox}
  2649. \end{wrapfigure}
  2650. The live locations can be computed by traversing the instruction
  2651. sequence back to front (i.e., backwards in execution order). Let
  2652. $I_1,\ldots, I_n$ be the instruction sequence. We write
  2653. $L_{\mathsf{after}}(k)$ for the set of live locations after
  2654. instruction $I_k$ and $L_{\mathsf{before}}(k)$ for the set of live
  2655. locations before instruction $I_k$. The live locations after an
  2656. instruction are always the same as the live locations before the next
  2657. instruction. \index{live-after} \index{live-before}
  2658. \begin{equation} \label{eq:live-after-before-next}
  2659. L_{\mathsf{after}}(k) = L_{\mathsf{before}}(k+1)
  2660. \end{equation}
  2661. To start things off, there are no live locations after the last
  2662. instruction\footnote{Technically, the \code{rax} register is live
  2663. but we do not use it for register allocation.}, so
  2664. \begin{equation}\label{eq:live-last-empty}
  2665. L_{\mathsf{after}}(n) = \emptyset
  2666. \end{equation}
  2667. We then apply the following rule repeatedly, traversing the
  2668. instruction sequence back to front.
  2669. \begin{equation}\label{eq:live-before-after-minus-writes-plus-reads}
  2670. L_{\mathtt{before}}(k) = (L_{\mathtt{after}}(k) - W(k)) \cup R(k),
  2671. \end{equation}
  2672. where $W(k)$ are the locations written to by instruction $I_k$ and
  2673. $R(k)$ are the locations read by instruction $I_k$.
  2674. There is a special case for \code{jmp} instructions. The locations
  2675. that are live before a \code{jmp} should be the locations that are
  2676. live before the instruction that follows the target label. So we
  2677. recommend maintaining an alist, perhaps called \code{label->live},
  2678. that maps each label to a set of such locations. Recall that for now,
  2679. the only \code{jmp} in a pseudo-x86 program is the one at the end, to
  2680. the \code{conclusion}. (For example, see Figure~\ref{fig:reg-eg}.) So
  2681. the alist should map \code{conclusion} to the set
  2682. $\{\ttm{rax},\ttm{rsp}\}$.
  2683. Let us walk through the above example, applying these formulas
  2684. starting with the instruction on line 5. We collect the answers in the
  2685. below listing. The $L_{\mathsf{after}}$ for the \code{addq b, c}
  2686. instruction is $\emptyset$ because it is the last instruction
  2687. (formula~\ref{eq:live-last-empty}). The $L_{\mathsf{before}}$ for
  2688. this instruction is $\{\ttm{b},\ttm{c}\}$ because it reads from
  2689. variables \code{b} and \code{c}
  2690. (formula~\ref{eq:live-before-after-minus-writes-plus-reads}), that is
  2691. \[
  2692. L_{\mathsf{before}}(5) = (\emptyset - \{\ttm{c}\}) \cup \{ \ttm{b}, \ttm{c} \} = \{ \ttm{b}, \ttm{c} \}
  2693. \]
  2694. Moving on the the instruction \code{movq \$10, b} at line 4, we copy
  2695. the live-before set from line 5 to be the live-after set for this
  2696. instruction (formula~\ref{eq:live-after-before-next}).
  2697. \[
  2698. L_{\mathsf{after}}(4) = \{ \ttm{b}, \ttm{c} \}
  2699. \]
  2700. This move instruction writes to \code{b} and does not read from any
  2701. variables, so we have the following live-before set
  2702. (formula~\ref{eq:live-before-after-minus-writes-plus-reads}).
  2703. \[
  2704. L_{\mathsf{before}}(4) = (\{\ttm{b},\ttm{c}\} - \{\ttm{b}\}) \cup \emptyset = \{ \ttm{c} \}
  2705. \]
  2706. The live-before for instruction \code{movq a, c}
  2707. is $\{\ttm{a}\}$ because it writes to $\{\ttm{c}\}$ and reads from $\{\ttm{a}\}$
  2708. (formula~\ref{eq:live-before-after-minus-writes-plus-reads}). The
  2709. live-before for \code{movq \$30, b} is $\{\ttm{a}\}$ because it writes to a
  2710. variable that is not live and does not read from a variable.
  2711. Finally, the live-before for \code{movq \$5, a} is $\emptyset$
  2712. because it writes to variable \code{a}.
  2713. \begin{center}
  2714. \begin{minipage}{0.45\textwidth}
  2715. \begin{lstlisting}[numbers=left,numberstyle=\tiny]
  2716. movq $5, a
  2717. movq $30, b
  2718. movq a, c
  2719. movq $10, b
  2720. addq b, c
  2721. \end{lstlisting}
  2722. \end{minipage}
  2723. \vrule\hspace{10pt}
  2724. \begin{minipage}{0.45\textwidth}
  2725. \begin{align*}
  2726. L_{\mathsf{before}}(1)= \emptyset,
  2727. L_{\mathsf{after}}(1)= \{\ttm{a}\}\\
  2728. L_{\mathsf{before}}(2)= \{\ttm{a}\},
  2729. L_{\mathsf{after}}(2)= \{\ttm{a}\}\\
  2730. L_{\mathsf{before}}(3)= \{\ttm{a}\},
  2731. L_{\mathsf{after}}(2)= \{\ttm{c}\}\\
  2732. L_{\mathsf{before}}(4)= \{\ttm{c}\},
  2733. L_{\mathsf{after}}(4)= \{\ttm{b},\ttm{c}\}\\
  2734. L_{\mathsf{before}}(5)= \{\ttm{b},\ttm{c}\},
  2735. L_{\mathsf{after}}(5)= \emptyset
  2736. \end{align*}
  2737. \end{minipage}
  2738. \end{center}
  2739. Figure~\ref{fig:live-eg} shows the results of liveness analysis for
  2740. the running example program, with the live-before and live-after sets
  2741. shown between each instruction to make the figure easy to read.
  2742. \begin{figure}[tp]
  2743. \hspace{20pt}
  2744. \begin{minipage}{0.45\textwidth}
  2745. \begin{lstlisting}
  2746. |$\{\ttm{rsp}\}$|
  2747. movq $1, v
  2748. |$\{\ttm{v},\ttm{rsp}\}$|
  2749. movq $42, w
  2750. |$\{\ttm{v},\ttm{w},\ttm{rsp}\}$|
  2751. movq v, x
  2752. |$\{\ttm{w},\ttm{x},\ttm{rsp}\}$|
  2753. addq $7, x
  2754. |$\{\ttm{w},\ttm{x},\ttm{rsp}\}$|
  2755. movq x, y
  2756. |$\{\ttm{w},\ttm{x},\ttm{y},\ttm{rsp}\}$|
  2757. movq x, z
  2758. |$\{\ttm{w},\ttm{y},\ttm{z},\ttm{rsp}\}$|
  2759. addq w, z
  2760. |$\{\ttm{y},\ttm{z},\ttm{rsp}\}$|
  2761. movq y, t
  2762. |$\{\ttm{t},\ttm{z},\ttm{rsp}\}$|
  2763. negq t
  2764. |$\{\ttm{t},\ttm{z},\ttm{rsp}\}$|
  2765. movq z, %rax
  2766. |$\{\ttm{rax},\ttm{t},\ttm{rsp}\}$|
  2767. addq t, %rax
  2768. |$\{\ttm{rax},\ttm{rsp}\}$|
  2769. jmp conclusion
  2770. \end{lstlisting}
  2771. \end{minipage}
  2772. \caption{The running example annotated with live-after sets.}
  2773. \label{fig:live-eg}
  2774. \end{figure}
  2775. \begin{exercise}\normalfont
  2776. Implement the compiler pass named \code{uncover-live} that computes
  2777. the live-after sets. We recommend storing the live-after sets (a list
  2778. of a set of variables) in the $\itm{info}$ field of the \code{Block}
  2779. structure.
  2780. %
  2781. We recommend organizing your code to use a helper function that takes
  2782. a list of instructions and an initial live-after set (typically empty)
  2783. and returns the list of live-after sets.
  2784. %
  2785. We recommend creating helper functions to 1) compute the set of
  2786. locations that appear in an argument (of an instruction), 2) compute
  2787. the locations read by an instruction which corresponds to the $R$
  2788. function discussed above, and 3) the locations written by an
  2789. instruction which corresponds to $W$. The \code{callq} instruction
  2790. should include all of the caller-saved registers in its write-set $W$
  2791. because the calling convention says that those registers may be
  2792. written to during the function call. Likewise, the \code{callq}
  2793. instruction should include the appropriate number of argument passing
  2794. registers in its read-set $R$, depending on the arity of the function
  2795. being called. (This is why the abstract syntax for \code{callq}
  2796. includes the arity.)
  2797. \end{exercise}
  2798. \section{Building the Interference Graph}
  2799. \label{sec:build-interference}
  2800. \begin{wrapfigure}[27]{r}[1.0in]{0.6\textwidth}
  2801. \small
  2802. \begin{tcolorbox}[title=\href{https://docs.racket-lang.org/graph/index.html}{The Racket Graph Library}]
  2803. A \emph{graph} is a collection of vertices and edges where each
  2804. edge connects two vertices. A graph is \emph{directed} if each
  2805. edge points from a source to a target. Otherwise the graph is
  2806. \emph{undirected}.
  2807. \index{graph}\index{directed graph}\index{undirected graph}
  2808. \begin{description}
  2809. \item[$\LP\code{directed-graph}\,\itm{edges}\RP$] constructs a
  2810. directed graph from a list of edges. Each edge is a list
  2811. containing the source and target vertex.
  2812. \item[$\LP\code{undirected-graph}\,\itm{edges}\RP$] constructs a
  2813. undirected graph from a list of edges. Each edge is represented by
  2814. a list containing two vertices.
  2815. \item[$\LP\code{add-vertex!}\,\itm{graph}\,\itm{vertex}\RP$]
  2816. inserts a vertex into the graph.
  2817. \item[$\LP\code{add-edge!}\,\itm{graph}\,\itm{source}\,\itm{target}\RP$]
  2818. inserts an edge between the two vertices into the graph.
  2819. \item[$\LP\code{in-neighbors}\,\itm{graph}\,\itm{vertex}\RP$]
  2820. returns a sequence of all the neighbors of the given vertex.
  2821. \item[$\LP\code{in-vertices}\,\itm{graph}\RP$]
  2822. returns a sequence of all the vertices in the graph.
  2823. \end{description}
  2824. \end{tcolorbox}
  2825. \end{wrapfigure}
  2826. Based on the liveness analysis, we know where each location is used
  2827. (read from). However, during register allocation, we need to answer
  2828. questions of the specific form: are locations $u$ and $v$ live at the
  2829. same time? (And therefore cannot be assigned to the same register.)
  2830. To make this question easier to answer, we create an explicit data
  2831. structure, an \emph{interference graph}\index{interference graph}. An
  2832. interference graph is an undirected graph that has an edge between two
  2833. locations if they are live at the same time, that is, if they
  2834. interfere with each other.
  2835. The most obvious way to compute the interference graph is to look at
  2836. the set of live location between each statement in the program and add
  2837. an edge to the graph for every pair of variables in the same set.
  2838. This approach is less than ideal for two reasons. First, it can be
  2839. expensive because it takes $O(n^2)$ time to look at every pair in a
  2840. set of $n$ live locations. Second, there is a special case in which
  2841. two locations that are live at the same time do not actually interfere
  2842. with each other: when they both contain the same value because we have
  2843. assigned one to the other.
  2844. A better way to compute the interference graph is to focus on the
  2845. writes~\cite{Appel:2003fk}. We do not want the writes performed by an
  2846. instruction to overwrite something in a live location. So for each
  2847. instruction, we create an edge between the locations being written to
  2848. and all the other live locations. (Except that one should not create
  2849. self edges.) Recall that for a \key{callq} instruction, we consider
  2850. all of the caller-saved registers as being written to, so an edge will
  2851. be added between every live variable and every caller-saved
  2852. register. For \key{movq}, we deal with the above-mentioned special
  2853. case by not adding an edge between a live variable $v$ and destination
  2854. $d$ if $v$ matches the source of the move. So we have the following
  2855. two rules.
  2856. \begin{enumerate}
  2857. \item If instruction $I_k$ is a move such as \key{movq} $s$\key{,}
  2858. $d$, then add the edge $(d,v)$ for every $v \in
  2859. L_{\mathsf{after}}(k)$ unless $v = d$ or $v = s$.
  2860. \item For any other instruction $I_k$, for every $d \in W(k)$
  2861. add an edge $(d,v)$ for every $v \in L_{\mathsf{after}}(k)$ unless $v = d$.
  2862. %% \item If instruction $I_k$ is an arithmetic instruction such as
  2863. %% \code{addq} $s$\key{,} $d$, then add the edge $(d,v)$ for every $v \in
  2864. %% L_{\mathsf{after}}(k)$ unless $v = d$.
  2865. %% \item If instruction $I_k$ is of the form \key{callq}
  2866. %% $\mathit{label}$, then add an edge $(r,v)$ for every caller-saved
  2867. %% register $r$ and every variable $v \in L_{\mathsf{after}}(k)$.
  2868. \end{enumerate}
  2869. Working from the top to bottom of Figure~\ref{fig:live-eg}, we apply
  2870. the above rules to each instruction. We highlight a few of the
  2871. instructions and then refer the reader to
  2872. Figure~\ref{fig:interference-results} for all the interference
  2873. results. The first instruction is \lstinline{movq $1, v}, so rule 3
  2874. applies, and the live-after set is $\{\ttm{v}\}$. We do not add any
  2875. interference edges because the one live variable \code{v} is also the
  2876. destination of this instruction.
  2877. %
  2878. For the second instruction, \lstinline{movq $42, w}, so rule 3 applies
  2879. again, and the live-after set is $\{\ttm{v},\ttm{w}\}$. So the target
  2880. $\ttm{w}$ of \key{movq} interferes with $\ttm{v}$.
  2881. %
  2882. Next we skip forward to the instruction \lstinline{movq x, y}.
  2883. \begin{figure}[tbp]
  2884. \begin{quote}
  2885. \begin{tabular}{ll}
  2886. \lstinline!movq $1, v!& \ttm{v} interferes with \ttm{rsp},\\
  2887. \lstinline!movq $42, w!& \ttm{w} interferes with \ttm{v} and \ttm{rsp},\\
  2888. \lstinline!movq v, x!& \ttm{x} interferes with \ttm{w} and \ttm{rsp},\\
  2889. \lstinline!addq $7, x!& \ttm{x} interferes with \ttm{w} and \ttm{rsp},\\
  2890. \lstinline!movq x, y!& \ttm{y} interferes with \ttm{w} and \ttm{rsp} but not \ttm{x},\\
  2891. \lstinline!movq x, z!& \ttm{z} interferes with \ttm{w}, \ttm{y}, and \ttm{rsp},\\
  2892. \lstinline!addq w, z!& \ttm{z} interferes with \ttm{y} and \ttm{rsp}, \\
  2893. \lstinline!movq y, t!& \ttm{t} interferes with \ttm{z} and \ttm{rsp}, \\
  2894. \lstinline!negq t!& \ttm{t} interferes with \ttm{z} and \ttm{rsp}, \\
  2895. \lstinline!movq z, %rax! & \ttm{rax} interferes with \ttm{t} and \ttm{rsp}, \\
  2896. \lstinline!addq t, %rax! & \ttm{rax} interferes with \ttm{rsp}. \\
  2897. \lstinline!jmp conclusion!& no interference.
  2898. \end{tabular}
  2899. \end{quote}
  2900. \caption{Interference results for the running example.}
  2901. \label{fig:interference-results}
  2902. \end{figure}
  2903. The resulting interference graph is shown in
  2904. Figure~\ref{fig:interfere}.
  2905. \begin{figure}[tbp]
  2906. \large
  2907. \[
  2908. \begin{tikzpicture}[baseline=(current bounding box.center)]
  2909. \node (rax) at (0,0) {$\ttm{rax}$};
  2910. \node (rsp) at (9,2) {$\ttm{rsp}$};
  2911. \node (t1) at (0,2) {$\ttm{t}$};
  2912. \node (z) at (3,2) {$\ttm{z}$};
  2913. \node (x) at (6,2) {$\ttm{x}$};
  2914. \node (y) at (3,0) {$\ttm{y}$};
  2915. \node (w) at (6,0) {$\ttm{w}$};
  2916. \node (v) at (9,0) {$\ttm{v}$};
  2917. \draw (t1) to (rax);
  2918. \draw (t1) to (z);
  2919. \draw (z) to (y);
  2920. \draw (z) to (w);
  2921. \draw (x) to (w);
  2922. \draw (y) to (w);
  2923. \draw (v) to (w);
  2924. \draw (v) to (rsp);
  2925. \draw (w) to (rsp);
  2926. \draw (x) to (rsp);
  2927. \draw (y) to (rsp);
  2928. \path[-.,bend left=15] (z) edge node {} (rsp);
  2929. \path[-.,bend left=10] (t1) edge node {} (rsp);
  2930. \draw (rax) to (rsp);
  2931. \end{tikzpicture}
  2932. \]
  2933. \caption{The interference graph of the example program.}
  2934. \label{fig:interfere}
  2935. \end{figure}
  2936. %% Our next concern is to choose a data structure for representing the
  2937. %% interference graph. There are many choices for how to represent a
  2938. %% graph, for example, \emph{adjacency matrix}, \emph{adjacency list},
  2939. %% and \emph{edge set}~\citep{Cormen:2001uq}. The right way to choose a
  2940. %% data structure is to study the algorithm that uses the data structure,
  2941. %% determine what operations need to be performed, and then choose the
  2942. %% data structure that provide the most efficient implementations of
  2943. %% those operations. Often times the choice of data structure can have an
  2944. %% effect on the time complexity of the algorithm, as it does here. If
  2945. %% you skim the next section, you will see that the register allocation
  2946. %% algorithm needs to ask the graph for all of its vertices and, given a
  2947. %% vertex, it needs to known all of the adjacent vertices. Thus, the
  2948. %% correct choice of graph representation is that of an adjacency
  2949. %% list. There are helper functions in \code{utilities.rkt} for
  2950. %% representing graphs using the adjacency list representation:
  2951. %% \code{make-graph}, \code{add-edge}, and \code{adjacent}
  2952. %% (Appendix~\ref{appendix:utilities}).
  2953. %% %
  2954. %% \margincomment{\footnotesize To do: change to use the
  2955. %% Racket graph library. \\ --Jeremy}
  2956. %% %
  2957. %% In particular, those functions use a hash table to map each vertex to
  2958. %% the set of adjacent vertices, and the sets are represented using
  2959. %% Racket's \key{set}, which is also a hash table.
  2960. \begin{exercise}\normalfont
  2961. Implement the compiler pass named \code{build-interference} according
  2962. to the algorithm suggested above. We recommend using the \code{graph}
  2963. package to create and inspect the interference graph. The output
  2964. graph of this pass should be stored in the $\itm{info}$ field of the
  2965. program, under the key \code{conflicts}.
  2966. \end{exercise}
  2967. \section{Graph Coloring via Sudoku}
  2968. \label{sec:graph-coloring}
  2969. \index{graph coloring}
  2970. \index{Sudoku}
  2971. \index{color}
  2972. We come to the main event, mapping variables to registers (or to stack
  2973. locations in the event that we run out of registers). We need to make
  2974. sure that two variables do not get mapped to the same register if the
  2975. two variables interfere with each other. Thinking about the
  2976. interference graph, this means that adjacent vertices must be mapped
  2977. to different registers. If we think of registers as colors, the
  2978. register allocation problem becomes the widely-studied graph coloring
  2979. problem~\citep{Balakrishnan:1996ve,Rosen:2002bh}.
  2980. The reader may be more familiar with the graph coloring problem than he
  2981. or she realizes; the popular game of Sudoku is an instance of the
  2982. graph coloring problem. The following describes how to build a graph
  2983. out of an initial Sudoku board.
  2984. \begin{itemize}
  2985. \item There is one vertex in the graph for each Sudoku square.
  2986. \item There is an edge between two vertices if the corresponding squares
  2987. are in the same row, in the same column, or if the squares are in
  2988. the same $3\times 3$ region.
  2989. \item Choose nine colors to correspond to the numbers $1$ to $9$.
  2990. \item Based on the initial assignment of numbers to squares in the
  2991. Sudoku board, assign the corresponding colors to the corresponding
  2992. vertices in the graph.
  2993. \end{itemize}
  2994. If you can color the remaining vertices in the graph with the nine
  2995. colors, then you have also solved the corresponding game of Sudoku.
  2996. Figure~\ref{fig:sudoku-graph} shows an initial Sudoku game board and
  2997. the corresponding graph with colored vertices. We map the Sudoku
  2998. number 1 to blue, 2 to yellow, and 3 to red. We only show edges for a
  2999. sampling of the vertices (the colored ones) because showing edges for
  3000. all of the vertices would make the graph unreadable.
  3001. \begin{figure}[tbp]
  3002. \includegraphics[width=0.45\textwidth]{figs/sudoku}
  3003. \includegraphics[width=0.5\textwidth]{figs/sudoku-graph}
  3004. \caption{A Sudoku game board and the corresponding colored graph.}
  3005. \label{fig:sudoku-graph}
  3006. \end{figure}
  3007. Given that Sudoku is an instance of graph coloring, one can use Sudoku
  3008. strategies to come up with an algorithm for allocating registers. For
  3009. example, one of the basic techniques for Sudoku is called Pencil
  3010. Marks. The idea is to use a process of elimination to determine what
  3011. numbers no longer make sense for a square and write down those
  3012. numbers in the square (writing very small). For example, if the number
  3013. $1$ is assigned to a square, then by process of elimination, you can
  3014. write the pencil mark $1$ in all the squares in the same row, column,
  3015. and region. Many Sudoku computer games provide automatic support for
  3016. Pencil Marks.
  3017. %
  3018. The Pencil Marks technique corresponds to the notion of
  3019. \emph{saturation}\index{saturation} due to \cite{Brelaz:1979eu}.
  3020. The saturation of a
  3021. vertex, in Sudoku terms, is the set of numbers that are no longer
  3022. available. In graph terminology, we have the following definition:
  3023. \begin{equation*}
  3024. \mathrm{saturation}(u) = \{ c \;|\; \exists v. v \in \mathrm{neighbors}(u)
  3025. \text{ and } \mathrm{color}(v) = c \}
  3026. \end{equation*}
  3027. where $\mathrm{neighbors}(u)$ is the set of vertices that share an
  3028. edge with $u$.
  3029. Using the Pencil Marks technique leads to a simple strategy for
  3030. filling in numbers: if there is a square with only one possible number
  3031. left, then choose that number! But what if there are no squares with
  3032. only one possibility left? One brute-force approach is to try them
  3033. all: choose the first and if it ultimately leads to a solution,
  3034. great. If not, backtrack and choose the next possibility. One good
  3035. thing about Pencil Marks is that it reduces the degree of branching in
  3036. the search tree. Nevertheless, backtracking can be horribly time
  3037. consuming. One way to reduce the amount of backtracking is to use the
  3038. most-constrained-first heuristic. That is, when choosing a square,
  3039. always choose one with the fewest possibilities left (the vertex with
  3040. the highest saturation). The idea is that choosing highly constrained
  3041. squares earlier rather than later is better because later on there may
  3042. not be any possibilities left for those squares.
  3043. However, register allocation is easier than Sudoku because the
  3044. register allocator can map variables to stack locations when the
  3045. registers run out. Thus, it makes sense to drop backtracking in favor
  3046. of greedy search, that is, make the best choice at the time and keep
  3047. going. We still wish to minimize the number of colors needed, so
  3048. keeping the most-constrained-first heuristic is a good idea.
  3049. Figure~\ref{fig:satur-algo} gives the pseudo-code for a simple greedy
  3050. algorithm for register allocation based on saturation and the
  3051. most-constrained-first heuristic. It is roughly equivalent to the
  3052. DSATUR algorithm of \cite{Brelaz:1979eu} (also known as saturation
  3053. degree ordering~\citep{Gebremedhin:1999fk,Omari:2006uq}). Just as in
  3054. Sudoku, the algorithm represents colors with integers. The integers
  3055. $0$ through $k-1$ correspond to the $k$ registers that we use for
  3056. register allocation. The integers $k$ and larger correspond to stack
  3057. locations. The registers that are not used for register allocation,
  3058. such as \code{rax}, are assigned to negative integers. In particular,
  3059. we assign $-1$ to \code{rax} and $-2$ to \code{rsp}.
  3060. One might wonder why we include registers at all in the liveness
  3061. analysis and interference graph, for example, we never allocate a
  3062. variable to \code{rax} and \code{rsp}, so it would be harmless to
  3063. leave them out. As we see in Chapter~\ref{ch:tuples}, when we begin
  3064. to use register for passing arguments to functions, it will be
  3065. necessary for those registers to appear in the interference graph
  3066. because those registers will also be assigned to variables, and we
  3067. don't want those two uses to encroach on each other. Regarding
  3068. registers such as \code{rax} and \code{rsp} that are not used for
  3069. variables, we could omit them from the interference graph but that
  3070. would require adding special cases to our algorithm, which would
  3071. complicate the logic for little gain.
  3072. \begin{figure}[btp]
  3073. \centering
  3074. \begin{lstlisting}[basicstyle=\rmfamily,deletekeywords={for,from,with,is,not,in,find},morekeywords={while},columns=fullflexible]
  3075. Algorithm: DSATUR
  3076. Input: a graph |$G$|
  3077. Output: an assignment |$\mathrm{color}[v]$| for each vertex |$v \in G$|
  3078. |$W \gets \mathrm{vertices}(G)$|
  3079. while |$W \neq \emptyset$| do
  3080. pick a vertex |$u$| from |$W$| with the highest saturation,
  3081. breaking ties randomly
  3082. find the lowest color |$c$| that is not in |$\{ \mathrm{color}[v] \;:\; v \in \mathrm{adjacent}(u)\}$|
  3083. |$\mathrm{color}[u] \gets c$|
  3084. |$W \gets W - \{u\}$|
  3085. \end{lstlisting}
  3086. \caption{The saturation-based greedy graph coloring algorithm.}
  3087. \label{fig:satur-algo}
  3088. \end{figure}
  3089. With the DSATUR algorithm in hand, let us return to the running
  3090. example and consider how to color the interference graph in
  3091. Figure~\ref{fig:interfere}.
  3092. %
  3093. We color the vertices for registers with their own color. For example,
  3094. \code{rax} is assigned the color $-1$ and \code{rsp} is assigned $-2$.
  3095. The vertices for variables are not yet colored, so they annotated with
  3096. a dash. We then update the saturation for vertices that are adjacent
  3097. to a register. For example, the saturation for \code{t} is $\{-1,-2\}$
  3098. because it interferes with both \code{rax} and \code{rsp}.
  3099. \[
  3100. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3101. \node (rax) at (0,0) {$\ttm{rax}:-1,\{-2\}$};
  3102. \node (rsp) at (10,2) {$\ttm{rsp}:-2,\{-1\}$};
  3103. \node (t1) at (0,2) {$\ttm{t}:-,\{-1,-2\}$};
  3104. \node (z) at (3,2) {$\ttm{z}:-,\{-2\}$};
  3105. \node (x) at (6,2) {$\ttm{x}:-,\{-2\}$};
  3106. \node (y) at (3,0) {$\ttm{y}:-,\{-2\}$};
  3107. \node (w) at (6,0) {$\ttm{w}:-,\{-2\}$};
  3108. \node (v) at (10,0) {$\ttm{v}:-,\{-2\}$};
  3109. \draw (t1) to (rax);
  3110. \draw (t1) to (z);
  3111. \draw (z) to (y);
  3112. \draw (z) to (w);
  3113. \draw (x) to (w);
  3114. \draw (y) to (w);
  3115. \draw (v) to (w);
  3116. \draw (v) to (rsp);
  3117. \draw (w) to (rsp);
  3118. \draw (x) to (rsp);
  3119. \draw (y) to (rsp);
  3120. \path[-.,bend left=15] (z) edge node {} (rsp);
  3121. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3122. \draw (rax) to (rsp);
  3123. \end{tikzpicture}
  3124. \]
  3125. The algorithm says to select a maximally saturated vertex. So we pick
  3126. $\ttm{t}$ and color it with the first available integer, which is
  3127. $0$. We mark $0$ as no longer available for $\ttm{z}$, $\ttm{rax}$,
  3128. and \ttm{rsp} because they interfere with $\ttm{t}$.
  3129. \[
  3130. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3131. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3132. \node (rsp) at (10,2) {$\ttm{rsp}:-2,\{-1,0\}$};
  3133. \node (t1) at (0,2) {$\ttm{t}:0,\{-1,-2\}$};
  3134. \node (z) at (3,2) {$\ttm{z}:-,\{0,-2\}$};
  3135. \node (x) at (6,2) {$\ttm{x}:-,\{-2\}$};
  3136. \node (y) at (3,0) {$\ttm{y}:-,\{-2\}$};
  3137. \node (w) at (6,0) {$\ttm{w}:-,\{-2\}$};
  3138. \node (v) at (10,0) {$\ttm{v}:-,\{-2\}$};
  3139. \draw (t1) to (rax);
  3140. \draw (t1) to (z);
  3141. \draw (z) to (y);
  3142. \draw (z) to (w);
  3143. \draw (x) to (w);
  3144. \draw (y) to (w);
  3145. \draw (v) to (w);
  3146. \draw (v) to (rsp);
  3147. \draw (w) to (rsp);
  3148. \draw (x) to (rsp);
  3149. \draw (y) to (rsp);
  3150. \path[-.,bend left=15] (z) edge node {} (rsp);
  3151. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3152. \draw (rax) to (rsp);
  3153. \end{tikzpicture}
  3154. \]
  3155. We repeat the process, selecting another maximally saturated
  3156. vertex, which is \code{z}, and color it with the first available
  3157. number, which is $1$. We add $1$ to the saturation for the
  3158. neighboring vertices \code{t}, \code{y}, \code{w}, and \code{rsp}.
  3159. \[
  3160. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3161. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3162. \node (rsp) at (10,2) {$\ttm{rsp}:-2,\{-1,0,1\}$};
  3163. \node (t1) at (0,2) {$\ttm{t}:0,\{-1,1,-2\}$};
  3164. \node (z) at (3,2) {$\ttm{z}:1,\{0,-2\}$};
  3165. \node (x) at (6,2) {$\ttm{x}:-,\{-2\}$};
  3166. \node (y) at (3,0) {$\ttm{y}:-,\{1,-2\}$};
  3167. \node (w) at (6,0) {$\ttm{w}:-,\{1,-2\}$};
  3168. \node (v) at (10,0) {$\ttm{v}:-,\{-2\}$};
  3169. \draw (t1) to (rax);
  3170. \draw (t1) to (z);
  3171. \draw (z) to (y);
  3172. \draw (z) to (w);
  3173. \draw (x) to (w);
  3174. \draw (y) to (w);
  3175. \draw (v) to (w);
  3176. \draw (v) to (rsp);
  3177. \draw (w) to (rsp);
  3178. \draw (x) to (rsp);
  3179. \draw (y) to (rsp);
  3180. \path[-.,bend left=15] (z) edge node {} (rsp);
  3181. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3182. \draw (rax) to (rsp);
  3183. \end{tikzpicture}
  3184. \]
  3185. The most saturated vertices are now \code{w} and \code{y}. We color
  3186. \code{w} with the first available color, which is $0$.
  3187. \[
  3188. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3189. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3190. \node (rsp) at (10,2) {$\ttm{rsp}:-2,\{-1,0,1\}$};
  3191. \node (t1) at (0,2) {$\ttm{t}:0,\{-1,1,-2\}$};
  3192. \node (z) at (3,2) {$\ttm{z}:1,\{0,-2\}$};
  3193. \node (x) at (6,2) {$\ttm{x}:-,\{0,-2\}$};
  3194. \node (y) at (3,0) {$\ttm{y}:-,\{0,1,-2\}$};
  3195. \node (w) at (6,0) {$\ttm{w}:0,\{1,-2\}$};
  3196. \node (v) at (10,0) {$\ttm{v}:-,\{0,-2\}$};
  3197. \draw (t1) to (rax);
  3198. \draw (t1) to (z);
  3199. \draw (z) to (y);
  3200. \draw (z) to (w);
  3201. \draw (x) to (w);
  3202. \draw (y) to (w);
  3203. \draw (v) to (w);
  3204. \draw (v) to (rsp);
  3205. \draw (w) to (rsp);
  3206. \draw (x) to (rsp);
  3207. \draw (y) to (rsp);
  3208. \path[-.,bend left=15] (z) edge node {} (rsp);
  3209. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3210. \draw (rax) to (rsp);
  3211. \end{tikzpicture}
  3212. \]
  3213. Vertex \code{y} is now the most highly saturated, so we color \code{y}
  3214. with $2$. We cannot choose $0$ or $1$ because those numbers are in
  3215. \code{y}'s saturation set. Indeed, \code{y} interferes with \code{w}
  3216. and \code{z}, whose colors are $0$ and $1$ respectively.
  3217. \[
  3218. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3219. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3220. \node (rsp) at (10,2) {$\ttm{rsp}:-2,\{-1,0,1,2\}$};
  3221. \node (t1) at (0,2) {$\ttm{t}:0,\{-1,1,-2\}$};
  3222. \node (z) at (3,2) {$\ttm{z}:1,\{0,2,-2\}$};
  3223. \node (x) at (6,2) {$\ttm{x}:-,\{0,-2\}$};
  3224. \node (y) at (3,0) {$\ttm{y}:2,\{0,1,-2\}$};
  3225. \node (w) at (6,0) {$\ttm{w}:0,\{1,2,-2\}$};
  3226. \node (v) at (10,0) {$\ttm{v}:-,\{0,-2\}$};
  3227. \draw (t1) to (rax);
  3228. \draw (t1) to (z);
  3229. \draw (z) to (y);
  3230. \draw (z) to (w);
  3231. \draw (x) to (w);
  3232. \draw (y) to (w);
  3233. \draw (v) to (w);
  3234. \draw (v) to (rsp);
  3235. \draw (w) to (rsp);
  3236. \draw (x) to (rsp);
  3237. \draw (y) to (rsp);
  3238. \path[-.,bend left=15] (z) edge node {} (rsp);
  3239. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3240. \draw (rax) to (rsp);
  3241. \end{tikzpicture}
  3242. \]
  3243. Now \code{x} and \code{v} are the most saturated, so we color \code{v} with $1$.
  3244. \[
  3245. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3246. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3247. \node (rsp) at (10,2) {$\ttm{rsp}:-2,\{-1,0,1,2\}$};
  3248. \node (t1) at (0,2) {$\ttm{t}:0,\{-1,1,-2\}$};
  3249. \node (z) at (3,2) {$\ttm{z}:1,\{0,2,-2\}$};
  3250. \node (x) at (6,2) {$\ttm{x}:-,\{0,-2\}$};
  3251. \node (y) at (3,0) {$\ttm{y}:2,\{0,1,-2\}$};
  3252. \node (w) at (6,0) {$\ttm{w}:0,\{1,2,-2\}$};
  3253. \node (v) at (10,0) {$\ttm{v}:1,\{0,-2\}$};
  3254. \draw (t1) to (rax);
  3255. \draw (t1) to (z);
  3256. \draw (z) to (y);
  3257. \draw (z) to (w);
  3258. \draw (x) to (w);
  3259. \draw (y) to (w);
  3260. \draw (v) to (w);
  3261. \draw (v) to (rsp);
  3262. \draw (w) to (rsp);
  3263. \draw (x) to (rsp);
  3264. \draw (y) to (rsp);
  3265. \path[-.,bend left=15] (z) edge node {} (rsp);
  3266. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3267. \draw (rax) to (rsp);
  3268. \end{tikzpicture}
  3269. \]
  3270. In the last step of the algorithm, we color \code{x} with $1$.
  3271. \[
  3272. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3273. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3274. \node (rsp) at (10,2) {$\ttm{rsp}:-2,\{-1,0,1,2\}$};
  3275. \node (t1) at (0,2) {$\ttm{t}:0,\{-1,1,-2\}$};
  3276. \node (z) at (3,2) {$\ttm{z}:1,\{0,2,-2\}$};
  3277. \node (x) at (6,2) {$\ttm{x}:1,\{0,-2\}$};
  3278. \node (y) at (3,0) {$\ttm{y}:2,\{0,1,-2\}$};
  3279. \node (w) at (6,0) {$\ttm{w}:0,\{1,2,-2\}$};
  3280. \node (v) at (10,0) {$\ttm{v}:1,\{0,-2\}$};
  3281. \draw (t1) to (rax);
  3282. \draw (t1) to (z);
  3283. \draw (z) to (y);
  3284. \draw (z) to (w);
  3285. \draw (x) to (w);
  3286. \draw (y) to (w);
  3287. \draw (v) to (w);
  3288. \draw (v) to (rsp);
  3289. \draw (w) to (rsp);
  3290. \draw (x) to (rsp);
  3291. \draw (y) to (rsp);
  3292. \path[-.,bend left=15] (z) edge node {} (rsp);
  3293. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3294. \draw (rax) to (rsp);
  3295. \end{tikzpicture}
  3296. \]
  3297. With the coloring complete, we finalize the assignment of variables to
  3298. registers and stack locations. Recall that if we have $k$ registers to
  3299. use for allocation, we map the first $k$ colors to registers and the
  3300. rest to stack locations. Suppose for the moment that we have just one
  3301. register to use for register allocation, \key{rcx}. Then the following
  3302. maps of colors to registers and stack allocations.
  3303. \[
  3304. \{ 0 \mapsto \key{\%rcx}, \; 1 \mapsto \key{-8(\%rbp)}, \; 2 \mapsto \key{-16(\%rbp)} \}
  3305. \]
  3306. Putting this mapping together with the above coloring of the
  3307. variables, we arrive at the following assignment.
  3308. \begin{gather*}
  3309. \{ \ttm{v} \mapsto \key{\%rcx}, \,
  3310. \ttm{w} \mapsto \key{\%rcx}, \,
  3311. \ttm{x} \mapsto \key{-8(\%rbp)}, \,
  3312. \ttm{y} \mapsto \key{-16(\%rbp)}, \\
  3313. \ttm{z} \mapsto \key{-8(\%rbp)}, \,
  3314. \ttm{t} \mapsto \key{\%rcx} \}
  3315. \end{gather*}
  3316. Applying this assignment to our running example, on the left, yields
  3317. the program on the right.
  3318. % why frame size of 32? -JGS
  3319. \begin{center}
  3320. \begin{minipage}{0.3\textwidth}
  3321. \begin{lstlisting}
  3322. movq $1, v
  3323. movq $42, w
  3324. movq v, x
  3325. addq $7, x
  3326. movq x, y
  3327. movq x, z
  3328. addq w, z
  3329. movq y, t
  3330. negq t
  3331. movq z, %rax
  3332. addq t, %rax
  3333. jmp conclusion
  3334. \end{lstlisting}
  3335. \end{minipage}
  3336. $\Rightarrow\qquad$
  3337. \begin{minipage}{0.45\textwidth}
  3338. \begin{lstlisting}
  3339. movq $1, %rcx
  3340. movq $42, %rcx
  3341. movq %rcx, -8(%rbp)
  3342. addq $7, -8(%rbp)
  3343. movq -8(%rbp), -16(%rbp)
  3344. movq -8(%rbp), -8(%rbp)
  3345. addq %rcx, -8(%rbp)
  3346. movq -16(%rbp), %rcx
  3347. negq %rcx
  3348. movq -8(%rbp), %rax
  3349. addq %rcx, %rax
  3350. jmp conclusion
  3351. \end{lstlisting}
  3352. \end{minipage}
  3353. \end{center}
  3354. The resulting program is almost an x86 program. The remaining step is
  3355. the patch instructions pass. In this example, the trivial move of
  3356. \code{-8(\%rbp)} to itself is deleted and the addition of
  3357. \code{-8(\%rbp)} to \key{-16(\%rbp)} is fixed by going through
  3358. \code{rax} as follows.
  3359. \begin{lstlisting}
  3360. movq -8(%rbp), %rax
  3361. addq %rax, -16(%rbp)
  3362. \end{lstlisting}
  3363. We recommend creating a helper function named \code{color-graph} that
  3364. takes an interference graph and a list of all the variables in the
  3365. program. This function should return a mapping of variables to their
  3366. colors (represented as natural numbers). By creating this helper
  3367. function, you will be able to reuse it in Chapter~\ref{ch:functions}
  3368. when you add support for functions. To prioritize the processing of
  3369. highly saturated nodes inside your \code{color-graph} function, we
  3370. recommend using the priority queue data structure (see the side bar on
  3371. the right). Note that you will also need to maintain a mapping from
  3372. variables to their ``handles'' in the priority queue so that you can
  3373. notify the priority queue when their saturation changes.
  3374. \begin{wrapfigure}[23]{r}[1.0in]{0.6\textwidth}
  3375. \small
  3376. \begin{tcolorbox}[title=Priority Queue]
  3377. A \emph{priority queue} is a collection of items in which the
  3378. removal of items is governed by priority. In a ``min'' queue,
  3379. lower priority items are removed first. An implementation is in
  3380. \code{priority\_queue.rkt} of the support code. \index{priority
  3381. queue} \index{minimum priority queue}
  3382. \begin{description}
  3383. \item[$\LP\code{make-pqueue}\,\itm{cmp}\RP$] constructs an empty
  3384. priority queue that uses the $\itm{cmp}$ predicate to determine
  3385. whether its first argument has lower or equal priority to its
  3386. second argument.
  3387. \item[$\LP\code{pqueue-count}\,\itm{queue}\RP$] returns the number of
  3388. items in the queue.
  3389. \item[$\LP\code{pqueue-push!}\,\itm{queue}\,\itm{item}\RP$] inserts
  3390. the item into the queue and returns a handle for the item in the
  3391. queue.
  3392. \item[$\LP\code{pqueue-pop!}\,\itm{queue}\RP$] returns the item with
  3393. the lowest priority.
  3394. \item[$\LP\code{pqueue-decrease-key!}\,\itm{queue}\,\itm{handle}\RP$]
  3395. notifies the queue that the priority has decreased for the item
  3396. associated with the given handle.
  3397. \end{description}
  3398. \end{tcolorbox}
  3399. \end{wrapfigure}
  3400. Once you have obtained the coloring from \code{color-graph}, you can
  3401. assign the variables to registers or stack locations and then reuse
  3402. code from the \code{assign-homes} pass from
  3403. Section~\ref{sec:assign-r1} to replace the variables with their
  3404. assigned location.
  3405. \begin{exercise}\normalfont
  3406. Implement the compiler pass \code{allocate-registers}, which should
  3407. come after the \code{build-interference} pass. The three new passes
  3408. described in this chapter replace the \code{assign-homes} pass of
  3409. Section~\ref{sec:assign-r1}.
  3410. %
  3411. Test your updated compiler by creating new example programs that
  3412. exercise all of the register allocation algorithm, such as forcing
  3413. variables to be spilled to the stack.
  3414. \end{exercise}
  3415. \section{Print x86}
  3416. \label{sec:print-x86-reg-alloc}
  3417. \index{calling conventions}
  3418. \index{prelude}\index{conclusion}
  3419. Recall that the \code{print-x86} pass generates the prelude and
  3420. conclusion instructions for the \code{main} function.
  3421. %
  3422. The prelude saved the values in \code{rbp} and \code{rsp} and the
  3423. conclusion returned those values to \code{rbp} and \code{rsp}. The
  3424. reason for this is that our \code{main} function must adhere to the
  3425. x86 calling conventions that we described in
  3426. Section~\ref{sec:calling-conventions}. Furthermore, if your register
  3427. allocator assigned variables to other callee-saved registers
  3428. (e.g. \code{rbx}, \code{r12}, etc.), then those variables must also be
  3429. saved to the stack in the prelude and restored in the conclusion. The
  3430. simplest approach is to save and restore all of the callee-saved
  3431. registers. The more efficient approach is to keep track of which
  3432. callee-saved registers were used and only save and restore
  3433. them. Either way, make sure to take this use of stack space into
  3434. account when you are calculating the size of the frame and adjusting
  3435. the \code{rsp} in the prelude. Also, don't forget that the size of the
  3436. frame needs to be a multiple of 16 bytes!
  3437. An overview of all of the passes involved in register allocation is
  3438. shown in Figure~\ref{fig:reg-alloc-passes}.
  3439. \begin{figure}[tbp]
  3440. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3441. \node (R1) at (0,2) {\large $R_1$};
  3442. \node (R1-2) at (3,2) {\large $R_1$};
  3443. \node (R1-3) at (6,2) {\large $R_1$};
  3444. \node (C0-1) at (3,0) {\large $C_0$};
  3445. \node (x86-2) at (3,-2) {\large $\text{x86}^{*}$};
  3446. \node (x86-3) at (6,-2) {\large $\text{x86}^{*}$};
  3447. \node (x86-4) at (9,-2) {\large $\text{x86}$};
  3448. \node (x86-5) at (9,-4) {\large $\text{x86}^{\dagger}$};
  3449. \node (x86-2-1) at (3,-4) {\large $\text{x86}^{*}$};
  3450. \node (x86-2-2) at (6,-4) {\large $\text{x86}^{*}$};
  3451. \path[->,bend left=15] (R1) edge [above] node {\ttfamily\footnotesize uniquify} (R1-2);
  3452. \path[->,bend left=15] (R1-2) edge [above] node {\ttfamily\footnotesize remove-complex.} (R1-3);
  3453. \path[->,bend left=15] (R1-3) edge [right] node {\ttfamily\footnotesize explicate-control} (C0-1);
  3454. \path[->,bend right=15] (C0-1) edge [left] node {\ttfamily\footnotesize select-instr.} (x86-2);
  3455. \path[->,bend left=15] (x86-2) edge [right] node {\ttfamily\footnotesize uncover-live} (x86-2-1);
  3456. \path[->,bend right=15] (x86-2-1) edge [below] node {\ttfamily\footnotesize build-inter.} (x86-2-2);
  3457. \path[->,bend right=15] (x86-2-2) edge [right] node {\ttfamily\footnotesize allocate-reg.} (x86-3);
  3458. \path[->,bend left=15] (x86-3) edge [above] node {\ttfamily\footnotesize patch-instr.} (x86-4);
  3459. \path[->,bend left=15] (x86-4) edge [right] node {\ttfamily\footnotesize print-x86} (x86-5);
  3460. \end{tikzpicture}
  3461. \caption{Diagram of the passes for $R_1$ with register allocation.}
  3462. \label{fig:reg-alloc-passes}
  3463. \end{figure}
  3464. \section{Challenge: Move Biasing}
  3465. \label{sec:move-biasing}
  3466. \index{move biasing}
  3467. This section describes an optional enhancement to register allocation
  3468. for those students who are looking for an extra challenge or who have
  3469. a deeper interest in register allocation.
  3470. We return to the running example, but we remove the supposition that
  3471. we only have one register to use. So we have the following mapping of
  3472. color numbers to registers.
  3473. \[
  3474. \{ 0 \mapsto \key{\%rbx}, \; 1 \mapsto \key{\%rcx}, \; 2 \mapsto \key{\%rdx} \}
  3475. \]
  3476. Using the same assignment of variables to color numbers that was
  3477. produced by the register allocator described in the last section, we
  3478. get the following program.
  3479. \begin{minipage}{0.3\textwidth}
  3480. \begin{lstlisting}
  3481. movq $1, v
  3482. movq $42, w
  3483. movq v, x
  3484. addq $7, x
  3485. movq x, y
  3486. movq x, z
  3487. addq w, z
  3488. movq y, t
  3489. negq t
  3490. movq z, %rax
  3491. addq t, %rax
  3492. jmp conclusion
  3493. \end{lstlisting}
  3494. \end{minipage}
  3495. $\Rightarrow\qquad$
  3496. \begin{minipage}{0.45\textwidth}
  3497. \begin{lstlisting}
  3498. movq $1, %rcx
  3499. movq $42, $rbx
  3500. movq %rcx, %rcx
  3501. addq $7, %rcx
  3502. movq %rcx, %rdx
  3503. movq %rcx, %rcx
  3504. addq %rbx, %rcx
  3505. movq %rdx, %rbx
  3506. negq %rbx
  3507. movq %rcx, %rax
  3508. addq %rbx, %rax
  3509. jmp conclusion
  3510. \end{lstlisting}
  3511. \end{minipage}
  3512. In the above output code there are two \key{movq} instructions that
  3513. can be removed because their source and target are the same. However,
  3514. if we had put \key{t}, \key{v}, \key{x}, and \key{y} into the same
  3515. register, we could instead remove three \key{movq} instructions. We
  3516. can accomplish this by taking into account which variables appear in
  3517. \key{movq} instructions with which other variables.
  3518. We say that two variables $p$ and $q$ are \emph{move
  3519. related}\index{move related} if they participate together in a
  3520. \key{movq} instruction, that is, \key{movq} $p$\key{,} $q$ or
  3521. \key{movq} $q$\key{,} $p$. When the register allocator chooses a color
  3522. for a variable, it should prefer a color that has already been used
  3523. for a move-related variable (assuming that they do not interfere). Of
  3524. course, this preference should not override the preference for
  3525. registers over stack locations. This preference should be used as a
  3526. tie breaker when choosing between registers or when choosing between
  3527. stack locations.
  3528. We recommend representing the move relationships in a graph, similar
  3529. to how we represented interference. The following is the \emph{move
  3530. graph} for our running example.
  3531. \[
  3532. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3533. \node (rax) at (0,0) {$\ttm{rax}$};
  3534. \node (rsp) at (9,2) {$\ttm{rsp}$};
  3535. \node (t) at (0,2) {$\ttm{t}$};
  3536. \node (z) at (3,2) {$\ttm{z}$};
  3537. \node (x) at (6,2) {$\ttm{x}$};
  3538. \node (y) at (3,0) {$\ttm{y}$};
  3539. \node (w) at (6,0) {$\ttm{w}$};
  3540. \node (v) at (9,0) {$\ttm{v}$};
  3541. \draw (v) to (x);
  3542. \draw (x) to (y);
  3543. \draw (x) to (z);
  3544. \draw (y) to (t);
  3545. \end{tikzpicture}
  3546. \]
  3547. Now we replay the graph coloring, pausing to see the coloring of
  3548. \code{y}. Recall the following configuration. The most saturated vertices
  3549. were \code{w} and \code{y}.
  3550. \[
  3551. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3552. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3553. \node (rsp) at (9,2) {$\ttm{rsp}:-2,\{-1,0,1,2\}$};
  3554. \node (t1) at (0,2) {$\ttm{t}:0,\{1,-2\}$};
  3555. \node (z) at (3,2) {$\ttm{z}:1,\{0,-2\}$};
  3556. \node (x) at (6,2) {$\ttm{x}:-,\{-2\}$};
  3557. \node (y) at (3,0) {$\ttm{y}:-,\{1,-2\}$};
  3558. \node (w) at (6,0) {$\ttm{w}:-,\{1,-2\}$};
  3559. \node (v) at (9,0) {$\ttm{v}:-,\{-2\}$};
  3560. \draw (t1) to (rax);
  3561. \draw (t1) to (z);
  3562. \draw (z) to (y);
  3563. \draw (z) to (w);
  3564. \draw (x) to (w);
  3565. \draw (y) to (w);
  3566. \draw (v) to (w);
  3567. \draw (v) to (rsp);
  3568. \draw (w) to (rsp);
  3569. \draw (x) to (rsp);
  3570. \draw (y) to (rsp);
  3571. \path[-.,bend left=15] (z) edge node {} (rsp);
  3572. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3573. \draw (rax) to (rsp);
  3574. \end{tikzpicture}
  3575. \]
  3576. %
  3577. Last time we chose to color \code{w} with $0$. But this time we see
  3578. that \code{w} is not move related to any vertex, but \code{y} is move
  3579. related to \code{t}. So we choose to color \code{y} the same color as
  3580. \code{t}, $0$.
  3581. \[
  3582. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3583. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3584. \node (rsp) at (9,2) {$\ttm{rsp}:-2,\{-1,0,1,2\}$};
  3585. \node (t1) at (0,2) {$\ttm{t}:0,\{1,-2\}$};
  3586. \node (z) at (3,2) {$\ttm{z}:1,\{0,-2\}$};
  3587. \node (x) at (6,2) {$\ttm{x}:-,\{-2\}$};
  3588. \node (y) at (3,0) {$\ttm{y}:0,\{1,-2\}$};
  3589. \node (w) at (6,0) {$\ttm{w}:-,\{0,1,-2\}$};
  3590. \node (v) at (9,0) {$\ttm{v}:-,\{-2\}$};
  3591. \draw (t1) to (rax);
  3592. \draw (t1) to (z);
  3593. \draw (z) to (y);
  3594. \draw (z) to (w);
  3595. \draw (x) to (w);
  3596. \draw (y) to (w);
  3597. \draw (v) to (w);
  3598. \draw (v) to (rsp);
  3599. \draw (w) to (rsp);
  3600. \draw (x) to (rsp);
  3601. \draw (y) to (rsp);
  3602. \path[-.,bend left=15] (z) edge node {} (rsp);
  3603. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3604. \draw (rax) to (rsp);
  3605. \end{tikzpicture}
  3606. \]
  3607. Now \code{w} is the most saturated, so we color it $2$.
  3608. \[
  3609. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3610. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3611. \node (rsp) at (9,2) {$\ttm{rsp}:-2,\{-1,0,1,2\}$};
  3612. \node (t1) at (0,2) {$\ttm{t}:0,\{1,-2\}$};
  3613. \node (z) at (3,2) {$\ttm{z}:1,\{0,2,-2\}$};
  3614. \node (x) at (6,2) {$\ttm{x}:-,\{2,-2\}$};
  3615. \node (y) at (3,0) {$\ttm{y}:0,\{1,2,-2\}$};
  3616. \node (w) at (6,0) {$\ttm{w}:2,\{0,1,-2\}$};
  3617. \node (v) at (9,0) {$\ttm{v}:-,\{2,-2\}$};
  3618. \draw (t1) to (rax);
  3619. \draw (t1) to (z);
  3620. \draw (z) to (y);
  3621. \draw (z) to (w);
  3622. \draw (x) to (w);
  3623. \draw (y) to (w);
  3624. \draw (v) to (w);
  3625. \draw (v) to (rsp);
  3626. \draw (w) to (rsp);
  3627. \draw (x) to (rsp);
  3628. \draw (y) to (rsp);
  3629. \path[-.,bend left=15] (z) edge node {} (rsp);
  3630. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3631. \draw (rax) to (rsp);
  3632. \end{tikzpicture}
  3633. \]
  3634. At this point, vertices \code{x} and \code{v} are most saturated, but
  3635. \code{x} is move related to \code{y} and \code{z}, so we color
  3636. \code{x} to $0$ to match \code{y}. Finally, we color \code{v} to $0$.
  3637. \[
  3638. \begin{tikzpicture}[baseline=(current bounding box.center)]
  3639. \node (rax) at (0,0) {$\ttm{rax}:-1,\{0,-2\}$};
  3640. \node (rsp) at (9,2) {$\ttm{rsp}:-2,\{-1,0,1,2\}$};
  3641. \node (t) at (0,2) {$\ttm{t}:0,\{1,-2\}$};
  3642. \node (z) at (3,2) {$\ttm{z}:1,\{0,2,-2\}$};
  3643. \node (x) at (6,2) {$\ttm{x}:0,\{2,-2\}$};
  3644. \node (y) at (3,0) {$\ttm{y}:0,\{1,2,-2\}$};
  3645. \node (w) at (6,0) {$\ttm{w}:2,\{0,1,-2\}$};
  3646. \node (v) at (9,0) {$\ttm{v}:0,\{2,-2\}$};
  3647. \draw (t1) to (rax);
  3648. \draw (t) to (z);
  3649. \draw (z) to (y);
  3650. \draw (z) to (w);
  3651. \draw (x) to (w);
  3652. \draw (y) to (w);
  3653. \draw (v) to (w);
  3654. \draw (v) to (rsp);
  3655. \draw (w) to (rsp);
  3656. \draw (x) to (rsp);
  3657. \draw (y) to (rsp);
  3658. \path[-.,bend left=15] (z) edge node {} (rsp);
  3659. \path[-.,bend left=10] (t1) edge node {} (rsp);
  3660. \draw (rax) to (rsp);
  3661. \end{tikzpicture}
  3662. \]
  3663. So we have the following assignment of variables to registers.
  3664. \begin{gather*}
  3665. \{ \ttm{v} \mapsto \key{\%rbx}, \,
  3666. \ttm{w} \mapsto \key{\%rdx}, \,
  3667. \ttm{x} \mapsto \key{\%rbx}, \,
  3668. \ttm{y} \mapsto \key{\%rbx}, \,
  3669. \ttm{z} \mapsto \key{\%rcx}, \,
  3670. \ttm{t} \mapsto \key{\%rbx} \}
  3671. \end{gather*}
  3672. We apply this register assignment to the running example, on the left,
  3673. to obtain the code in the middle. The \code{patch-instructions} then
  3674. removes the three trivial moves from \key{rbx} to \key{rbx} to obtain
  3675. the code on the right.
  3676. \begin{minipage}{0.25\textwidth}
  3677. \begin{lstlisting}
  3678. movq $1, v
  3679. movq $42, w
  3680. movq v, x
  3681. addq $7, x
  3682. movq x, y
  3683. movq x, z
  3684. addq w, z
  3685. movq y, t
  3686. negq t
  3687. movq z, %rax
  3688. addq t, %rax
  3689. jmp conclusion
  3690. \end{lstlisting}
  3691. \end{minipage}
  3692. $\Rightarrow\qquad$
  3693. \begin{minipage}{0.25\textwidth}
  3694. \begin{lstlisting}
  3695. movq $1, %rbx
  3696. movq $42, %rdx
  3697. movq %rbx, %rbx
  3698. addq $7, %rbx
  3699. movq %rbx, %rbx
  3700. movq %rbx, %rcx
  3701. addq %rdx, %rcx
  3702. movq %rbx, %rbx
  3703. negq %rbx
  3704. movq %rcx, %rax
  3705. addq %rbx, %rax
  3706. jmp conclusion
  3707. \end{lstlisting}
  3708. \end{minipage}
  3709. $\Rightarrow\qquad$
  3710. \begin{minipage}{0.25\textwidth}
  3711. \begin{lstlisting}
  3712. movq $1, %rbx
  3713. movq $42, %rdx
  3714. addq $7, %rbx
  3715. movq %rbx, %rcx
  3716. addq %rdx, %rcx
  3717. negq %rbx
  3718. movq %rcx, %rax
  3719. addq %rbx, %rax
  3720. jmp conclusion
  3721. \end{lstlisting}
  3722. \end{minipage}
  3723. \begin{exercise}\normalfont
  3724. Change your implementation of \code{allocate-registers} to take move
  3725. biasing into account. Make sure that your compiler still passes all of
  3726. the previous tests. Create two new tests that include at least one
  3727. opportunity for move biasing and visually inspect the output x86
  3728. programs to make sure that your move biasing is working properly.
  3729. \end{exercise}
  3730. \margincomment{\footnotesize To do: another neat challenge would be to do
  3731. live range splitting~\citep{Cooper:1998ly}. \\ --Jeremy}
  3732. \section{Output of the Running Example}
  3733. \label{sec:reg-alloc-output}
  3734. \index{prelude}\index{conclusion}
  3735. Figure~\ref{fig:running-example-x86} shows the x86 code generated for
  3736. the running example (Figure~\ref{fig:reg-eg}) with register allocation
  3737. and move biasing. To demonstrate both the use of registers and the
  3738. stack, we have limited the register allocator to use just two
  3739. registers: \code{rbx} and \code{rcx}. In the prelude of the
  3740. \code{main} function, we push \code{rbx} onto the stack because it is
  3741. a callee-saved register and it was assigned to variable by the
  3742. register allocator. We subtract \code{8} from the \code{rsp} at the
  3743. end of the prelude to reserve space for the one spilled variable.
  3744. After that subtraction, the \code{rsp} is aligned to 16 bytes.
  3745. Moving on the the \code{start} block, we see how the registers were
  3746. allocated. Variables \code{v}, \code{x}, and \code{y} were assigned to
  3747. \code{rbx} and variable \code{z} was assigned to \code{rcx}. Variable
  3748. \code{w} was spilled to the stack location \code{-16(\%rbp)}. Recall
  3749. that the prelude saved the callee-save register \code{rbx} onto the
  3750. stack. The spilled variables must be placed lower on the stack than
  3751. the saved callee-save registers, so in this case \code{w} is placed at
  3752. \code{-16(\%rbp)}.
  3753. In the \code{conclusion}, we undo the work that was done in the
  3754. prelude. We move the stack pointer up by \code{8} bytes (the room for
  3755. spilled variables), then we pop the old values of \code{rbx} and
  3756. \code{rbp} (callee-saved registers), and finish with \code{retq} to
  3757. return control to the operating system.
  3758. \begin{figure}[tbp]
  3759. % s0_28.rkt
  3760. % (use-minimal-set-of-registers! #t)
  3761. % and only rbx rcx
  3762. % tmp 0 rbx
  3763. % z 1 rcx
  3764. % y 0 rbx
  3765. % w 2 16(%rbp)
  3766. % v 0 rbx
  3767. % x 0 rbx
  3768. \begin{lstlisting}
  3769. start:
  3770. movq $1, %rbx
  3771. movq $42, -16(%rbp)
  3772. addq $7, %rbx
  3773. movq %rbx, %rcx
  3774. addq -16(%rbp), %rcx
  3775. negq %rbx
  3776. movq %rcx, %rax
  3777. addq %rbx, %rax
  3778. jmp conclusion
  3779. .globl main
  3780. main:
  3781. pushq %rbp
  3782. movq %rsp, %rbp
  3783. pushq %rbx
  3784. subq $8, %rsp
  3785. jmp start
  3786. conclusion:
  3787. addq $8, %rsp
  3788. popq %rbx
  3789. popq %rbp
  3790. retq
  3791. \end{lstlisting}
  3792. \caption{The x86 output from the running example (Figure~\ref{fig:reg-eg}).}
  3793. \label{fig:running-example-x86}
  3794. \end{figure}
  3795. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  3796. \chapter{Booleans and Control Flow}
  3797. \label{ch:bool-types}
  3798. \index{Boolean}
  3799. \index{control flow}
  3800. \index{conditional expression}
  3801. The $R_0$ and $R_1$ languages only have a single kind of value, the
  3802. integers. In this chapter we add a second kind of value, the Booleans,
  3803. to create the $R_2$ language. The Boolean values \emph{true} and
  3804. \emph{false} are written \key{\#t} and \key{\#f} respectively in
  3805. Racket. The $R_2$ language includes several operations that involve
  3806. Booleans (\key{and}, \key{not}, \key{eq?}, \key{<}, etc.) and the
  3807. conditional \key{if} expression. With the addition of \key{if}
  3808. expressions, programs can have non-trivial control flow which which
  3809. significantly impacts the \code{explicate-control} and the liveness
  3810. analysis for register allocation. Also, because we now have two kinds
  3811. of values, we need to handle programs that apply an operation to the
  3812. wrong kind of value, such as \code{(not 1)}.
  3813. There are two language design options for such situations. One option
  3814. is to signal an error and the other is to provide a wider
  3815. interpretation of the operation. The Racket language uses a mixture of
  3816. these two options, depending on the operation and the kind of
  3817. value. For example, the result of \code{(not 1)} in Racket is
  3818. \code{\#f} because Racket treats non-zero integers as if they were
  3819. \code{\#t}. On the other hand, \code{(car 1)} results in a run-time
  3820. error in Racket stating that \code{car} expects a pair.
  3821. The Typed Racket language makes similar design choices as Racket,
  3822. except much of the error detection happens at compile time instead of
  3823. run time. Like Racket, Typed Racket accepts and runs \code{(not 1)},
  3824. producing \code{\#f}. But in the case of \code{(car 1)}, Typed Racket
  3825. reports a compile-time error because Typed Racket expects the type of
  3826. the argument to be of the form \code{(Listof T)} or \code{(Pairof T1 T2)}.
  3827. For the $R_2$ language we choose to be more like Typed Racket in that
  3828. we perform type checking during compilation. In
  3829. Chapter~\ref{ch:type-dynamic} we study the alternative choice, that
  3830. is, how to compile a dynamically typed language like Racket. The
  3831. $R_2$ language is a subset of Typed Racket but by no means includes
  3832. all of Typed Racket. For many operations we take a narrower
  3833. interpretation than Typed Racket, for example, rejecting \code{(not 1)}.
  3834. This chapter is organized as follows. We begin by defining the syntax
  3835. and interpreter for the $R_2$ language (Section~\ref{sec:r2-lang}). We
  3836. then introduce the idea of type checking and build a type checker for
  3837. $R_2$ (Section~\ref{sec:type-check-r2}). To compile $R_2$ we need to
  3838. enlarge the intermediate language $C_0$ into $C_1$, which we do in
  3839. Section~\ref{sec:c1}. The remaining sections of this chapter discuss
  3840. how our compiler passes need to change to accommodate Booleans and
  3841. conditional control flow.
  3842. \section{The $R_2$ Language}
  3843. \label{sec:r2-lang}
  3844. The concrete syntax of the $R_2$ language is defined in
  3845. Figure~\ref{fig:r2-concrete-syntax} and the abstract syntax is defined
  3846. in Figure~\ref{fig:r2-syntax}. The $R_2$ language includes all of
  3847. $R_1$ (shown in gray), the Boolean literals \code{\#t} and \code{\#f},
  3848. and the conditional \code{if} expression. Also, we expand the
  3849. operators to include
  3850. \begin{enumerate}
  3851. \item subtraction on integers,
  3852. \item the logical operators \key{and}, \key{or} and \key{not},
  3853. \item the \key{eq?} operation for comparing two integers or two Booleans, and
  3854. \item the \key{<}, \key{<=}, \key{>}, and \key{>=} operations for
  3855. comparing integers.
  3856. \end{enumerate}
  3857. We reorganize the abstract syntax for the primitive operations in
  3858. Figure~\ref{fig:r2-syntax}, using only one grammar rule for all of
  3859. them. This means that the grammar no longer checks whether the arity
  3860. of an operators matches the number of arguments. That responsibility
  3861. is moved to the type checker for $R_2$, which we introduce in
  3862. Section~\ref{sec:type-check-r2}.
  3863. \begin{figure}[tp]
  3864. \centering
  3865. \fbox{
  3866. \begin{minipage}{0.96\textwidth}
  3867. \[
  3868. \begin{array}{lcl}
  3869. \itm{bool} &::=& \key{\#t} \mid \key{\#f} \\
  3870. \itm{cmp} &::= & \key{eq?} \mid \key{<} \mid \key{<=} \mid \key{>} \mid \key{>=} \\
  3871. \Exp &::=& \gray{ \Int \mid \CREAD{} \mid \CNEG{\Exp} \mid \CADD{\Exp}{\Exp} } \mid \CSUB{\Exp}{\Exp} \\
  3872. &\mid& \gray{ \Var \mid \CLET{\Var}{\Exp}{\Exp} } \\
  3873. &\mid& \itm{bool}
  3874. \mid (\key{and}\;\Exp\;\Exp) \mid (\key{or}\;\Exp\;\Exp)
  3875. \mid (\key{not}\;\Exp) \\
  3876. &\mid& (\itm{cmp}\;\Exp\;\Exp) \mid \CIF{\Exp}{\Exp}{\Exp} \\
  3877. R_2 &::=& \Exp
  3878. \end{array}
  3879. \]
  3880. \end{minipage}
  3881. }
  3882. \caption{The concrete syntax of $R_2$, extending $R_1$
  3883. (Figure~\ref{fig:r1-concrete-syntax}) with Booleans and conditionals.}
  3884. \label{fig:r2-concrete-syntax}
  3885. \end{figure}
  3886. \begin{figure}[tp]
  3887. \centering
  3888. \fbox{
  3889. \begin{minipage}{0.96\textwidth}
  3890. \[
  3891. \begin{array}{lcl}
  3892. \itm{bool} &::=& \code{\#t} \mid \code{\#f} \\
  3893. \itm{cmp} &::= & \code{eq?} \mid \code{<} \mid \code{<=} \mid \code{>} \mid \code{>=} \\
  3894. \itm{op} &::= & \itm{cmp} \mid \code{read} \mid \code{+} \mid \code{-}
  3895. \mid \code{and} \mid \code{or} \mid \code{not} \\
  3896. \Exp &::=& \gray{ \INT{\Int} \mid \VAR{\Var} \mid \LET{\Var}{\Exp}{\Exp} } \\
  3897. &\mid& \PRIM{\itm{op}}{\Exp\ldots}\\
  3898. &\mid& \BOOL{\itm{bool}} \mid \IF{\Exp}{\Exp}{\Exp} \\
  3899. R_2 &::=& \PROGRAM{\code{'()}}{\Exp}
  3900. \end{array}
  3901. \]
  3902. \end{minipage}
  3903. }
  3904. \caption{The abstract syntax of $R_2$.}
  3905. \label{fig:r2-syntax}
  3906. \end{figure}
  3907. Figure~\ref{fig:interp-R2} defines the interpreter for $R_2$,
  3908. inheriting from the interpreter for $R_1$
  3909. (Figure~\ref{fig:interp-R1}). The literals \code{\#t} and \code{\#f}
  3910. evaluate to the corresponding Boolean values. The conditional
  3911. expression $(\key{if}\, \itm{cnd}\,\itm{thn}\,\itm{els})$ evaluates
  3912. the Boolean expression \itm{cnd} and then either evaluates \itm{thn}
  3913. or \itm{els} depending on whether \itm{cnd} produced \code{\#t} or
  3914. \code{\#f}. The logical operations \code{not} and \code{and} behave as
  3915. you might expect, but note that the \code{and} operation is
  3916. short-circuiting. That is, given the expression
  3917. $(\key{and}\,e_1\,e_2)$, the expression $e_2$ is not evaluated if
  3918. $e_1$ evaluates to \code{\#f}.
  3919. With the increase in the number of primitive operations, the
  3920. interpreter code for them could become repetitive without some
  3921. care. We factor out the different parts of the code for primitive
  3922. operations into the \code{interp-op} method shown in in
  3923. Figure~\ref{fig:interp-op-R2}. The match clause for \code{Prim} makes
  3924. the recursive calls to interpret the arguments and then passes the
  3925. resulting values to \code{interp-op}. We do not use \code{interp-op}
  3926. for the \code{and} operation because of its short-circuiting behavior.
  3927. \begin{figure}[tbp]
  3928. \begin{lstlisting}
  3929. (define interp-R2-class
  3930. (class interp-R1-class
  3931. (super-new)
  3932. (define/public (interp-op op) ...)
  3933. (define/override ((interp-exp env) e)
  3934. (define recur (interp-exp env))
  3935. (match e
  3936. [(Bool b) b]
  3937. [(If cnd thn els)
  3938. (define b (recur cnd))
  3939. (match b
  3940. [#t (recur thn)]
  3941. [#f (recur els)])]
  3942. [(Prim 'and (list e1 e2))
  3943. (define v1 (recur e1))
  3944. (match v1
  3945. [#t (match (recur e2) [#t #t] [#f #f])]
  3946. [#f #f])]
  3947. [(Prim op args)
  3948. (apply (interp-op op) (for/list ([e args]) (recur e)))]
  3949. [else ((super interp-exp env) e)]
  3950. ))
  3951. ))
  3952. (define (interp-R2 p)
  3953. (send (new interp-R2-class) interp-program p))
  3954. \end{lstlisting}
  3955. \caption{Interpreter for the $R_2$ language. (See
  3956. Figure~\ref{fig:interp-op-R2} for \code{interp-op}.)}
  3957. \label{fig:interp-R2}
  3958. \end{figure}
  3959. \begin{figure}[tbp]
  3960. \begin{lstlisting}
  3961. (define/public (interp-op op)
  3962. (match op
  3963. ['+ fx+]
  3964. ['- fx-]
  3965. ['read read-fixnum]
  3966. ['not (lambda (v) (match v [#t #f] [#f #t]))]
  3967. ['or (lambda (v1 v2)
  3968. (cond [(and (boolean? v1) (boolean? v2))
  3969. (or v1 v2)]))]
  3970. ['eq? (lambda (v1 v2)
  3971. (cond [(or (and (fixnum? v1) (fixnum? v2))
  3972. (and (boolean? v1) (boolean? v2))
  3973. (and (vector? v1) (vector? v2)))
  3974. (eq? v1 v2)]))]
  3975. ['< (lambda (v1 v2)
  3976. (cond [(and (fixnum? v1) (fixnum? v2))
  3977. (< v1 v2)]))]
  3978. ['<= (lambda (v1 v2)
  3979. (cond [(and (fixnum? v1) (fixnum? v2))
  3980. (<= v1 v2)]))]
  3981. ['> (lambda (v1 v2)
  3982. (cond [(and (fixnum? v1) (fixnum? v2))
  3983. (> v1 v2)]))]
  3984. ['>= (lambda (v1 v2)
  3985. (cond [(and (fixnum? v1) (fixnum? v2))
  3986. (>= v1 v2)]))]
  3987. [else (error 'interp-op "unknown operator")]
  3988. ))
  3989. \end{lstlisting}
  3990. \caption{Interpreter for the primitive operators in the $R_2$ language.}
  3991. \label{fig:interp-op-R2}
  3992. \end{figure}
  3993. \section{Type Checking $R_2$ Programs}
  3994. \label{sec:type-check-r2}
  3995. \index{type checking}
  3996. \index{semantic analysis}
  3997. It is helpful to think about type checking in two complementary
  3998. ways. A type checker predicts the type of value that will be produced
  3999. by each expression in the program. For $R_2$, we have just two types,
  4000. \key{Integer} and \key{Boolean}. So a type checker should predict that
  4001. \begin{lstlisting}
  4002. (+ 10 (- (+ 12 20)))
  4003. \end{lstlisting}
  4004. produces an \key{Integer} while
  4005. \begin{lstlisting}
  4006. (and (not #f) #t)
  4007. \end{lstlisting}
  4008. produces a \key{Boolean}.
  4009. Another way to think about type checking is that it enforces a set of
  4010. rules about which operators can be applied to which kinds of
  4011. values. For example, our type checker for $R_2$ will signal an error
  4012. for the below expression because, as we have seen above, the
  4013. expression \code{(+ 10 ...)} has type \key{Integer} but the type
  4014. checker enforces the rule that the argument of \code{not} must be a
  4015. \key{Boolean}.
  4016. \begin{lstlisting}
  4017. (not (+ 10 (- (+ 12 20))))
  4018. \end{lstlisting}
  4019. We implement type checking using classes and method overriding for the
  4020. same reason that we use them to implement the interpreters. We
  4021. separate the type checker for the $R_1$ fragment into its own class,
  4022. shown in Figure~\ref{fig:type-check-R1}. The type checker for $R_2$ is
  4023. shown in Figure~\ref{fig:type-check-R2}; inherits from the one for
  4024. $R_1$. The code for these type checkers are in the files
  4025. \code{type-check-R1.rkt} and \code{type-check-R2.rkt} of the support
  4026. code.
  4027. %
  4028. Each type checker is a structurally recursive function over the AST.
  4029. Given an input expression \code{e}, the type checker either signals an
  4030. error or returns an expression and its type (\key{Integer} or
  4031. \key{Boolean}). There are situations in which we want to change or
  4032. update the expression.
  4033. %
  4034. The type of an integer literal is \code{Integer} and
  4035. the type of a Boolean literal is \code{Boolean}. To handle variables,
  4036. the type checker uses the environment \code{env} to map variables to
  4037. types. Consider the clause for \key{let}. We type check the
  4038. initializing expression to obtain its type \key{T} and then associate
  4039. type \code{T} with the variable \code{x} in the environment used to
  4040. type check the body of the \key{let}. Thus, when the type checker
  4041. encounters a use of variable \code{x}, it can find its type in the
  4042. environment.
  4043. \begin{figure}[tbp]
  4044. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  4045. (define type-check-R1-class
  4046. (class object%
  4047. (super-new)
  4048. (define/public (operator-types)
  4049. '((+ . ((Integer Integer) . Integer))
  4050. (- . ((Integer) . Integer))
  4051. (read . (() . Integer))))
  4052. (define/public (type-equal? t1 t2) (equal? t1 t2))
  4053. (define/public (check-type-equal? t1 t2 e)
  4054. (unless (type-equal? t1 t2)
  4055. (error 'type-check "~a != ~a\nin ~v" t1 t2 e)))
  4056. (define/public (type-check-op op arg-types e)
  4057. (match (dict-ref (operator-types) op)
  4058. [`(,param-types . ,return-type)
  4059. (for ([at arg-types] [pt param-types])
  4060. (check-type-equal? at pt e))
  4061. return-type]
  4062. [else (error 'type-check-op "unrecognized ~a" op)]))
  4063. (define/public (type-check-exp env)
  4064. (lambda (e)
  4065. (debug 'type-check-exp "R1" e)
  4066. (match e
  4067. [(Var x) (values (Var x) (dict-ref env x))]
  4068. [(Int n) (values (Int n) 'Integer)]
  4069. [(Let x e body)
  4070. (define-values (e^ Te) ((type-check-exp env) e))
  4071. (define-values (b Tb) ((type-check-exp (dict-set env x Te)) body))
  4072. (values (Let x e^ b) Tb)]
  4073. [(Prim op es)
  4074. (define-values (new-es ts)
  4075. (for/lists (exprs types) ([e es]) ((type-check-exp env) e)))
  4076. (values (Prim op new-es) (type-check-op op ts e))]
  4077. [else (error 'type-check-exp "couldn't match" e)])))
  4078. (define/public (type-check-program e)
  4079. (match e
  4080. [(Program info body)
  4081. (define-values (body^ Tb) ((type-check-exp '()) body))
  4082. (check-type-equal? Tb 'Integer body)
  4083. (Program info body^)]
  4084. [else (error 'type-check-R1 "couldn't match ~a" e)]))
  4085. ))
  4086. (define (type-check-R1 p)
  4087. (send (new type-check-R1-class) type-check-program p))
  4088. \end{lstlisting}
  4089. \caption{Type checker for the $R_1$ fragment of $R_2$.}
  4090. \label{fig:type-check-R1}
  4091. \end{figure}
  4092. \begin{figure}[tbp]
  4093. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  4094. (define type-check-R2-class
  4095. (class type-check-R1-class
  4096. (super-new)
  4097. (inherit check-type-equal?)
  4098. (define/override (operator-types)
  4099. (append '((- . ((Integer Integer) . Integer))
  4100. (and . ((Boolean Boolean) . Boolean))
  4101. (or . ((Boolean Boolean) . Boolean))
  4102. (< . ((Integer Integer) . Boolean))
  4103. (<= . ((Integer Integer) . Boolean))
  4104. (> . ((Integer Integer) . Boolean))
  4105. (>= . ((Integer Integer) . Boolean))
  4106. (not . ((Boolean) . Boolean))
  4107. )
  4108. (super operator-types)))
  4109. (define/override (type-check-exp env)
  4110. (lambda (e)
  4111. (match e
  4112. [(Bool b) (values (Bool b) 'Boolean)]
  4113. [(If cnd thn els)
  4114. (define-values (cnd^ Tc) ((type-check-exp env) cnd))
  4115. (define-values (thn^ Tt) ((type-check-exp env) thn))
  4116. (define-values (els^ Te) ((type-check-exp env) els))
  4117. (check-type-equal? Tc 'Boolean e)
  4118. (check-type-equal? Tt Te e)
  4119. (values (If cnd^ thn^ els^) Te)]
  4120. [(Prim 'eq? (list e1 e2))
  4121. (define-values (e1^ T1) ((type-check-exp env) e1))
  4122. (define-values (e2^ T2) ((type-check-exp env) e2))
  4123. (check-type-equal? T1 T2 e)
  4124. (values (Prim 'eq? (list e1^ e2^)) 'Boolean)]
  4125. [else ((super type-check-exp env) e)])))
  4126. ))
  4127. (define (type-check-R2 p)
  4128. (send (new type-check-R2-class) type-check-program p))
  4129. \end{lstlisting}
  4130. \caption{Type checker for the $R_2$ language.}
  4131. \label{fig:type-check-R2}
  4132. \end{figure}
  4133. Three auxiliary methods are used in the type checker. The method
  4134. \code{operator-types} defines a dictionary that maps the operator
  4135. names to their parameter and return types. The \code{type-equal?}
  4136. method determines whether two types are equal, which for now simply
  4137. dispatches to \code{equal?} (deep equality). The \code{type-check-op}
  4138. method looks up the operator in the \code{operator-types} dictionary
  4139. and then checks whether the argument types are equal to the parameter
  4140. types. The result is the return type of the operator.
  4141. \begin{exercise}\normalfont
  4142. Create 10 new example programs in $R_2$. Half of the example programs
  4143. should have a type error. For those programs, to signal that a type
  4144. error is expected, create an empty file with the same base name but
  4145. with file extension \code{.tyerr}. For example, if the test
  4146. \code{r2\_14.rkt} is expected to error, then create an empty file
  4147. named \code{r2\_14.tyerr}. The other half of the example programs
  4148. should not have type errors. Note that if the type checker does not
  4149. signal an error for a program, then interpreting that program should
  4150. not encounter an error.
  4151. \end{exercise}
  4152. \section{Shrink the $R_2$ Language}
  4153. \label{sec:shrink-r2}
  4154. The $R_2$ language includes several operators that are easily
  4155. expressible in terms of other operators. For example, subtraction is
  4156. expressible in terms of addition and negation.
  4157. \[
  4158. \key{(-}\; e_1 \; e_2\key{)} \quad \Rightarrow \quad \LP\key{+} \; e_1 \; \LP\key{-} \; e_2\RP\RP
  4159. \]
  4160. Several of the comparison operations are expressible in terms of
  4161. less-than and logical negation.
  4162. \[
  4163. \LP\key{<=}\; e_1 \; e_2\RP \quad \Rightarrow \quad
  4164. \LP\key{let}~\LP\LS\key{tmp.1}~e_1\RS\RP~\LP\key{not}\;\LP\key{<}\;e_2\;\key{tmp.1})\RP\RP
  4165. \]
  4166. The \key{let} is needed in the above translation to ensure that
  4167. expression $e_1$ is evaluated before $e_2$.
  4168. By performing these translations near the front-end of the compiler,
  4169. the later passes of the compiler do not need to deal with these
  4170. constructs, making those passes shorter. On the other hand, sometimes
  4171. these translations make it more difficult to generate the most
  4172. efficient code with respect to the number of instructions. However,
  4173. these differences typically do not affect the number of accesses to
  4174. memory, which is the primary factor that determines execution time on
  4175. modern computer architectures.
  4176. \begin{exercise}\normalfont
  4177. Implement the pass \code{shrink} that removes subtraction,
  4178. \key{and}, \key{or}, \key{<=}, \key{>}, and \key{>=} from the language
  4179. by translating them to other constructs in $R_2$. Create tests to
  4180. make sure that the behavior of all of these constructs stays the
  4181. same after translation.
  4182. \end{exercise}
  4183. \section{The x86$_1$ Language}
  4184. \label{sec:x86-1}
  4185. \index{x86}
  4186. To implement the new logical operations, the comparison operations,
  4187. and the \key{if} expression, we need to delve further into the x86
  4188. language. Figures~\ref{fig:x86-1-concrete} and \ref{fig:x86-1} define
  4189. the concrete and abstract syntax for a larger subset of x86 that
  4190. includes instructions for logical operations, comparisons, and
  4191. conditional jumps.
  4192. One small challenge is that x86 does not provide an instruction that
  4193. directly implements logical negation (\code{not} in $R_2$ and $C_1$).
  4194. However, the \code{xorq} instruction can be used to encode \code{not}.
  4195. The \key{xorq} instruction takes two arguments, performs a pairwise
  4196. exclusive-or ($\mathrm{XOR}$) operation on each bit of its arguments,
  4197. and writes the results into its second argument. Recall the truth
  4198. table for exclusive-or:
  4199. \begin{center}
  4200. \begin{tabular}{l|cc}
  4201. & 0 & 1 \\ \hline
  4202. 0 & 0 & 1 \\
  4203. 1 & 1 & 0
  4204. \end{tabular}
  4205. \end{center}
  4206. For example, applying $\mathrm{XOR}$ to each bit of the binary numbers
  4207. $0011$ and $0101$ yields $0110$. Notice that in the row of the table
  4208. for the bit $1$, the result is the opposite of the second bit. Thus,
  4209. the \code{not} operation can be implemented by \code{xorq} with $1$ as
  4210. the first argument:
  4211. \[
  4212. \Var~ \key{=}~ \LP\key{not}~\Arg\RP\key{;}
  4213. \qquad\Rightarrow\qquad
  4214. \begin{array}{l}
  4215. \key{movq}~ \Arg\key{,} \Var\\
  4216. \key{xorq}~ \key{\$1,} \Var
  4217. \end{array}
  4218. \]
  4219. \begin{figure}[tp]
  4220. \fbox{
  4221. \begin{minipage}{0.96\textwidth}
  4222. \[
  4223. \begin{array}{lcl}
  4224. \itm{bytereg} &::=& \key{ah} \mid \key{al} \mid \key{bh} \mid \key{bl}
  4225. \mid \key{ch} \mid \key{cl} \mid \key{dh} \mid \key{dl} \\
  4226. \Arg &::=& \gray{ \key{\$}\Int \mid \key{\%}\Reg \mid \Int\key{(}\key{\%}\Reg\key{)} } \mid \key{\%}\itm{bytereg}\\
  4227. \itm{cc} & ::= & \key{e} \mid \key{l} \mid \key{le} \mid \key{g} \mid \key{ge} \\
  4228. \Instr &::=& \gray{ \key{addq} \; \Arg\key{,} \Arg \mid
  4229. \key{subq} \; \Arg\key{,} \Arg \mid
  4230. \key{negq} \; \Arg \mid \key{movq} \; \Arg\key{,} \Arg \mid } \\
  4231. && \gray{ \key{callq} \; \itm{label} \mid
  4232. \key{pushq}\;\Arg \mid \key{popq}\;\Arg \mid \key{retq} \mid \key{jmp}\,\itm{label} } \\
  4233. && \gray{ \itm{label}\key{:}\; \Instr }
  4234. \mid \key{xorq}~\Arg\key{,}~\Arg
  4235. \mid \key{cmpq}~\Arg\key{,}~\Arg \mid \\
  4236. && \key{set}cc~\Arg
  4237. \mid \key{movzbq}~\Arg\key{,}~\Arg
  4238. \mid \key{j}cc~\itm{label}
  4239. \\
  4240. x86_1 &::= & \gray{ \key{.globl main} }\\
  4241. & & \gray{ \key{main:} \; \Instr\ldots }
  4242. \end{array}
  4243. \]
  4244. \end{minipage}
  4245. }
  4246. \caption{The concrete syntax of x86$_1$ (extends x86$_0$ of Figure~\ref{fig:x86-0-concrete}).}
  4247. \label{fig:x86-1-concrete}
  4248. \end{figure}
  4249. \begin{figure}[tp]
  4250. \fbox{
  4251. \begin{minipage}{0.96\textwidth}
  4252. \small
  4253. \[
  4254. \begin{array}{lcl}
  4255. \itm{bytereg} &::=& \key{ah} \mid \key{al} \mid \key{bh} \mid \key{bl}
  4256. \mid \key{ch} \mid \key{cl} \mid \key{dh} \mid \key{dl} \\
  4257. \Arg &::=& \gray{\IMM{\Int} \mid \REG{\Reg} \mid \DEREF{\Reg}{\Int}}
  4258. \mid \BYTEREG{\itm{bytereg}} \\
  4259. \itm{cc} & ::= & \key{e} \mid \key{l} \mid \key{le} \mid \key{g} \mid \key{ge} \\
  4260. \Instr &::=& \gray{ \BININSTR{\code{'addq}}{\Arg}{\Arg}
  4261. \mid \BININSTR{\code{'subq}}{\Arg}{\Arg} } \\
  4262. &\mid& \gray{ \BININSTR{\code{'movq}}{\Arg}{\Arg}
  4263. \mid \UNIINSTR{\code{'negq}}{\Arg} } \\
  4264. &\mid& \gray{ \CALLQ{\itm{label}}{\itm{int}} \mid \RETQ{}
  4265. \mid \PUSHQ{\Arg} \mid \POPQ{\Arg} \mid \JMP{\itm{label}} } \\
  4266. &\mid& \BININSTR{\code{'xorq}}{\Arg}{\Arg}
  4267. \mid \BININSTR{\code{'cmpq}}{\Arg}{\Arg}\\
  4268. &\mid& \BININSTR{\code{'set}}{\itm{cc}}{\Arg}
  4269. \mid \BININSTR{\code{'movzbq}}{\Arg}{\Arg}\\
  4270. &\mid& \JMPIF{\itm{cc}}{\itm{label}} \\
  4271. \Block &::= & \gray{\BLOCK{\itm{info}}{\Instr\ldots}} \\
  4272. x86_1 &::= & \gray{\PROGRAM{\itm{info}}{\CFG{\key{(}\itm{label} \,\key{.}\, \Block \key{)}\ldots}}}
  4273. \end{array}
  4274. \]
  4275. \end{minipage}
  4276. }
  4277. \caption{The abstract syntax of x86$_1$ (extends x86$_0$ of Figure~\ref{fig:x86-0-ast}).}
  4278. \label{fig:x86-1}
  4279. \end{figure}
  4280. Next we consider the x86 instructions that are relevant for compiling
  4281. the comparison operations. The \key{cmpq} instruction compares its two
  4282. arguments to determine whether one argument is less than, equal, or
  4283. greater than the other argument. The \key{cmpq} instruction is unusual
  4284. regarding the order of its arguments and where the result is
  4285. placed. The argument order is backwards: if you want to test whether
  4286. $x < y$, then write \code{cmpq} $y$\code{,} $x$. The result of
  4287. \key{cmpq} is placed in the special EFLAGS register. This register
  4288. cannot be accessed directly but it can be queried by a number of
  4289. instructions, including the \key{set} instruction. The \key{set}
  4290. instruction puts a \key{1} or \key{0} into its destination depending
  4291. on whether the comparison came out according to the condition code
  4292. \itm{cc} (\key{e} for equal, \key{l} for less, \key{le} for
  4293. less-or-equal, \key{g} for greater, \key{ge} for greater-or-equal).
  4294. The \key{set} instruction has an annoying quirk in that its
  4295. destination argument must be single byte register, such as \code{al}
  4296. (L for lower bits) or \code{ah} (H for higher bits), which are part of
  4297. the \code{rax} register. Thankfully, the \key{movzbq} instruction can
  4298. then be used to move from a single byte register to a normal 64-bit
  4299. register.
  4300. The x86 instruction for conditional jump are relevant to the
  4301. compilation of \key{if} expressions. The \key{JmpIf} instruction
  4302. updates the program counter to point to the instruction after the
  4303. indicated label depending on whether the result in the EFLAGS register
  4304. matches the condition code \itm{cc}, otherwise the \key{JmpIf}
  4305. instruction falls through to the next instruction. The abstract
  4306. syntax for \key{JmpIf} differs from the concrete syntax for x86 in
  4307. that it separates the instruction name from the condition code. For
  4308. example, \code{(JmpIf le foo)} corresponds to \code{jle foo}. Because
  4309. the \key{JmpIf} instruction relies on the EFLAGS register, it is
  4310. common for the \key{JmpIf} to be immediately preceded by a \key{cmpq}
  4311. instruction to set the EFLAGS register.
  4312. \section{The $C_1$ Intermediate Language}
  4313. \label{sec:c1}
  4314. As with $R_1$, we compile $R_2$ to a C-like intermediate language, but
  4315. we need to grow that intermediate language to handle the new features
  4316. in $R_2$: Booleans and conditional expressions.
  4317. Figure~\ref{fig:c1-syntax} defines the abstract syntax of $C_1$. (The
  4318. concrete syntax is in the Appendix,
  4319. Figure~\ref{fig:c1-concrete-syntax}.) The $C_1$ language adds logical
  4320. and comparison operators to the $\Exp$ non-terminal and the literals
  4321. \key{\#t} and \key{\#f} to the $\Arg$ non-terminal. Regarding control
  4322. flow, $C_1$ differs considerably from $R_2$. Instead of \key{if}
  4323. expressions, $C_1$ has \key{goto} and conditional \key{goto} in the
  4324. grammar for $\Tail$. This means that a sequence of statements may now
  4325. end with a \code{goto} or a conditional \code{goto}. The conditional
  4326. \code{goto} jumps to one of two labels depending on the outcome of the
  4327. comparison. In Section~\ref{sec:explicate-control-r2} we discuss how
  4328. to translate from $R_2$ to $C_1$, bridging this gap between \key{if}
  4329. expressions and \key{goto}'s.
  4330. \begin{figure}[tp]
  4331. \fbox{
  4332. \begin{minipage}{0.96\textwidth}
  4333. \small
  4334. \[
  4335. \begin{array}{lcl}
  4336. \Atm &::=& \gray{\INT{\Int} \mid \VAR{\Var}} \mid \BOOL{\itm{bool}} \\
  4337. \itm{cmp} &::= & \key{eq?} \mid \key{<} \\
  4338. \Exp &::= & \gray{ \Atm \mid \READ{} }\\
  4339. &\mid& \gray{ \NEG{\Atm} \mid \ADD{\Atm}{\Atm} } \\
  4340. &\mid& \UNIOP{\key{'not}}{\Atm}
  4341. \mid \BINOP{\key{'}\itm{cmp}}{\Atm}{\Atm} \\
  4342. \Stmt &::=& \gray{ \ASSIGN{\VAR{\Var}}{\Exp} } \\
  4343. \Tail &::= & \gray{\RETURN{\Exp} \mid \SEQ{\Stmt}{\Tail} }
  4344. \mid \GOTO{\itm{label}} \\
  4345. &\mid& \IFSTMT{\BINOP{\itm{cmp}}{\Atm}{\Atm}}{\GOTO{\itm{label}}}{\GOTO{\itm{label}}} \\
  4346. C_1 & ::= & \gray{\PROGRAM{\itm{info}}{\CFG{\key{(}\itm{label}\,\key{.}\,\Tail\key{)}\ldots}}}
  4347. \end{array}
  4348. \]
  4349. \end{minipage}
  4350. }
  4351. \caption{The abstract syntax of $C_1$, an extension of $C_0$
  4352. (Figure~\ref{fig:c0-syntax}).}
  4353. \label{fig:c1-syntax}
  4354. \end{figure}
  4355. \clearpage
  4356. \section{Remove Complex Operands}
  4357. \label{sec:remove-complex-opera-R2}
  4358. Add cases for \code{Bool} and \code{If} to the \code{rco-exp} and
  4359. \code{rco-atom} functions according to the definition of the output
  4360. language for this pass, $R_2^{\dagger}$, the administrative normal
  4361. form of $R_2$, which is defined in Figure~\ref{fig:r2-anf-syntax}. The
  4362. \code{Bool} form is an atomic expressions but \code{If} is not. All
  4363. three sub-expressions of an \code{If} are allowed to be complex
  4364. expressions in the output of \code{remove-complex-opera*}, but the
  4365. operands of \code{not} and the comparisons must be atoms. Regarding
  4366. the \code{If} form, it is particularly important to \textbf{not}
  4367. replace its condition with a temporary variable because that would
  4368. interfere with the generation of high-quality output in the
  4369. \code{explicate-control} pass.
  4370. \begin{figure}[tp]
  4371. \centering
  4372. \fbox{
  4373. \begin{minipage}{0.96\textwidth}
  4374. \[
  4375. \begin{array}{rcl}
  4376. \Atm &::=& \gray{ \INT{\Int} \mid \VAR{\Var} } \mid \BOOL{\itm{bool}}\\
  4377. \Exp &::=& \gray{ \Atm \mid \READ{} } \\
  4378. &\mid& \gray{ \NEG{\Atm} \mid \ADD{\Atm}{\Atm} } \\
  4379. &\mid& \gray{ \LET{\Var}{\Exp}{\Exp} } \\
  4380. &\mid& \UNIOP{\key{'not}}{\Atm} \\
  4381. &\mid& \BINOP{\itm{cmp}}{\Atm}{\Atm} \mid \IF{\Exp}{\Exp}{\Exp} \\
  4382. R^{\dagger}_2 &::=& \PROGRAM{\code{'()}}{\Exp}
  4383. \end{array}
  4384. \]
  4385. \end{minipage}
  4386. }
  4387. \caption{$R_2^{\dagger}$ is $R_2$ in administrative normal form (ANF).}
  4388. \label{fig:r2-anf-syntax}
  4389. \end{figure}
  4390. \section{Explicate Control}
  4391. \label{sec:explicate-control-r2}
  4392. Recall that the purpose of \code{explicate-control} is to make the
  4393. order of evaluation explicit in the syntax of the program. With the
  4394. addition of \key{if} in $R_2$ this get more interesting.
  4395. As a motivating example, consider the following program that has an
  4396. \key{if} expression nested in the predicate of another \key{if}.
  4397. % s1_41.rkt
  4398. \begin{center}
  4399. \begin{minipage}{0.96\textwidth}
  4400. \begin{lstlisting}
  4401. (let ([x (read)])
  4402. (let ([y (read)])
  4403. (if (if (< x 1) (eq? x 0) (eq? x 2))
  4404. (+ y 2)
  4405. (+ y 10))))
  4406. \end{lstlisting}
  4407. \end{minipage}
  4408. \end{center}
  4409. %
  4410. The naive way to compile \key{if} and the comparison would be to
  4411. handle each of them in isolation, regardless of their context. Each
  4412. comparison would be translated into a \key{cmpq} instruction followed
  4413. by a couple instructions to move the result from the EFLAGS register
  4414. into a general purpose register or stack location. Each \key{if} would
  4415. be translated into the combination of a \key{cmpq} and a conditional
  4416. jump. The generated code for the inner \key{if} in the above example
  4417. would be as follows.
  4418. \begin{center}
  4419. \begin{minipage}{0.96\textwidth}
  4420. \begin{lstlisting}
  4421. ...
  4422. cmpq $1, x ;; (< x 1)
  4423. setl %al
  4424. movzbq %al, tmp
  4425. cmpq $1, tmp ;; (if (< x 1) ...)
  4426. je then_branch_1
  4427. jmp else_branch_1
  4428. ...
  4429. \end{lstlisting}
  4430. \end{minipage}
  4431. \end{center}
  4432. However, if we take context into account we can do better and reduce
  4433. the use of \key{cmpq} and EFLAG-accessing instructions.
  4434. One idea is to try and reorganize the code at the level of $R_2$,
  4435. pushing the outer \key{if} inside the inner one. This would yield the
  4436. following code.
  4437. \begin{center}
  4438. \begin{minipage}{0.96\textwidth}
  4439. \begin{lstlisting}
  4440. (let ([x (read)])
  4441. (let ([y (read)])
  4442. (if (< x 1)
  4443. (if (eq? x 0)
  4444. (+ y 2)
  4445. (+ y 10))
  4446. (if (eq? x 2)
  4447. (+ y 2)
  4448. (+ y 10)))))
  4449. \end{lstlisting}
  4450. \end{minipage}
  4451. \end{center}
  4452. Unfortunately, this approach duplicates the two branches, and a
  4453. compiler must never duplicate code!
  4454. We need a way to perform the above transformation, but without
  4455. duplicating code. That is, we need a way for different parts of a
  4456. program to refer to the same piece of code, that is, to \emph{share}
  4457. code. At the level of x86 assembly this is straightforward because we
  4458. can label the code for each of the branches and insert jumps in all
  4459. the places that need to execute the branches. At the higher level of
  4460. our intermediate languages, we need to move away from abstract syntax
  4461. \emph{trees} and instead use \emph{graphs}. In particular, we use a
  4462. standard program representation called a \emph{control flow graph}
  4463. (CFG), due to Frances Elizabeth \citet{Allen:1970uq}.
  4464. \index{control-flow graph} Each vertex is a labeled sequence of code,
  4465. called a \emph{basic block}, and each edge represents a jump to
  4466. another block. The \key{Program} construct of $C_0$ and $C_1$ contains
  4467. a control flow graph represented as an alist mapping labels to basic
  4468. blocks. Each basic block is represented by the $\Tail$ non-terminal.
  4469. Figure~\ref{fig:explicate-control-s1-38} shows the output of the
  4470. \code{remove-complex-opera*} pass and then the
  4471. \code{explicate-control} pass on the example program. We walk through
  4472. the output program and then discuss the algorithm.
  4473. %
  4474. Following the order of evaluation in the output of
  4475. \code{remove-complex-opera*}, we first have two calls to \code{(read)}
  4476. and then the less-than-comparison to \code{1} in the predicate of the
  4477. inner \key{if}. In the output of \code{explicate-control}, in the
  4478. block labeled \code{start}, this becomes two assignment statements
  4479. followed by a conditional \key{goto} to label \code{block40} or
  4480. \code{block41}. The blocks associated with those labels contain the
  4481. translations of the code \code{(eq? x 0)} and \code{(eq? x 2)},
  4482. respectively. Regarding the block labeled with \code{block40}, we
  4483. start with the comparison to \code{0} and then have a conditional
  4484. goto, either to label \code{block38} or label \code{block39}, which
  4485. are the two branches of the outer \key{if}, i.e., \code{(+ y 2)} and
  4486. \code{(+ y 10)}. The story for the block labeled \code{block41} is
  4487. similar.
  4488. \begin{figure}[tbp]
  4489. \begin{tabular}{lll}
  4490. \begin{minipage}{0.4\textwidth}
  4491. % s1_41.rkt
  4492. \begin{lstlisting}
  4493. (let ([x (read)])
  4494. (let ([y (read)])
  4495. (if (if (< x 1)
  4496. (eq? x 0)
  4497. (eq? x 2))
  4498. (+ y 2)
  4499. (+ y 10))))
  4500. \end{lstlisting}
  4501. \hspace{40pt}$\Downarrow$
  4502. \begin{lstlisting}
  4503. (let ([x (read)])
  4504. (let ([y (read)])
  4505. (if (if (< x 1)
  4506. (eq? x 0)
  4507. (eq? x 2))
  4508. (+ y 2)
  4509. (+ y 10))))
  4510. \end{lstlisting}
  4511. \end{minipage}
  4512. &
  4513. $\Rightarrow$
  4514. &
  4515. \begin{minipage}{0.55\textwidth}
  4516. \begin{lstlisting}
  4517. start:
  4518. x = (read);
  4519. y = (read);
  4520. if (< x 1)
  4521. goto block40;
  4522. else
  4523. goto block41;
  4524. block40:
  4525. if (eq? x 0)
  4526. goto block38;
  4527. else
  4528. goto block39;
  4529. block41:
  4530. if (eq? x 2)
  4531. goto block38;
  4532. else
  4533. goto block39;
  4534. block38:
  4535. return (+ y 2);
  4536. block39:
  4537. return (+ y 10);
  4538. \end{lstlisting}
  4539. \end{minipage}
  4540. \end{tabular}
  4541. \caption{Translation from $R_2$ to $C_1$
  4542. via the \code{explicate-control}.}
  4543. \label{fig:explicate-control-s1-38}
  4544. \end{figure}
  4545. %% The nice thing about the output of \code{explicate-control} is that
  4546. %% there are no unnecessary comparisons and every comparison is part of a
  4547. %% conditional jump.
  4548. %% The down-side of this output is that it includes
  4549. %% trivial blocks, such as the blocks labeled \code{block92} through
  4550. %% \code{block95}, that only jump to another block. We discuss a solution
  4551. %% to this problem in Section~\ref{sec:opt-jumps}.
  4552. Recall that in Section~\ref{sec:explicate-control-r1} we implement
  4553. \code{explicate-control} for $R_1$ using two mutually recursive
  4554. functions, \code{explicate-tail} and \code{explicate-assign}. The
  4555. former function translates expressions in tail position whereas the
  4556. later function translates expressions on the right-hand-side of a
  4557. \key{let}. With the addition of \key{if} expression in $R_2$ we have a
  4558. new kind of context to deal with: the predicate position of the
  4559. \key{if}. We need another function, \code{explicate-pred}, that takes
  4560. an $R_2$ expression and two blocks for the then-branch and
  4561. else-branch. The output of \code{explicate-pred} is a block.
  4562. %
  4563. %% Note that the three explicate functions need to construct a
  4564. %% control-flow graph, which we recommend they do via updates to a global
  4565. %% variable.
  4566. %
  4567. In the following paragraphs we discuss specific cases in the
  4568. \code{explicate-pred} function as well as the additions to the
  4569. \code{explicate-tail} and \code{explicate-assign} functions.
  4570. The function \code{explicate-pred} will need a case for every
  4571. expression that can have type \code{Boolean}. We detail a few cases
  4572. here and leave the rest for the reader. The input to this function is
  4573. an expression and two blocks, $B_1$ and $B_2$, for the two branches of
  4574. the enclosing \key{if}, though some care will be needed regarding how
  4575. we represent the blocks. Suppose the expression is the Boolean
  4576. \code{\#t}. Then we can perform a kind of partial evaluation
  4577. \index{partial evaluation} and translate it to the ``then'' branch
  4578. $B_1$. Likewise, we translate \code{\#f} to the ``else`` branch $B_2$.
  4579. \[
  4580. \key{\#t} \quad\Rightarrow\quad B_1,
  4581. \qquad\qquad\qquad
  4582. \key{\#f} \quad\Rightarrow\quad B_2
  4583. \]
  4584. These two cases demonstrate that we sometimes discard one of the
  4585. blocks that are input to \code{explicate-pred}. We will need to
  4586. arrange for the blocks that we actually use to appear in the resulting
  4587. control-flow graph, but not the discarded blocks.
  4588. The case for \key{if} in \code{explicate-pred} is particularly
  4589. illuminating as it deals with the challenges that we discussed above
  4590. regarding the example of the nested \key{if} expressions. The
  4591. ``then'' and ``else'' branches of the current \key{if} inherit their
  4592. context from the current one, that is, predicate context. So we
  4593. recursively apply \code{explicate-pred} to the ``then'' and ``else''
  4594. branches. For both of those recursive calls, we shall pass the blocks
  4595. $B_1$ and $B_2$. Thus, $B_1$ may get used twice, once inside each
  4596. recursive call, and likewise for $B_2$. As discussed above, to avoid
  4597. duplicating code, we need to add these blocks to the control-flow
  4598. graph so that we can instead refer to them by name and execute them
  4599. with a \key{goto}. However, as we saw in the cases above for \key{\#t}
  4600. and \key{\#f}, the blocks $B_1$ or $B_2$ may not get used at all and
  4601. we don't want to prematurely add them to the control-flow graph if
  4602. they end up being discarded.
  4603. The solution to this conundrum is to use \emph{lazy evaluation} to
  4604. delay adding the blocks to the control-flow graph until the points
  4605. where we know they will be used~\citep{Friedman:1976aa}.\index{lazy
  4606. evaluation} Racket provides support for lazy evaluation with the
  4607. \href{https://docs.racket-lang.org/reference/Delayed_Evaluation.html}{\code{racket/promise}}
  4608. package. The expression \key{(delay} $e_1 \ldots e_n$\key{)}
  4609. \index{delay} creates a \emph{promise}\index{promise} in which the
  4610. evaluation of the expressions is postponed. When \key{(force}
  4611. $p$\key{)}\index{force} is applied to a promise $p$ for the first
  4612. time, the expressions $e_1 \ldots e_n$ are evaluated and the result of
  4613. $e_n$ is cached in the promise and returned. If \code{force} is
  4614. applied again to the same promise, then the cached result is returned.
  4615. We use lazy evaluation for the input and output blocks of the
  4616. functions \code{explicate-pred} and \code{explicate-assign} and for
  4617. the output block of \code{explicate-tail}. So instead of taking and
  4618. returning blocks, they take and return promised blocks. Furthermore,
  4619. when we come to a situation in which we a block might be used more
  4620. than once, as in the case for \code{if} above, we transform the
  4621. promise into a new promise that will add the block to the control-flow
  4622. graph and return a \code{goto}. The following auxiliary function
  4623. accomplishes this task. It begins with \code{delay} to create a
  4624. promise. When forced, this promise will force the input block. If that
  4625. block is already a \code{goto} (because it was already added to the
  4626. control-flow graph), then we return that \code{goto}. Otherwise we add
  4627. the block to the control-flow graph with another auxiliary function
  4628. named \code{add-node} that returns the new label, and then return the
  4629. \code{goto}.
  4630. \begin{lstlisting}
  4631. (define (block->goto block)
  4632. (delay
  4633. (define b (force block))
  4634. (match b
  4635. [(Goto label) (Goto label)]
  4636. [else (Goto (add-node b))]
  4637. )))
  4638. \end{lstlisting}
  4639. Getting back to the case for \code{if} in \code{explicate-pred}, we
  4640. make the recursive calls to \code{explicate-pred} on the ``then'' and
  4641. ``else'' branches with the arguments \code{(block->goto} $B_1$\code{)}
  4642. and \code{(block->goto} $B_2$\code{)}. Let $B_3$ and $B_4$ be the
  4643. results from the two recursive calls. We complete the case for
  4644. \code{if} by recursively apply \code{explicate-pred} to the condition
  4645. of the \code{if} with the promised blocks $B_3$ and $B_4$ to obtain
  4646. the result $B_5$.
  4647. \[
  4648. (\key{if}\; \itm{cnd}\; \itm{thn}\; \itm{els})
  4649. \quad\Rightarrow\quad
  4650. B_5
  4651. \]
  4652. Next, consider the case for a less-than comparison in
  4653. \code{explicate-pred}. We translate it to an \code{if} statement,
  4654. whose two branches are required to be \code{goto}'s. So we apply
  4655. \code{block->goto} to $B_1$ and $B_2$ to obtain two promised goto's,
  4656. which we can \code{force} to obtain the two actual goto's $G_1$ and
  4657. $G_2$. The translation of the less-than comparison is as follows.
  4658. \[
  4659. (\key{<}~e_1~e_2) \quad\Rightarrow\quad
  4660. \begin{array}{l}
  4661. \key{if}~(\key{<}~e_1~e_2) \; G_1\\
  4662. \key{else} \; G_2
  4663. \end{array}
  4664. \]
  4665. The \code{explicate-tail} function needs to be updated to use lazy
  4666. evaluation and it needs an additional case for \key{if}. Each of the
  4667. cases that return an AST node need use \code{delay} to instead return
  4668. a promise of an AST node. Recall that \code{explicate-tail} has an
  4669. accumulator parameter that is a block, which now becomes a promise of
  4670. a block, which we refer to as $B_0$.
  4671. In the case for \code{if} in \code{explicate-tail}, the two branches
  4672. inherit the current context, so they are in tail position. Thus, the
  4673. recursive calls on the ``then'' and ``else'' branch should be calls to
  4674. \code{explicate-tail}.
  4675. %
  4676. We need to pass $B_0$ as the accumulator argument for both of these
  4677. recursive calls, but we need to be careful not to duplicate $B_0$.
  4678. Thus, we first apply \code{block->goto} to $B_0$ so that it gets added
  4679. to the control-flow graph and obtain a promised goto $G_0$.
  4680. %
  4681. Let $B_1$ be the result of \code{explicate-tail} on the ``then''
  4682. branch and $G_0$ and let $B_2$ be the result of \code{explicate-tail}
  4683. on the ``else'' branch and $G_0$. Let $B_3$ be the result of applying
  4684. \code{explicate-pred} to the condition of the \key{if}, $B_1$, and
  4685. $B_2$. Then the \key{if} as a whole translates to promise $B_3$.
  4686. \[
  4687. (\key{if}\; \itm{cnd}\; \itm{thn}\; \itm{els}) \quad\Rightarrow\quad B_3
  4688. \]
  4689. %% In the above discussion, we use the metavariables $B_1$, $B_2$, and
  4690. %% $B_3$ to refer to blocks for the purposes of our discussion, but they
  4691. %% should not be confused with the labels for the blocks that appear in
  4692. %% the generated code. We initially construct unlabeled blocks; we only
  4693. %% attach labels to blocks when we add them to the control-flow graph, as
  4694. %% we see in the next case.
  4695. Next consider the case for \key{if} in the \code{explicate-assign}
  4696. function. The context of the \key{if} is an assignment to some
  4697. variable $x$ and then the control continues to some promised block
  4698. $B_1$. The code that we generate for both the ``then'' and ``else''
  4699. branches needs to continue to $B_1$, so to avoid duplicating $B_1$ we
  4700. apply \code{block->goto} to it and obtain a promised goto $G_1$. The
  4701. branches of the \key{if} inherit the current context, so they are in
  4702. assignment positions. Let $B_2$ be the result of applying
  4703. \code{explicate-assign} to the ``then'' branch, variable $x$, and
  4704. $G_1$. Let $B_3$ be the result of applying \code{explicate-assign} to
  4705. the ``else'' branch, variable $x$, and $G_1$. Finally, let $B_4$ be
  4706. the result of applying \code{explicate-pred} to the predicate
  4707. $\itm{cnd}$ and the promises $B_2$ and $B_3$. The \key{if} as a whole
  4708. translates to the promise $B_4$.
  4709. \[
  4710. (\key{if}\; \itm{cnd}\; \itm{thn}\; \itm{els}) \quad\Rightarrow\quad B_4
  4711. \]
  4712. This completes the description of \code{explicate-control} for $R_2$.
  4713. The way in which the \code{shrink} pass transforms logical operations
  4714. such as \code{and} and \code{or} can impact the quality of code
  4715. generated by \code{explicate-control}. For example, consider the
  4716. following program.
  4717. % s1_21.rkt
  4718. \begin{lstlisting}
  4719. (if (and (eq? (read) 0) (eq? (read) 1))
  4720. 0
  4721. 42)
  4722. \end{lstlisting}
  4723. The \code{and} operation should transform into something that the
  4724. \code{explicate-pred} function can still analyze and descend through to
  4725. reach the underlying \code{eq?} conditions. Ideally, your
  4726. \code{explicate-control} pass should generate code similar to the
  4727. following for the above program.
  4728. \begin{center}
  4729. \begin{lstlisting}
  4730. start:
  4731. tmp1 = (read);
  4732. if (eq? tmp1 0)
  4733. goto block40;
  4734. else
  4735. goto block39;
  4736. block40:
  4737. tmp2 = (read);
  4738. if (eq? tmp2 1)
  4739. goto block38;
  4740. else
  4741. goto block39;
  4742. block38:
  4743. return 0;
  4744. block39:
  4745. return 42;
  4746. \end{lstlisting}
  4747. \end{center}
  4748. \begin{exercise}\normalfont
  4749. Implement the pass \code{explicate-control} by adding the cases for
  4750. \key{if} to the functions for tail and assignment contexts, and
  4751. implement \code{explicate-pred} for predicate contexts. Create test
  4752. cases that exercise all of the new cases in the code for this pass.
  4753. \end{exercise}
  4754. \section{Select Instructions}
  4755. \label{sec:select-r2}
  4756. \index{instruction selection}
  4757. Recall that the \code{select-instructions} pass lowers from our
  4758. $C$-like intermediate representation to the pseudo-x86 language, which
  4759. is suitable for conducting register allocation. The pass is
  4760. implemented using three auxiliary functions, one for each of the
  4761. non-terminals $\Atm$, $\Stmt$, and $\Tail$.
  4762. For $\Atm$, we have new cases for the Booleans. We take the usual
  4763. approach of encoding them as integers, with true as 1 and false as 0.
  4764. \[
  4765. \key{\#t} \Rightarrow \key{1}
  4766. \qquad
  4767. \key{\#f} \Rightarrow \key{0}
  4768. \]
  4769. For $\Stmt$, we discuss a couple cases. The \code{not} operation can
  4770. be implemented in terms of \code{xorq} as we discussed at the
  4771. beginning of this section. Given an assignment
  4772. $\itm{var}$ \key{=} \key{(not} $\Atm$\key{);},
  4773. if the left-hand side $\itm{var}$ is
  4774. the same as $\Atm$, then just the \code{xorq} suffices.
  4775. \[
  4776. \Var~\key{=}~ \key{(not}\; \Var\key{);}
  4777. \quad\Rightarrow\quad
  4778. \key{xorq}~\key{\$}1\key{,}~\Var
  4779. \]
  4780. Otherwise, a \key{movq} is needed to adapt to the update-in-place
  4781. semantics of x86. Let $\Arg$ be the result of translating $\Atm$ to
  4782. x86. Then we have
  4783. \[
  4784. \Var~\key{=}~ \key{(not}\; \Atm\key{);}
  4785. \quad\Rightarrow\quad
  4786. \begin{array}{l}
  4787. \key{movq}~\Arg\key{,}~\Var\\
  4788. \key{xorq}~\key{\$}1\key{,}~\Var
  4789. \end{array}
  4790. \]
  4791. Next consider the cases for \code{eq?} and less-than comparison.
  4792. Translating these operations to x86 is slightly involved due to the
  4793. unusual nature of the \key{cmpq} instruction discussed above. We
  4794. recommend translating an assignment from \code{eq?} into the following
  4795. sequence of three instructions. \\
  4796. \begin{tabular}{lll}
  4797. \begin{minipage}{0.4\textwidth}
  4798. \begin{lstlisting}
  4799. |$\Var$| = (eq? |$\Atm_1$| |$\Atm_2$|);
  4800. \end{lstlisting}
  4801. \end{minipage}
  4802. &
  4803. $\Rightarrow$
  4804. &
  4805. \begin{minipage}{0.4\textwidth}
  4806. \begin{lstlisting}
  4807. cmpq |$\Arg_2$|, |$\Arg_1$|
  4808. sete %al
  4809. movzbq %al, |$\Var$|
  4810. \end{lstlisting}
  4811. \end{minipage}
  4812. \end{tabular} \\
  4813. Regarding the $\Tail$ non-terminal, we have two new cases: \key{goto}
  4814. and conditional \key{goto}. Both are straightforward to handle. A
  4815. \key{goto} becomes a jump instruction.
  4816. \[
  4817. \key{goto}\; \ell\key{;} \quad \Rightarrow \quad \key{jmp}\;\ell
  4818. \]
  4819. A conditional \key{goto} becomes a compare instruction followed
  4820. by a conditional jump (for ``then'') and the fall-through is
  4821. to a regular jump (for ``else'').\\
  4822. \begin{tabular}{lll}
  4823. \begin{minipage}{0.4\textwidth}
  4824. \begin{lstlisting}
  4825. if (eq? |$\Atm_1$| |$\Atm_2$|)
  4826. goto |$\ell_1$|;
  4827. else
  4828. goto |$\ell_2$|;
  4829. \end{lstlisting}
  4830. \end{minipage}
  4831. &
  4832. $\Rightarrow$
  4833. &
  4834. \begin{minipage}{0.4\textwidth}
  4835. \begin{lstlisting}
  4836. cmpq |$\Arg_2$|, |$\Arg_1$|
  4837. je |$\ell_1$|
  4838. jmp |$\ell_2$|
  4839. \end{lstlisting}
  4840. \end{minipage}
  4841. \end{tabular} \\
  4842. \begin{exercise}\normalfont
  4843. Expand your \code{select-instructions} pass to handle the new features
  4844. of the $R_2$ language. Test the pass on all the examples you have
  4845. created and make sure that you have some test programs that use the
  4846. \code{eq?} and \code{<} operators, creating some if necessary. Test
  4847. the output using the \code{interp-x86} interpreter
  4848. (Appendix~\ref{appendix:interp}).
  4849. \end{exercise}
  4850. \section{Register Allocation}
  4851. \label{sec:register-allocation-r2}
  4852. \index{register allocation}
  4853. The changes required for $R_2$ affect liveness analysis, building the
  4854. interference graph, and assigning homes, but the graph coloring
  4855. algorithm itself does not change.
  4856. \subsection{Liveness Analysis}
  4857. \label{sec:liveness-analysis-r2}
  4858. \index{liveness analysis}
  4859. Recall that for $R_1$ we implemented liveness analysis for a single
  4860. basic block (Section~\ref{sec:liveness-analysis-r1}). With the
  4861. addition of \key{if} expressions to $R_2$, \code{explicate-control}
  4862. produces many basic blocks arranged in a control-flow graph. We
  4863. recommend that you create a new auxiliary function named
  4864. \code{uncover-live-CFG} that applies liveness analysis to a
  4865. control-flow graph.
  4866. The first question we need to consider is: what order should we
  4867. process the basic blocks in the control-flow graph? To perform
  4868. liveness analysis on a basic block, we need to know its live-after
  4869. set. If a basic block has no successor blocks (i.e. no out-edges in
  4870. the control flow graph), then it has an empty live-after set and we
  4871. can immediately apply liveness analysis to it. If a basic block has
  4872. some successors, then we need to complete liveness analysis on those
  4873. blocks first. Thankfully, the control flow graph does not contain any
  4874. cycles because $R_2$ does not include loops. (In
  4875. Chapter~\ref{ch:loop} we add loops and study how to handle cycles in
  4876. the control-flow graph.)
  4877. %
  4878. Returning to the question of what order should we process the basic
  4879. blocks, the answer is reverse topological order. We recommend using
  4880. the \code{tsort} (topological sort) and \code{transpose} functions of
  4881. the Racket \code{graph} package to obtain this ordering.
  4882. \index{topological order}
  4883. \index{topological sort}
  4884. The next question is how to analyze the jump instructions. In
  4885. Section~\ref{sec:liveness-analysis-r1} we recommended that you
  4886. maintain an alist named \code{label->live} that maps each label to the
  4887. set of live locations at the beginning of the associated block. Now
  4888. that we have many basic blocks, the alist needs to be extended as we
  4889. process the blocks. In particular, after performing liveness analysis
  4890. on a block, we can take the live-before set for its first instruction
  4891. and associate that with the block's label in the alist.
  4892. %
  4893. As discussed in Section~\ref{sec:liveness-analysis-r1}, the
  4894. live-before set for a $\JMP{\itm{label}}$ instruction is given by the
  4895. mapping for $\itm{label}$ in \code{label->live}.
  4896. Now for $x86_1$ we also have the conditional jump
  4897. $\JMPIF{\itm{cc}}{\itm{label}}$ to deal with. This one is
  4898. particularly interesting because during compilation we do not know, in
  4899. general, which way a conditional jump will go, so we do not know
  4900. whether to use the live-before set for the following instruction or
  4901. the live-before set for $\itm{label}$. The solution to this challenge
  4902. is based on the observation that there is no harm to the correctness
  4903. of the compiler if we classify more locations as live than the ones
  4904. that are truly live during a particular execution of the
  4905. instruction. Thus, we can take the union of the live-before sets from
  4906. the following instruction and from the mapping fro $\itm{label}$ in
  4907. \code{label->live}.
  4908. The helper functions for computing the variables in an instruction's
  4909. argument and for computing the variables read-from ($R$) or written-to
  4910. ($W$) by an instruction need to be updated to handle the new kinds of
  4911. arguments and instructions in x86$_1$.
  4912. \subsection{Build Interference}
  4913. \label{sec:build-interference-r2}
  4914. Many of the new instructions in x86$_1$ can be handled in the same way
  4915. as the instructions in x86$_0$. Thus, if your code was already quite
  4916. general, it will not need to be changed to handle the new
  4917. instructions. If you code is not general enough, I recommend that you
  4918. change your code to be more general. For example, you can factor out
  4919. the computing of the the read and write sets for each kind of
  4920. instruction into two auxiliary functions.
  4921. Note that the \key{movzbq} instruction requires some special care,
  4922. just like the \key{movq} instruction. See rule number 3 in
  4923. Section~\ref{sec:build-interference}.
  4924. %% \subsection{Assign Homes}
  4925. %% \label{sec:assign-homes-r2}
  4926. %% The \code{assign-homes} function (Section~\ref{sec:assign-r1}) needs
  4927. %% to be updated to handle the \key{if} statement, simply by recursively
  4928. %% processing the child nodes. Hopefully your code already handles the
  4929. %% other new instructions, but if not, you can generalize your code.
  4930. \begin{exercise}\normalfont
  4931. Update the \code{register-allocation} pass so that it works for $R_2$
  4932. and test your compiler using your previously created programs on the
  4933. \code{interp-x86} interpreter (Appendix~\ref{appendix:interp}).
  4934. \end{exercise}
  4935. \section{Patch Instructions}
  4936. The second argument of the \key{cmpq} instruction must not be an
  4937. immediate value (such as an integer). So if you are comparing two
  4938. immediates, we recommend inserting a \key{movq} instruction to put the
  4939. second argument in \key{rax}. Also, recall that instructions may have
  4940. at most one memory reference.
  4941. %
  4942. The second argument of the \key{movzbq} must be a register.
  4943. %
  4944. There are no special restrictions on the x86 instructions \key{JmpIf}
  4945. and \key{Jmp}.
  4946. \begin{exercise}\normalfont
  4947. Update \code{patch-instructions} to handle the new x86 instructions.
  4948. Test your compiler using your previously created programs on the
  4949. \code{interp-x86} interpreter (Appendix~\ref{appendix:interp}).
  4950. \end{exercise}
  4951. \begin{figure}[tbp]
  4952. \begin{tikzpicture}[baseline=(current bounding box.center)]
  4953. \node (R2) at (0,2) {\large $R_2$};
  4954. \node (R2-2) at (3,2) {\large $R_2$};
  4955. \node (R2-3) at (6,2) {\large $R_2$};
  4956. \node (R2-4) at (9,2) {\large $R_2$};
  4957. \node (R2-5) at (12,2) {\large $R_2$};
  4958. \node (C1-1) at (3,0) {\large $C_1$};
  4959. \node (x86-2) at (3,-2) {\large $\text{x86}^{*}_1$};
  4960. \node (x86-3) at (6,-2) {\large $\text{x86}^{*}_1$};
  4961. \node (x86-4) at (9,-2) {\large $\text{x86}^{*}_1$};
  4962. \node (x86-5) at (9,-4) {\large $\text{x86}^{\dagger}_1$};
  4963. \node (x86-2-1) at (3,-4) {\large $\text{x86}^{*}_1$};
  4964. \node (x86-2-2) at (6,-4) {\large $\text{x86}^{*}_1$};
  4965. \path[->,bend left=15] (R2) edge [above] node {\ttfamily\footnotesize type-check} (R2-2);
  4966. \path[->,bend left=15] (R2-2) edge [above] node {\ttfamily\footnotesize shrink} (R2-3);
  4967. \path[->,bend left=15] (R2-3) edge [above] node {\ttfamily\footnotesize uniquify} (R2-4);
  4968. \path[->,bend left=15] (R2-4) edge [above] node {\ttfamily\footnotesize remove-complex.} (R2-5);
  4969. \path[->,bend left=15] (R2-5) edge [left] node {\ttfamily\footnotesize explicate-control} (C1-1);
  4970. \path[->,bend right=15] (C1-1) edge [left] node {\ttfamily\footnotesize select-instructions} (x86-2);
  4971. \path[->,bend left=15] (x86-2) edge [right] node {\ttfamily\footnotesize uncover-live} (x86-2-1);
  4972. \path[->,bend right=15] (x86-2-1) edge [below] node {\ttfamily\footnotesize build-inter.} (x86-2-2);
  4973. \path[->,bend right=15] (x86-2-2) edge [right] node {\ttfamily\footnotesize allocate-reg.} (x86-3);
  4974. \path[->,bend left=15] (x86-3) edge [above] node {\ttfamily\footnotesize patch-instr.} (x86-4);
  4975. \path[->,bend left=15] (x86-4) edge [right] node {\ttfamily\footnotesize print-x86 } (x86-5);
  4976. \end{tikzpicture}
  4977. \caption{Diagram of the passes for $R_2$, a language with conditionals.}
  4978. \label{fig:R2-passes}
  4979. \end{figure}
  4980. Figure~\ref{fig:R2-passes} lists all the passes needed for the
  4981. compilation of $R_2$.
  4982. \section{An Example Translation}
  4983. Figure~\ref{fig:if-example-x86} shows a simple example program in
  4984. $R_2$ translated to x86, showing the results of
  4985. \code{explicate-control}, \code{select-instructions}, and the final
  4986. x86 assembly code.
  4987. \begin{figure}[tbp]
  4988. \begin{tabular}{lll}
  4989. \begin{minipage}{0.5\textwidth}
  4990. % s1_20.rkt
  4991. \begin{lstlisting}
  4992. (if (eq? (read) 1) 42 0)
  4993. \end{lstlisting}
  4994. $\Downarrow$
  4995. \begin{lstlisting}
  4996. start:
  4997. tmp7951 = (read);
  4998. if (eq? tmp7951 1) then
  4999. goto block7952;
  5000. else
  5001. goto block7953;
  5002. block7952:
  5003. return 42;
  5004. block7953:
  5005. return 0;
  5006. \end{lstlisting}
  5007. $\Downarrow$
  5008. \begin{lstlisting}
  5009. start:
  5010. callq read_int
  5011. movq %rax, tmp7951
  5012. cmpq $1, tmp7951
  5013. je block7952
  5014. jmp block7953
  5015. block7953:
  5016. movq $0, %rax
  5017. jmp conclusion
  5018. block7952:
  5019. movq $42, %rax
  5020. jmp conclusion
  5021. \end{lstlisting}
  5022. \end{minipage}
  5023. &
  5024. $\Rightarrow\qquad$
  5025. \begin{minipage}{0.4\textwidth}
  5026. \begin{lstlisting}
  5027. start:
  5028. callq read_int
  5029. movq %rax, %rcx
  5030. cmpq $1, %rcx
  5031. je block7952
  5032. jmp block7953
  5033. block7953:
  5034. movq $0, %rax
  5035. jmp conclusion
  5036. block7952:
  5037. movq $42, %rax
  5038. jmp conclusion
  5039. .globl main
  5040. main:
  5041. pushq %rbp
  5042. movq %rsp, %rbp
  5043. pushq %r13
  5044. pushq %r12
  5045. pushq %rbx
  5046. pushq %r14
  5047. subq $0, %rsp
  5048. jmp start
  5049. conclusion:
  5050. addq $0, %rsp
  5051. popq %r14
  5052. popq %rbx
  5053. popq %r12
  5054. popq %r13
  5055. popq %rbp
  5056. retq
  5057. \end{lstlisting}
  5058. \end{minipage}
  5059. \end{tabular}
  5060. \caption{Example compilation of an \key{if} expression to x86.}
  5061. \label{fig:if-example-x86}
  5062. \end{figure}
  5063. \section{Challenge: Remove Jumps}
  5064. \label{sec:opt-jumps}
  5065. %% Recall that in the example output of \code{explicate-control} in
  5066. %% Figure~\ref{fig:explicate-control-s1-38}, \code{block57} through
  5067. %% \code{block60} are trivial blocks, they do nothing but jump to another
  5068. %% block. The first goal of this challenge assignment is to remove those
  5069. %% blocks. Figure~\ref{fig:optimize-jumps} repeats the result of
  5070. %% \code{explicate-control} on the left and shows the result of bypassing
  5071. %% the trivial blocks on the right. Let us focus on \code{block61}. The
  5072. %% \code{then} branch jumps to \code{block57}, which in turn jumps to
  5073. %% \code{block55}. The optimized code on the right of
  5074. %% Figure~\ref{fig:optimize-jumps} bypasses \code{block57}, with the
  5075. %% \code{then} branch jumping directly to \code{block55}. The story is
  5076. %% similar for the \code{else} branch, as well as for the two branches in
  5077. %% \code{block62}. After the jumps in \code{block61} and \code{block62}
  5078. %% have been optimized in this way, there are no longer any jumps to
  5079. %% blocks \code{block57} through \code{block60}, so they can be removed.
  5080. %% \begin{figure}[tbp]
  5081. %% \begin{tabular}{lll}
  5082. %% \begin{minipage}{0.4\textwidth}
  5083. %% \begin{lstlisting}
  5084. %% block62:
  5085. %% tmp54 = (read);
  5086. %% if (eq? tmp54 2) then
  5087. %% goto block59;
  5088. %% else
  5089. %% goto block60;
  5090. %% block61:
  5091. %% tmp53 = (read);
  5092. %% if (eq? tmp53 0) then
  5093. %% goto block57;
  5094. %% else
  5095. %% goto block58;
  5096. %% block60:
  5097. %% goto block56;
  5098. %% block59:
  5099. %% goto block55;
  5100. %% block58:
  5101. %% goto block56;
  5102. %% block57:
  5103. %% goto block55;
  5104. %% block56:
  5105. %% return (+ 700 77);
  5106. %% block55:
  5107. %% return (+ 10 32);
  5108. %% start:
  5109. %% tmp52 = (read);
  5110. %% if (eq? tmp52 1) then
  5111. %% goto block61;
  5112. %% else
  5113. %% goto block62;
  5114. %% \end{lstlisting}
  5115. %% \end{minipage}
  5116. %% &
  5117. %% $\Rightarrow$
  5118. %% &
  5119. %% \begin{minipage}{0.55\textwidth}
  5120. %% \begin{lstlisting}
  5121. %% block62:
  5122. %% tmp54 = (read);
  5123. %% if (eq? tmp54 2) then
  5124. %% goto block55;
  5125. %% else
  5126. %% goto block56;
  5127. %% block61:
  5128. %% tmp53 = (read);
  5129. %% if (eq? tmp53 0) then
  5130. %% goto block55;
  5131. %% else
  5132. %% goto block56;
  5133. %% block56:
  5134. %% return (+ 700 77);
  5135. %% block55:
  5136. %% return (+ 10 32);
  5137. %% start:
  5138. %% tmp52 = (read);
  5139. %% if (eq? tmp52 1) then
  5140. %% goto block61;
  5141. %% else
  5142. %% goto block62;
  5143. %% \end{lstlisting}
  5144. %% \end{minipage}
  5145. %% \end{tabular}
  5146. %% \caption{Optimize jumps by removing trivial blocks.}
  5147. %% \label{fig:optimize-jumps}
  5148. %% \end{figure}
  5149. %% The name of this pass is \code{optimize-jumps}. We recommend
  5150. %% implementing this pass in two phases. The first phrase builds a hash
  5151. %% table that maps labels to possibly improved labels. The second phase
  5152. %% changes the target of each \code{goto} to use the improved label. If
  5153. %% the label is for a trivial block, then the hash table should map the
  5154. %% label to the first non-trivial block that can be reached from this
  5155. %% label by jumping through trivial blocks. If the label is for a
  5156. %% non-trivial block, then the hash table should map the label to itself;
  5157. %% we do not want to change jumps to non-trivial blocks.
  5158. %% The first phase can be accomplished by constructing an empty hash
  5159. %% table, call it \code{short-cut}, and then iterating over the control
  5160. %% flow graph. Each time you encouter a block that is just a \code{goto},
  5161. %% then update the hash table, mapping the block's source to the target
  5162. %% of the \code{goto}. Also, the hash table may already have mapped some
  5163. %% labels to the block's source, to you must iterate through the hash
  5164. %% table and update all of those so that they instead map to the target
  5165. %% of the \code{goto}.
  5166. %% For the second phase, we recommend iterating through the $\Tail$ of
  5167. %% each block in the program, updating the target of every \code{goto}
  5168. %% according to the mapping in \code{short-cut}.
  5169. %% \begin{exercise}\normalfont
  5170. %% Implement the \code{optimize-jumps} pass as a transformation from
  5171. %% $C_1$ to $C_1$, coming after the \code{explicate-control} pass.
  5172. %% Check that \code{optimize-jumps} removes trivial blocks in a few
  5173. %% example programs. Then check that your compiler still passes all of
  5174. %% your tests.
  5175. %% \end{exercise}
  5176. There is an opportunity for optimizing jumps that is apparent in the
  5177. example of Figure~\ref{fig:if-example-x86}. The \code{start} block end
  5178. with a jump to \code{block7953} and there are no other jumps to
  5179. \code{block7953} in the rest of the program. In this situation we can
  5180. avoid the runtime overhead of this jump by merging \code{block7953}
  5181. into the preceding block, in this case the \code{start} block.
  5182. Figure~\ref{fig:remove-jumps} shows the output of
  5183. \code{select-instructions} on the left and the result of this
  5184. optimization on the right.
  5185. \begin{figure}[tbp]
  5186. \begin{tabular}{lll}
  5187. \begin{minipage}{0.5\textwidth}
  5188. % s1_20.rkt
  5189. \begin{lstlisting}
  5190. start:
  5191. callq read_int
  5192. movq %rax, tmp7951
  5193. cmpq $1, tmp7951
  5194. je block7952
  5195. jmp block7953
  5196. block7953:
  5197. movq $0, %rax
  5198. jmp conclusion
  5199. block7952:
  5200. movq $42, %rax
  5201. jmp conclusion
  5202. \end{lstlisting}
  5203. \end{minipage}
  5204. &
  5205. $\Rightarrow\qquad$
  5206. \begin{minipage}{0.4\textwidth}
  5207. \begin{lstlisting}
  5208. start:
  5209. callq read_int
  5210. movq %rax, tmp7951
  5211. cmpq $1, tmp7951
  5212. je block7952
  5213. movq $0, %rax
  5214. jmp conclusion
  5215. block7952:
  5216. movq $42, %rax
  5217. jmp conclusion
  5218. \end{lstlisting}
  5219. \end{minipage}
  5220. \end{tabular}
  5221. \caption{Merging basic blocks by removing unnecessary jumps.}
  5222. \label{fig:remove-jumps}
  5223. \end{figure}
  5224. \begin{exercise}\normalfont
  5225. Implement a pass named \code{remove-jumps} that merges basic blocks
  5226. into their preceding basic block, when there is only one preceding
  5227. block. The pass should translate from pseudo $x86_1$ to pseudo
  5228. $x86_1$ and it should come immediately after
  5229. \code{select-instructions}. Check that \code{remove-jumps}
  5230. accomplishes the goal of merging basic blocks on several test
  5231. programs and check that your compiler passes all of your tests.
  5232. \end{exercise}
  5233. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  5234. \chapter{Tuples and Garbage Collection}
  5235. \label{ch:tuples}
  5236. \index{tuple}
  5237. \index{vector}
  5238. \margincomment{\scriptsize To do: challenge assignments: mark-and-sweep,
  5239. add simple structures. \\ --Jeremy}
  5240. \margincomment{\scriptsize To do: look through Andre's code comments for extra
  5241. things to discuss in this chapter. \\ --Jeremy}
  5242. \margincomment{\scriptsize To do: Flesh out this chapter, e.g., make sure
  5243. all the IR grammars are spelled out! \\ --Jeremy}
  5244. \margincomment{\scriptsize Introduce has-type, but after flatten, remove it,
  5245. but keep type annotations on vector creation and local variables, function
  5246. parameters, etc. \\ --Jeremy}
  5247. \margincomment{\scriptsize Be more explicit about how to deal with
  5248. the root stack. \\ --Jeremy}
  5249. In this chapter we study the implementation of mutable tuples (called
  5250. ``vectors'' in Racket). This language feature is the first to use the
  5251. computer's \emph{heap}\index{heap} because the lifetime of a Racket tuple is
  5252. indefinite, that is, a tuple lives forever from the programmer's
  5253. viewpoint. Of course, from an implementer's viewpoint, it is important
  5254. to reclaim the space associated with a tuple when it is no longer
  5255. needed, which is why we also study \emph{garbage collection}
  5256. \emph{garbage collection}
  5257. techniques in this chapter.
  5258. Section~\ref{sec:r3} introduces the $R_3$ language including its
  5259. interpreter and type checker. The $R_3$ language extends the $R_2$
  5260. language of Chapter~\ref{ch:bool-types} with vectors and Racket's
  5261. \code{void} value. The reason for including the later is that the
  5262. \code{vector-set!} operation returns a value of type
  5263. \code{Void}\footnote{Racket's \code{Void} type corresponds to what is
  5264. called the \code{Unit} type in the programming languages
  5265. literature. Racket's \code{Void} type is inhabited by a single value
  5266. \code{void} which corresponds to \code{unit} or \code{()} in the
  5267. literature~\citep{Pierce:2002hj}.}.
  5268. Section~\ref{sec:GC} describes a garbage collection algorithm based on
  5269. copying live objects back and forth between two halves of the
  5270. heap. The garbage collector requires coordination with the compiler so
  5271. that it can see all of the \emph{root} pointers, that is, pointers in
  5272. registers or on the procedure call stack.
  5273. Sections~\ref{sec:expose-allocation} through \ref{sec:print-x86-gc}
  5274. discuss all the necessary changes and additions to the compiler
  5275. passes, including a new compiler pass named \code{expose-allocation}.
  5276. \section{The $R_3$ Language}
  5277. \label{sec:r3}
  5278. Figure~\ref{fig:r3-concrete-syntax} defines the concrete syntax for
  5279. $R_3$ and Figure~\ref{fig:r3-syntax} defines the abstract syntax. The
  5280. $R_3$ language includes three new forms: \code{vector} for creating a
  5281. tuple, \code{vector-ref} for reading an element of a tuple, and
  5282. \code{vector-set!} for writing to an element of a tuple. The program
  5283. in Figure~\ref{fig:vector-eg} shows the usage of tuples in Racket. We
  5284. create a 3-tuple \code{t} and a 1-tuple that is stored at index $2$ of
  5285. the 3-tuple, demonstrating that tuples are first-class values. The
  5286. element at index $1$ of \code{t} is \code{\#t}, so the ``then'' branch
  5287. of the \key{if} is taken. The element at index $0$ of \code{t} is
  5288. \code{40}, to which we add \code{2}, the element at index $0$ of the
  5289. 1-tuple. So the result of the program is \code{42}.
  5290. \begin{figure}[tbp]
  5291. \centering
  5292. \fbox{
  5293. \begin{minipage}{0.96\textwidth}
  5294. \[
  5295. \begin{array}{lcl}
  5296. \Type &::=& \gray{\key{Integer} \mid \key{Boolean}}
  5297. \mid \LP\key{Vector}\;\Type\ldots\RP \mid \key{Void}\\
  5298. \Exp &::=& \gray{ \Int \mid \CREAD{} \mid \CNEG{\Exp} \mid \CADD{\Exp}{\Exp} \mid \CSUB{\Exp}{\Exp} } \\
  5299. &\mid& \gray{ \Var \mid \CLET{\Var}{\Exp}{\Exp} }\\
  5300. &\mid& \gray{ \key{\#t} \mid \key{\#f}
  5301. \mid \LP\key{and}\;\Exp\;\Exp\RP
  5302. \mid \LP\key{or}\;\Exp\;\Exp\RP
  5303. \mid \LP\key{not}\;\Exp\RP } \\
  5304. &\mid& \gray{ \LP\itm{cmp}\;\Exp\;\Exp\RP
  5305. \mid \CIF{\Exp}{\Exp}{\Exp} } \\
  5306. &\mid& \LP\key{vector}\;\Exp\ldots\RP
  5307. \mid \LP\key{vector-length}\;\Exp\RP \\
  5308. &\mid& \LP\key{vector-ref}\;\Exp\;\Int\RP
  5309. \mid \LP\key{vector-set!}\;\Exp\;\Int\;\Exp\RP \\
  5310. &\mid& \LP\key{void}\RP \mid \LP\key{has-type}~\Exp~\Type\RP\\
  5311. R_3 &::=& \Exp
  5312. \end{array}
  5313. \]
  5314. \end{minipage}
  5315. }
  5316. \caption{The concrete syntax of $R_3$, extending $R_2$
  5317. (Figure~\ref{fig:r2-concrete-syntax}).}
  5318. \label{fig:r3-concrete-syntax}
  5319. \end{figure}
  5320. \begin{figure}[tbp]
  5321. \begin{lstlisting}
  5322. (let ([t (vector 40 #t (vector 2))])
  5323. (if (vector-ref t 1)
  5324. (+ (vector-ref t 0)
  5325. (vector-ref (vector-ref t 2) 0))
  5326. 44))
  5327. \end{lstlisting}
  5328. \caption{Example program that creates tuples and reads from them.}
  5329. \label{fig:vector-eg}
  5330. \end{figure}
  5331. \begin{figure}[tp]
  5332. \centering
  5333. \fbox{
  5334. \begin{minipage}{0.96\textwidth}
  5335. \[
  5336. \begin{array}{lcl}
  5337. \itm{op} &::=& \ldots \mid \code{vector} \mid \code{vector-length} \\
  5338. \Exp &::=& \gray{ \INT{\Int} \mid \VAR{\Var} \mid \LET{\Var}{\Exp}{\Exp} } \\
  5339. &\mid& \gray{ \PRIM{\itm{op}}{\Exp\ldots}
  5340. \mid \BOOL{\itm{bool}}
  5341. \mid \IF{\Exp}{\Exp}{\Exp} } \\
  5342. &\mid& \VECREF{\Exp}{\INT{\Int}}\\
  5343. &\mid& \VECSET{\Exp}{\INT{\Int}}{\Exp} \\
  5344. &\mid& \VOID{} \mid \LP\key{HasType}~\Exp~\Type \RP \\
  5345. R_3 &::=& \PROGRAM{\key{'()}}{\Exp}
  5346. \end{array}
  5347. \]
  5348. \end{minipage}
  5349. }
  5350. \caption{The abstract syntax of $R_3$.}
  5351. \label{fig:r3-syntax}
  5352. \end{figure}
  5353. \index{allocate}
  5354. \index{heap allocate}
  5355. Tuples are our first encounter with heap-allocated data, which raises
  5356. several interesting issues. First, variable binding performs a
  5357. shallow-copy when dealing with tuples, which means that different
  5358. variables can refer to the same tuple, that is, different variables
  5359. can be \emph{aliases} for the same entity. Consider the following
  5360. example in which both \code{t1} and \code{t2} refer to the same tuple.
  5361. Thus, the mutation through \code{t2} is visible when referencing the
  5362. tuple from \code{t1}, so the result of this program is \code{42}.
  5363. \index{alias}\index{mutation}
  5364. \begin{center}
  5365. \begin{minipage}{0.96\textwidth}
  5366. \begin{lstlisting}
  5367. (let ([t1 (vector 3 7)])
  5368. (let ([t2 t1])
  5369. (let ([_ (vector-set! t2 0 42)])
  5370. (vector-ref t1 0))))
  5371. \end{lstlisting}
  5372. \end{minipage}
  5373. \end{center}
  5374. The next issue concerns the lifetime of tuples. Of course, they are
  5375. created by the \code{vector} form, but when does their lifetime end?
  5376. Notice that $R_3$ does not include an operation for deleting
  5377. tuples. Furthermore, the lifetime of a tuple is not tied to any notion
  5378. of static scoping. For example, the following program returns
  5379. \code{42} even though the variable \code{w} goes out of scope prior to
  5380. the \code{vector-ref} that reads from the vector it was bound to.
  5381. \begin{center}
  5382. \begin{minipage}{0.96\textwidth}
  5383. \begin{lstlisting}
  5384. (let ([v (vector (vector 44))])
  5385. (let ([x (let ([w (vector 42)])
  5386. (let ([_ (vector-set! v 0 w)])
  5387. 0))])
  5388. (+ x (vector-ref (vector-ref v 0) 0))))
  5389. \end{lstlisting}
  5390. \end{minipage}
  5391. \end{center}
  5392. From the perspective of programmer-observable behavior, tuples live
  5393. forever. Of course, if they really lived forever, then many programs
  5394. would run out of memory.\footnote{The $R_3$ language does not have
  5395. looping or recursive functions, so it is nigh impossible to write a
  5396. program in $R_3$ that will run out of memory. However, we add
  5397. recursive functions in the next Chapter!} A Racket implementation
  5398. must therefore perform automatic garbage collection.
  5399. Figure~\ref{fig:interp-R3} shows the definitional interpreter for the
  5400. $R_3$ language. We define the \code{vector}, \code{vector-length},
  5401. \code{vector-ref}, and \code{vector-set!} operations for $R_3$ in
  5402. terms of the corresponding operations in Racket. One subtle point is
  5403. that the \code{vector-set!} operation returns the \code{\#<void>}
  5404. value. The \code{\#<void>} value can be passed around just like other
  5405. values inside an $R_3$ program and a \code{\#<void>} value can be
  5406. compared for equality with another \code{\#<void>} value. However,
  5407. there are no other operations specific to the the \code{\#<void>}
  5408. value in $R_3$. In contrast, Racket defines the \code{void?} predicate
  5409. that returns \code{\#t} when applied to \code{\#<void>} and \code{\#f}
  5410. otherwise.
  5411. \begin{figure}[tbp]
  5412. \begin{lstlisting}
  5413. (define interp-R3-class
  5414. (class interp-R2-class
  5415. (super-new)
  5416. (define/override (interp-op op)
  5417. (match op
  5418. ['eq? (lambda (v1 v2)
  5419. (cond [(or (and (fixnum? v1) (fixnum? v2))
  5420. (and (boolean? v1) (boolean? v2))
  5421. (and (vector? v1) (vector? v2))
  5422. (and (void? v1) (void? v2)))
  5423. (eq? v1 v2)]))]
  5424. ['vector vector]
  5425. ['vector-length vector-length]
  5426. ['vector-ref vector-ref]
  5427. ['vector-set! vector-set!]
  5428. [else (super interp-op op)]
  5429. ))
  5430. (define/override ((interp-exp env) e)
  5431. (define recur (interp-exp env))
  5432. (match e
  5433. [(HasType e t) (recur e)]
  5434. [(Void) (void)]
  5435. [else ((super interp-exp env) e)]
  5436. ))
  5437. ))
  5438. (define (interp-R3 p)
  5439. (send (new interp-R3-class) interp-program p))
  5440. \end{lstlisting}
  5441. \caption{Interpreter for the $R_3$ language.}
  5442. \label{fig:interp-R3}
  5443. \end{figure}
  5444. Figure~\ref{fig:type-check-R3} shows the type checker for $R_3$, which
  5445. deserves some explanation. When allocating a vector, we need to know
  5446. which elements of the vector are pointers (i.e. are also vectors). We
  5447. can obtain this information during type checking. The type checker in
  5448. Figure~\ref{fig:type-check-R3} not only computes the type of an
  5449. expression, it also wraps every \key{vector} creation with the form
  5450. $(\key{HasType}~e~T)$, where $T$ is the vector's type.
  5451. %
  5452. To create the s-expression for the \code{Vector} type in
  5453. Figure~\ref{fig:type-check-R3}, we use the
  5454. \href{https://docs.racket-lang.org/reference/quasiquote.html}{unquote-splicing
  5455. operator} \code{,@} to insert the list \code{t*} without its usual
  5456. start and end parentheses. \index{unquote-slicing}
  5457. \begin{figure}[tp]
  5458. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  5459. (define type-check-R3-class
  5460. (class type-check-R2-class
  5461. (super-new)
  5462. (inherit check-type-equal?)
  5463. (define/override (type-check-exp env)
  5464. (lambda (e)
  5465. (define recur (type-check-exp env))
  5466. (match e
  5467. [(Void) (values (Void) 'Void)]
  5468. [(Prim 'vector es)
  5469. (define-values (e* t*) (for/lists (e* t*) ([e es]) (recur e)))
  5470. (define t `(Vector ,@t*))
  5471. (values (HasType (Prim 'vector e*) t) t)]
  5472. [(Prim 'vector-ref (list e1 (Int i)))
  5473. (define-values (e1^ t) (recur e1))
  5474. (match t
  5475. [`(Vector ,ts ...)
  5476. (unless (and (0 . <= . i) (i . < . (length ts)))
  5477. (error 'type-check "index ~a out of bounds\nin ~v" i e))
  5478. (values (Prim 'vector-ref (list e1^ (Int i))) (list-ref ts i))]
  5479. [else (error 'type-check "expect Vector, not ~a\nin ~v" t e)])]
  5480. [(Prim 'vector-set! (list e1 (Int i) arg) )
  5481. (define-values (e-vec t-vec) (recur e1))
  5482. (define-values (e-arg^ t-arg) (recur arg))
  5483. (match t-vec
  5484. [`(Vector ,ts ...)
  5485. (unless (and (0 . <= . i) (i . < . (length ts)))
  5486. (error 'type-check "index ~a out of bounds\nin ~v" i e))
  5487. (check-type-equal? (list-ref ts i) t-arg e)
  5488. (values (Prim 'vector-set! (list e-vec (Int i) e-arg^)) 'Void)]
  5489. [else (error 'type-check "expect Vector, not ~a\nin ~v" t-vec e)])]
  5490. [(Prim 'vector-length (list e))
  5491. (define-values (e^ t) (recur e))
  5492. (match t
  5493. [`(Vector ,ts ...)
  5494. (values (Prim 'vector-length (list e^)) 'Integer)]
  5495. [else (error 'type-check "expect Vector, not ~a\nin ~v" t e)])]
  5496. [(Prim 'eq? (list arg1 arg2))
  5497. (define-values (e1 t1) (recur arg1))
  5498. (define-values (e2 t2) (recur arg2))
  5499. (match* (t1 t2)
  5500. [(`(Vector ,ts1 ...) `(Vector ,ts2 ...)) (void)]
  5501. [(other wise) (check-type-equal? t1 t2 e)])
  5502. (values (Prim 'eq? (list e1 e2)) 'Boolean)]
  5503. [(HasType (Prim 'vector es) t)
  5504. ((type-check-exp env) (Prim 'vector es))]
  5505. [(HasType e1 t)
  5506. (define-values (e1^ t^) (recur e1))
  5507. (check-type-equal? t t^ e)
  5508. (values (HasType e1^ t) t)]
  5509. [else ((super type-check-exp env) e)]
  5510. )))
  5511. ))
  5512. (define (type-check-R3 p)
  5513. (send (new type-check-R3-class) type-check-program p))
  5514. \end{lstlisting}
  5515. \caption{Type checker for the $R_3$ language.}
  5516. \label{fig:type-check-R3}
  5517. \end{figure}
  5518. \section{Garbage Collection}
  5519. \label{sec:GC}
  5520. Here we study a relatively simple algorithm for garbage collection
  5521. that is the basis of state-of-the-art garbage
  5522. collectors~\citep{Lieberman:1983aa,Ungar:1984aa,Jones:1996aa,Detlefs:2004aa,Dybvig:2006aa,Tene:2011kx}. In
  5523. particular, we describe a two-space copying
  5524. collector~\citep{Wilson:1992fk} that uses Cheney's algorithm to
  5525. perform the
  5526. copy~\citep{Cheney:1970aa}.
  5527. \index{copying collector}
  5528. \index{two-space copying collector}
  5529. Figure~\ref{fig:copying-collector} gives a
  5530. coarse-grained depiction of what happens in a two-space collector,
  5531. showing two time steps, prior to garbage collection (on the top) and
  5532. after garbage collection (on the bottom). In a two-space collector,
  5533. the heap is divided into two parts named the FromSpace and the
  5534. ToSpace. Initially, all allocations go to the FromSpace until there is
  5535. not enough room for the next allocation request. At that point, the
  5536. garbage collector goes to work to make more room.
  5537. \index{ToSpace}
  5538. \index{FromSpace}
  5539. The garbage collector must be careful not to reclaim tuples that will
  5540. be used by the program in the future. Of course, it is impossible in
  5541. general to predict what a program will do, but we can over approximate
  5542. the will-be-used tuples by preserving all tuples that could be
  5543. accessed by \emph{any} program given the current computer state. A
  5544. program could access any tuple whose address is in a register or on
  5545. the procedure call stack. These addresses are called the \emph{root
  5546. set}\index{root set}. In addition, a program could access any tuple that is
  5547. transitively reachable from the root set. Thus, it is safe for the
  5548. garbage collector to reclaim the tuples that are not reachable in this
  5549. way.
  5550. So the goal of the garbage collector is twofold:
  5551. \begin{enumerate}
  5552. \item preserve all tuple that are reachable from the root set via a
  5553. path of pointers, that is, the \emph{live} tuples, and
  5554. \item reclaim the memory of everything else, that is, the
  5555. \emph{garbage}.
  5556. \end{enumerate}
  5557. A copying collector accomplishes this by copying all of the live
  5558. objects from the FromSpace into the ToSpace and then performs a slight
  5559. of hand, treating the ToSpace as the new FromSpace and the old
  5560. FromSpace as the new ToSpace. In the example of
  5561. Figure~\ref{fig:copying-collector}, there are three pointers in the
  5562. root set, one in a register and two on the stack. All of the live
  5563. objects have been copied to the ToSpace (the right-hand side of
  5564. Figure~\ref{fig:copying-collector}) in a way that preserves the
  5565. pointer relationships. For example, the pointer in the register still
  5566. points to a 2-tuple whose first element is a 3-tuple and whose second
  5567. element is a 2-tuple. There are four tuples that are not reachable
  5568. from the root set and therefore do not get copied into the ToSpace.
  5569. The exact situation in Figure~\ref{fig:copying-collector} cannot be
  5570. created by a well-typed program in $R_3$ because it contains a
  5571. cycle. However, creating cycles will be possible once we get to $R_6$.
  5572. We design the garbage collector to deal with cycles to begin with so
  5573. we will not need to revisit this issue.
  5574. \begin{figure}[tbp]
  5575. \centering
  5576. \includegraphics[width=\textwidth]{figs/copy-collect-1} \\[5ex]
  5577. \includegraphics[width=\textwidth]{figs/copy-collect-2}
  5578. \caption{A copying collector in action.}
  5579. \label{fig:copying-collector}
  5580. \end{figure}
  5581. There are many alternatives to copying collectors (and their bigger
  5582. siblings, the generational collectors) when its comes to garbage
  5583. collection, such as mark-and-sweep~\citep{McCarthy:1960dz} and
  5584. reference counting~\citep{Collins:1960aa}. The strengths of copying
  5585. collectors are that allocation is fast (just a comparison and pointer
  5586. increment), there is no fragmentation, cyclic garbage is collected,
  5587. and the time complexity of collection only depends on the amount of
  5588. live data, and not on the amount of garbage~\citep{Wilson:1992fk}. The
  5589. main disadvantages of a two-space copying collector is that it uses a
  5590. lot of space and takes a long time to perform the copy, though these
  5591. problems are ameliorated in generational collectors. Racket and
  5592. Scheme programs tend to allocate many small objects and generate a lot
  5593. of garbage, so copying and generational collectors are a good fit.
  5594. Garbage collection is an active research topic, especially concurrent
  5595. garbage collection~\citep{Tene:2011kx}. Researchers are continuously
  5596. developing new techniques and revisiting old
  5597. trade-offs~\citep{Blackburn:2004aa,Jones:2011aa,Shahriyar:2013aa,Cutler:2015aa,Shidal:2015aa,Osterlund:2016aa,Jacek:2019aa,Gamari:2020aa}. Researchers
  5598. meet every year at the International Symposium on Memory Management to
  5599. present these findings.
  5600. \subsection{Graph Copying via Cheney's Algorithm}
  5601. \label{sec:cheney}
  5602. \index{Cheney's algorithm}
  5603. Let us take a closer look at the copying of the live objects. The
  5604. allocated objects and pointers can be viewed as a graph and we need to
  5605. copy the part of the graph that is reachable from the root set. To
  5606. make sure we copy all of the reachable vertices in the graph, we need
  5607. an exhaustive graph traversal algorithm, such as depth-first search or
  5608. breadth-first search~\citep{Moore:1959aa,Cormen:2001uq}. Recall that
  5609. such algorithms take into account the possibility of cycles by marking
  5610. which vertices have already been visited, so as to ensure termination
  5611. of the algorithm. These search algorithms also use a data structure
  5612. such as a stack or queue as a to-do list to keep track of the vertices
  5613. that need to be visited. We use breadth-first search and a trick
  5614. due to \citet{Cheney:1970aa} for simultaneously representing the queue
  5615. and copying tuples into the ToSpace.
  5616. Figure~\ref{fig:cheney} shows several snapshots of the ToSpace as the
  5617. copy progresses. The queue is represented by a chunk of contiguous
  5618. memory at the beginning of the ToSpace, using two pointers to track
  5619. the front and the back of the queue. The algorithm starts by copying
  5620. all tuples that are immediately reachable from the root set into the
  5621. ToSpace to form the initial queue. When we copy a tuple, we mark the
  5622. old tuple to indicate that it has been visited. We discuss how this
  5623. marking is accomplish in Section~\ref{sec:data-rep-gc}. Note that any
  5624. pointers inside the copied tuples in the queue still point back to the
  5625. FromSpace. Once the initial queue has been created, the algorithm
  5626. enters a loop in which it repeatedly processes the tuple at the front
  5627. of the queue and pops it off the queue. To process a tuple, the
  5628. algorithm copies all the tuple that are directly reachable from it to
  5629. the ToSpace, placing them at the back of the queue. The algorithm then
  5630. updates the pointers in the popped tuple so they point to the newly
  5631. copied tuples.
  5632. \begin{figure}[tbp]
  5633. \centering \includegraphics[width=0.9\textwidth]{figs/cheney}
  5634. \caption{Depiction of the Cheney algorithm copying the live tuples.}
  5635. \label{fig:cheney}
  5636. \end{figure}
  5637. Getting back to Figure~\ref{fig:cheney}, in the first step we copy the
  5638. tuple whose second element is $42$ to the back of the queue. The other
  5639. pointer goes to a tuple that has already been copied, so we do not
  5640. need to copy it again, but we do need to update the pointer to the new
  5641. location. This can be accomplished by storing a \emph{forwarding
  5642. pointer} to the new location in the old tuple, back when we initially
  5643. copied the tuple into the ToSpace. This completes one step of the
  5644. algorithm. The algorithm continues in this way until the front of the
  5645. queue is empty, that is, until the front catches up with the back.
  5646. \subsection{Data Representation}
  5647. \label{sec:data-rep-gc}
  5648. The garbage collector places some requirements on the data
  5649. representations used by our compiler. First, the garbage collector
  5650. needs to distinguish between pointers and other kinds of data. There
  5651. are several ways to accomplish this.
  5652. \begin{enumerate}
  5653. \item Attached a tag to each object that identifies what type of
  5654. object it is~\citep{McCarthy:1960dz}.
  5655. \item Store different types of objects in different
  5656. regions~\citep{Steele:1977ab}.
  5657. \item Use type information from the program to either generate
  5658. type-specific code for collecting or to generate tables that can
  5659. guide the
  5660. collector~\citep{Appel:1989aa,Goldberg:1991aa,Diwan:1992aa}.
  5661. \end{enumerate}
  5662. Dynamically typed languages, such as Lisp, need to tag objects
  5663. anyways, so option 1 is a natural choice for those languages.
  5664. However, $R_3$ is a statically typed language, so it would be
  5665. unfortunate to require tags on every object, especially small and
  5666. pervasive objects like integers and Booleans. Option 3 is the
  5667. best-performing choice for statically typed languages, but comes with
  5668. a relatively high implementation complexity. To keep this chapter
  5669. within a 2-week time budget, we recommend a combination of options 1
  5670. and 2, using separate strategies for the stack and the heap.
  5671. Regarding the stack, we recommend using a separate stack for pointers,
  5672. which we call a \emph{root stack}\index{root stack} (a.k.a. ``shadow
  5673. stack'')~\citep{Siebert:2001aa,Henderson:2002aa,Baker:2009aa}. That
  5674. is, when a local variable needs to be spilled and is of type
  5675. \code{(Vector $\Type_1 \ldots \Type_n$)}, then we put it on the root
  5676. stack instead of the normal procedure call stack. Furthermore, we
  5677. always spill vector-typed variables if they are live during a call to
  5678. the collector, thereby ensuring that no pointers are in registers
  5679. during a collection. Figure~\ref{fig:shadow-stack} reproduces the
  5680. example from Figure~\ref{fig:copying-collector} and contrasts it with
  5681. the data layout using a root stack. The root stack contains the two
  5682. pointers from the regular stack and also the pointer in the second
  5683. register.
  5684. \begin{figure}[tbp]
  5685. \centering \includegraphics[width=0.60\textwidth]{figs/root-stack}
  5686. \caption{Maintaining a root stack to facilitate garbage collection.}
  5687. \label{fig:shadow-stack}
  5688. \end{figure}
  5689. The problem of distinguishing between pointers and other kinds of data
  5690. also arises inside of each tuple on the heap. We solve this problem by
  5691. attaching a tag, an extra 64-bits, to each
  5692. tuple. Figure~\ref{fig:tuple-rep} zooms in on the tags for two of the
  5693. tuples in the example from Figure~\ref{fig:copying-collector}. Note
  5694. that we have drawn the bits in a big-endian way, from right-to-left,
  5695. with bit location 0 (the least significant bit) on the far right,
  5696. which corresponds to the direction of the x86 shifting instructions
  5697. \key{salq} (shift left) and \key{sarq} (shift right). Part of each tag
  5698. is dedicated to specifying which elements of the tuple are pointers,
  5699. the part labeled ``pointer mask''. Within the pointer mask, a 1 bit
  5700. indicates there is a pointer and a 0 bit indicates some other kind of
  5701. data. The pointer mask starts at bit location 7. We have limited
  5702. tuples to a maximum size of 50 elements, so we just need 50 bits for
  5703. the pointer mask. The tag also contains two other pieces of
  5704. information. The length of the tuple (number of elements) is stored in
  5705. bits location 1 through 6. Finally, the bit at location 0 indicates
  5706. whether the tuple has yet to be copied to the ToSpace. If the bit has
  5707. value 1, then this tuple has not yet been copied. If the bit has
  5708. value 0 then the entire tag is a forwarding pointer. (The lower 3 bits
  5709. of a pointer are always zero anyways because our tuples are 8-byte
  5710. aligned.)
  5711. \begin{figure}[tbp]
  5712. \centering \includegraphics[width=0.8\textwidth]{figs/tuple-rep}
  5713. \caption{Representation of tuples in the heap.}
  5714. \label{fig:tuple-rep}
  5715. \end{figure}
  5716. \subsection{Implementation of the Garbage Collector}
  5717. \label{sec:organize-gz}
  5718. \index{prelude}
  5719. An implementation of the copying collector is provided in the
  5720. \code{runtime.c} file. Figure~\ref{fig:gc-header} defines the
  5721. interface to the garbage collector that is used by the compiler. The
  5722. \code{initialize} function creates the FromSpace, ToSpace, and root
  5723. stack and should be called in the prelude of the \code{main}
  5724. function. The arguments of \code{initialize} are the root stack size
  5725. and the heap size. Both need to be multiples of $64$ and $16384$ is a
  5726. good choice for both. The \code{initialize} function puts the address
  5727. of the beginning of the FromSpace into the global variable
  5728. \code{free\_ptr}. The global variable \code{fromspace\_end} points to
  5729. the address that is 1-past the last element of the FromSpace. (We use
  5730. half-open intervals to represent chunks of
  5731. memory~\citep{Dijkstra:1982aa}.) The \code{rootstack\_begin} variable
  5732. points to the first element of the root stack.
  5733. As long as there is room left in the FromSpace, your generated code
  5734. can allocate tuples simply by moving the \code{free\_ptr} forward.
  5735. %
  5736. The amount of room left in FromSpace is the difference between the
  5737. \code{fromspace\_end} and the \code{free\_ptr}. The \code{collect}
  5738. function should be called when there is not enough room left in the
  5739. FromSpace for the next allocation. The \code{collect} function takes
  5740. a pointer to the current top of the root stack (one past the last item
  5741. that was pushed) and the number of bytes that need to be
  5742. allocated. The \code{collect} function performs the copying collection
  5743. and leaves the heap in a state such that the next allocation will
  5744. succeed.
  5745. \begin{figure}[tbp]
  5746. \begin{lstlisting}
  5747. void initialize(uint64_t rootstack_size, uint64_t heap_size);
  5748. void collect(int64_t** rootstack_ptr, uint64_t bytes_requested);
  5749. int64_t* free_ptr;
  5750. int64_t* fromspace_begin;
  5751. int64_t* fromspace_end;
  5752. int64_t** rootstack_begin;
  5753. \end{lstlisting}
  5754. \caption{The compiler's interface to the garbage collector.}
  5755. \label{fig:gc-header}
  5756. \end{figure}
  5757. %% \begin{exercise}
  5758. %% In the file \code{runtime.c} you will find the implementation of
  5759. %% \code{initialize} and a partial implementation of \code{collect}.
  5760. %% The \code{collect} function calls another function, \code{cheney},
  5761. %% to perform the actual copy, and that function is left to the reader
  5762. %% to implement. The following is the prototype for \code{cheney}.
  5763. %% \begin{lstlisting}
  5764. %% static void cheney(int64_t** rootstack_ptr);
  5765. %% \end{lstlisting}
  5766. %% The parameter \code{rootstack\_ptr} is a pointer to the top of the
  5767. %% rootstack (which is an array of pointers). The \code{cheney} function
  5768. %% also communicates with \code{collect} through the global
  5769. %% variables \code{fromspace\_begin} and \code{fromspace\_end}
  5770. %% mentioned in Figure~\ref{fig:gc-header} as well as the pointers for
  5771. %% the ToSpace:
  5772. %% \begin{lstlisting}
  5773. %% static int64_t* tospace_begin;
  5774. %% static int64_t* tospace_end;
  5775. %% \end{lstlisting}
  5776. %% The job of the \code{cheney} function is to copy all the live
  5777. %% objects (reachable from the root stack) into the ToSpace, update
  5778. %% \code{free\_ptr} to point to the next unused spot in the ToSpace,
  5779. %% update the root stack so that it points to the objects in the
  5780. %% ToSpace, and finally to swap the global pointers for the FromSpace
  5781. %% and ToSpace.
  5782. %% \end{exercise}
  5783. %% \section{Compiler Passes}
  5784. %% \label{sec:code-generation-gc}
  5785. The introduction of garbage collection has a non-trivial impact on our
  5786. compiler passes. We introduce a new compiler pass named
  5787. \code{expose-allocation}. We make
  5788. significant changes to \code{select-instructions},
  5789. \code{build-interference}, \code{allocate-registers}, and
  5790. \code{print-x86} and make minor changes in several more passes. The
  5791. following program will serve as our running example. It creates two
  5792. tuples, one nested inside the other. Both tuples have length one. The
  5793. program accesses the element in the inner tuple tuple via two vector
  5794. references.
  5795. % tests/s2_17.rkt
  5796. \begin{lstlisting}
  5797. (vector-ref (vector-ref (vector (vector 42)) 0) 0)
  5798. \end{lstlisting}
  5799. \section{Shrink}
  5800. \label{sec:shrink-R3}
  5801. Recall that the \code{shrink} pass translates the primitives operators
  5802. into a smaller set of primitives. Because this pass comes after type
  5803. checking, but before the passes that require the type information in
  5804. the \code{HasType} AST nodes, the \code{shrink} pass must be modified
  5805. to wrap \code{HasType} around each AST node that it generates.
  5806. \section{Expose Allocation}
  5807. \label{sec:expose-allocation}
  5808. The pass \code{expose-allocation} lowers the \code{vector} creation
  5809. form into a conditional call to the collector followed by the
  5810. allocation. We choose to place the \code{expose-allocation} pass
  5811. before \code{remove-complex-opera*} because the code generated by
  5812. \code{expose-allocation} contains complex operands. We also place
  5813. \code{expose-allocation} before \code{explicate-control} because
  5814. \code{expose-allocation} introduces new variables using \code{let},
  5815. but \code{let} is gone after \code{explicate-control}.
  5816. The output of \code{expose-allocation} is a language $R'_3$ that
  5817. extends $R_3$ with the three new forms that we use in the translation
  5818. of the \code{vector} form.
  5819. \[
  5820. \begin{array}{lcl}
  5821. \Exp &::=& \cdots
  5822. \mid (\key{collect} \,\itm{int})
  5823. \mid (\key{allocate} \,\itm{int}\,\itm{type})
  5824. \mid (\key{global-value} \,\itm{name})
  5825. \end{array}
  5826. \]
  5827. The $(\key{collect}\,n)$ form runs the garbage collector, requesting
  5828. $n$ bytes. It will become a call to the \code{collect} function in
  5829. \code{runtime.c} in \code{select-instructions}. The
  5830. $(\key{allocate}\,n\,T)$ form creates an tuple of $n$ elements.
  5831. \index{allocate}
  5832. The $T$ parameter is the type of the tuple: \code{(Vector $\Type_1 \ldots
  5833. \Type_n$)} where $\Type_i$ is the type of the $i$th element in the
  5834. tuple. The $(\key{global-value}\,\itm{name})$ form reads the value of
  5835. a global variable, such as \code{free\_ptr}.
  5836. In the following, we show the transformation for the \code{vector}
  5837. form into 1) a sequence of let-bindings for the initializing
  5838. expressions, 2) a conditional call to \code{collect}, 3) a call to
  5839. \code{allocate}, and 4) the initialization of the vector. In the
  5840. following, \itm{len} refers to the length of the vector and
  5841. \itm{bytes} is how many total bytes need to be allocated for the
  5842. vector, which is 8 for the tag plus \itm{len} times 8.
  5843. \begin{lstlisting}
  5844. (has-type (vector |$e_0 \ldots e_{n-1}$|) |\itm{type}|)
  5845. |$\Longrightarrow$|
  5846. (let ([|$x_0$| |$e_0$|]) ... (let ([|$x_{n-1}$| |$e_{n-1}$|])
  5847. (let ([_ (if (< (+ (global-value free_ptr) |\itm{bytes}|)
  5848. (global-value fromspace_end))
  5849. (void)
  5850. (collect |\itm{bytes}|))])
  5851. (let ([|$v$| (allocate |\itm{len}| |\itm{type}|)])
  5852. (let ([_ (vector-set! |$v$| |$0$| |$x_0$|)]) ...
  5853. (let ([_ (vector-set! |$v$| |$n-1$| |$x_{n-1}$|)])
  5854. |$v$|) ... )))) ...)
  5855. \end{lstlisting}
  5856. In the above, we suppressed all of the \code{has-type} forms in the
  5857. output for the sake of readability. The placement of the initializing
  5858. expressions $e_0,\ldots,e_{n-1}$ prior to the \code{allocate} and the
  5859. sequence of \code{vector-set!} is important, as those expressions may
  5860. trigger garbage collection and we cannot have an allocated but
  5861. uninitialized tuple on the heap during a collection.
  5862. Figure~\ref{fig:expose-alloc-output} shows the output of the
  5863. \code{expose-allocation} pass on our running example.
  5864. \begin{figure}[tbp]
  5865. % tests/s2_17.rkt
  5866. \begin{lstlisting}
  5867. (vector-ref
  5868. (vector-ref
  5869. (let ([vecinit7976
  5870. (let ([vecinit7972 42])
  5871. (let ([collectret7974
  5872. (if (< (+ (global-value free_ptr) 16)
  5873. (global-value fromspace_end))
  5874. (void)
  5875. (collect 16)
  5876. )])
  5877. (let ([alloc7971 (allocate 1 (Vector Integer))])
  5878. (let ([initret7973 (vector-set! alloc7971 0 vecinit7972)])
  5879. alloc7971)
  5880. )
  5881. )
  5882. )
  5883. ])
  5884. (let ([collectret7978
  5885. (if (< (+ (global-value free_ptr) 16)
  5886. (global-value fromspace_end))
  5887. (void)
  5888. (collect 16)
  5889. )])
  5890. (let ([alloc7975 (allocate 1 (Vector (Vector Integer)))])
  5891. (let ([initret7977 (vector-set! alloc7975 0 vecinit7976)])
  5892. alloc7975)
  5893. )
  5894. )
  5895. )
  5896. 0)
  5897. 0)
  5898. \end{lstlisting}
  5899. \caption{Output of the \code{expose-allocation} pass, minus
  5900. all of the \code{has-type} forms.}
  5901. \label{fig:expose-alloc-output}
  5902. \end{figure}
  5903. \section{Remove Complex Operands}
  5904. \label{sec:remove-complex-opera-R3}
  5905. The new forms \code{collect}, \code{allocate}, and \code{global-value}
  5906. should all be treated as complex operands.
  5907. %% A new case for
  5908. %% \code{HasType} is needed and the case for \code{Prim} needs to be
  5909. %% handled carefully to prevent the \code{Prim} node from being separated
  5910. %% from its enclosing \code{HasType}.
  5911. Figure~\ref{fig:r3-anf-syntax}
  5912. shows the grammar for the output language $R_3^{\dagger}$ of this
  5913. pass, which is $R_3$ in administrative normal form.
  5914. \begin{figure}[tp]
  5915. \centering
  5916. \fbox{
  5917. \begin{minipage}{0.96\textwidth}
  5918. \small
  5919. \[
  5920. \begin{array}{rcl}
  5921. \Atm &::=& \gray{ \INT{\Int} \mid \VAR{\Var} \mid \BOOL{\itm{bool}} }
  5922. \mid \VOID{} \\
  5923. \Exp &::=& \gray{ \Atm \mid \READ{} } \\
  5924. &\mid& \gray{ \NEG{\Atm} \mid \ADD{\Atm}{\Atm} } \\
  5925. &\mid& \gray{ \LET{\Var}{\Exp}{\Exp} } \\
  5926. &\mid& \gray{ \UNIOP{\key{'not}}{\Atm} } \\
  5927. &\mid& \gray{ \BINOP{\itm{cmp}}{\Atm}{\Atm} \mid \IF{\Exp}{\Exp}{\Exp} }\\
  5928. &\mid& \LP\key{Collect}~\Int\RP \mid \LP\key{Allocate}~\Int~\Type\RP
  5929. \mid \LP\key{GlobalValue}~\Var\RP\\
  5930. % &\mid& \LP\key{HasType}~\Exp~\Type\RP \\
  5931. R^{\dagger}_3 &::=& \gray{ \PROGRAM{\code{'()}}{\Exp} }
  5932. \end{array}
  5933. \]
  5934. \end{minipage}
  5935. }
  5936. \caption{$R_3^{\dagger}$ is $R_3$ in administrative normal form (ANF).}
  5937. \label{fig:r3-anf-syntax}
  5938. \end{figure}
  5939. \section{Explicate Control and the $C_2$ language}
  5940. \label{sec:explicate-control-r3}
  5941. \begin{figure}[tp]
  5942. \fbox{
  5943. \begin{minipage}{0.96\textwidth}
  5944. \small
  5945. \[
  5946. \begin{array}{lcl}
  5947. \Atm &::=& \gray{ \INT{\Int} \mid \VAR{\Var} \mid \BOOL{\itm{bool}} }\\
  5948. \itm{cmp} &::= & \gray{ \key{eq?} \mid \key{<} } \\
  5949. \Exp &::= & \gray{ \Atm \mid \READ{} } \\
  5950. &\mid& \gray{ \NEG{\Atm} \mid \ADD{\Atm}{\Atm} }\\
  5951. &\mid& \gray{ \UNIOP{\key{not}}{\Atm} \mid \BINOP{\itm{cmp}}{\Atm}{\Atm} } \\
  5952. &\mid& (\key{Allocate} \,\itm{int}\,\itm{type}) \\
  5953. &\mid& \BINOP{\key{'vector-ref}}{\Atm}{\INT{\Int}} \\
  5954. &\mid& (\key{Prim}~\key{'vector-set!}\,(\key{list}\,\Atm\,\INT{\Int}\,\Atm))\\
  5955. &\mid& (\key{GlobalValue} \,\Var) \mid (\key{Void})\\
  5956. \Stmt &::=& \gray{ \ASSIGN{\VAR{\Var}}{\Exp} }
  5957. \mid (\key{Collect} \,\itm{int}) \\
  5958. \Tail &::= & \gray{ \RETURN{\Exp} \mid \SEQ{\Stmt}{\Tail}
  5959. \mid \GOTO{\itm{label}} } \\
  5960. &\mid& \gray{ \IFSTMT{\BINOP{\itm{cmp}}{\Atm}{\Atm}}{\GOTO{\itm{label}}}{\GOTO{\itm{label}}} }\\
  5961. C_2 & ::= & \gray{ \PROGRAM{\itm{info}}{\CFG{(\itm{label}\,\key{.}\,\Tail)\ldots}} }
  5962. \end{array}
  5963. \]
  5964. \end{minipage}
  5965. }
  5966. \caption{The abstract syntax of $C_2$, extending $C_1$
  5967. (Figure~\ref{fig:c1-syntax}).}
  5968. \label{fig:c2-syntax}
  5969. \end{figure}
  5970. The output of \code{explicate-control} is a program in the
  5971. intermediate language $C_2$, whose abstract syntax is defined in
  5972. Figure~\ref{fig:c2-syntax}. (The concrete syntax is defined in
  5973. Figure~\ref{fig:c2-concrete-syntax} of the Appendix.) The new forms
  5974. of $C_2$ include the \key{allocate}, \key{vector-ref}, and
  5975. \key{vector-set!}, and \key{global-value} expressions and the
  5976. \code{collect} statement. The \code{explicate-control} pass can treat
  5977. these new forms much like the other expression forms that we've
  5978. already encoutered.
  5979. \section{Select Instructions and the x86$_2$ Language}
  5980. \label{sec:select-instructions-gc}
  5981. \index{instruction selection}
  5982. %% void (rep as zero)
  5983. %% allocate
  5984. %% collect (callq collect)
  5985. %% vector-ref
  5986. %% vector-set!
  5987. %% global (postpone)
  5988. In this pass we generate x86 code for most of the new operations that
  5989. were needed to compile tuples, including \code{Allocate},
  5990. \code{Collect}, \code{vector-ref}, \code{vector-set!}, and
  5991. \code{void}. We compile \code{GlobalValue} to \code{Global} because
  5992. the later has a different concrete syntax (see
  5993. Figures~\ref{fig:x86-2-concrete} and \ref{fig:x86-2}).
  5994. \index{x86}
  5995. The \code{vector-ref} and \code{vector-set!} forms translate into
  5996. \code{movq} instructions. (The plus one in the offset is to get past
  5997. the tag at the beginning of the tuple representation.)
  5998. \begin{lstlisting}
  5999. |$\itm{lhs}$| = (vector-ref |$\itm{vec}$| |$n$|);
  6000. |$\Longrightarrow$|
  6001. movq |$\itm{vec}'$|, %r11
  6002. movq |$8(n+1)$|(%r11), |$\itm{lhs'}$|
  6003. |$\itm{lhs}$| = (vector-set! |$\itm{vec}$| |$n$| |$\itm{arg}$|);
  6004. |$\Longrightarrow$|
  6005. movq |$\itm{vec}'$|, %r11
  6006. movq |$\itm{arg}'$|, |$8(n+1)$|(%r11)
  6007. movq $0, |$\itm{lhs'}$|
  6008. \end{lstlisting}
  6009. The $\itm{lhs}'$, $\itm{vec}'$, and $\itm{arg}'$ are obtained by
  6010. translating $\itm{vec}$ and $\itm{arg}$ to x86. The move of $\itm{vec}'$ to
  6011. register \code{r11} ensures that offset expression
  6012. \code{$-8(n+1)$(\%r11)} contains a register operand. This requires
  6013. removing \code{r11} from consideration by the register allocating.
  6014. Why not use \code{rax} instead of \code{r11}? Suppose we instead used
  6015. \code{rax}. Then the generated code for \code{vector-set!} would be
  6016. \begin{lstlisting}
  6017. movq |$\itm{vec}'$|, %rax
  6018. movq |$\itm{arg}'$|, |$8(n+1)$|(%rax)
  6019. movq $0, |$\itm{lhs}'$|
  6020. \end{lstlisting}
  6021. Next, suppose that $\itm{arg}'$ ends up as a stack location, so
  6022. \code{patch-instructions} would insert a move through \code{rax}
  6023. as follows.
  6024. \begin{lstlisting}
  6025. movq |$\itm{vec}'$|, %rax
  6026. movq |$\itm{arg}'$|, %rax
  6027. movq %rax, |$8(n+1)$|(%rax)
  6028. movq $0, |$\itm{lhs}'$|
  6029. \end{lstlisting}
  6030. But the above sequence of instructions does not work because we're
  6031. trying to use \code{rax} for two different values ($\itm{vec}'$ and
  6032. $\itm{arg}'$) at the same time!
  6033. We compile the \code{allocate} form to operations on the
  6034. \code{free\_ptr}, as shown below. The address in the \code{free\_ptr}
  6035. is the next free address in the FromSpace, so we copy it into
  6036. \code{r11} and then move it forward by enough space for the tuple
  6037. being allocated, which is $8(\itm{len}+1)$ bytes because each element
  6038. is 8 bytes (64 bits) and we use 8 bytes for the tag. We then
  6039. initialize the \itm{tag} and finally copy the address in \code{r11} to
  6040. the left-hand-side. Refer to Figure~\ref{fig:tuple-rep} to see how the
  6041. tag is organized. We recommend using the Racket operations
  6042. \code{bitwise-ior} and \code{arithmetic-shift} to compute the tag
  6043. during compilation. The type annotation in the \code{vector} form is
  6044. used to determine the pointer mask region of the tag.
  6045. \begin{lstlisting}
  6046. |$\itm{lhs}$| = (allocate |$\itm{len}$| (Vector |$\itm{type} \ldots$|));
  6047. |$\Longrightarrow$|
  6048. movq free_ptr(%rip), %r11
  6049. addq |$8(\itm{len}+1)$|, free_ptr(%rip)
  6050. movq $|$\itm{tag}$|, 0(%r11)
  6051. movq %r11, |$\itm{lhs}'$|
  6052. \end{lstlisting}
  6053. The \code{collect} form is compiled to a call to the \code{collect}
  6054. function in the runtime. The arguments to \code{collect} are 1) the
  6055. top of the root stack and 2) the number of bytes that need to be
  6056. allocated. We use another dedicated register, \code{r15}, to
  6057. store the pointer to the top of the root stack. So \code{r15} is not
  6058. available for use by the register allocator.
  6059. \begin{lstlisting}
  6060. (collect |$\itm{bytes}$|)
  6061. |$\Longrightarrow$|
  6062. movq %r15, %rdi
  6063. movq $|\itm{bytes}|, %rsi
  6064. callq collect
  6065. \end{lstlisting}
  6066. \begin{figure}[tp]
  6067. \fbox{
  6068. \begin{minipage}{0.96\textwidth}
  6069. \[
  6070. \begin{array}{lcl}
  6071. \Arg &::=& \gray{ \key{\$}\Int \mid \key{\%}\Reg \mid \Int\key{(}\key{\%}\Reg\key{)} \mid \key{\%}\itm{bytereg} } \mid \Var \key{(\%rip)} \\
  6072. x86_1 &::= & \gray{ \key{.globl main} }\\
  6073. & & \gray{ \key{main:} \; \Instr\ldots }
  6074. \end{array}
  6075. \]
  6076. \end{minipage}
  6077. }
  6078. \caption{The concrete syntax of x86$_2$ (extends x86$_1$ of Figure~\ref{fig:x86-1-concrete}).}
  6079. \label{fig:x86-2-concrete}
  6080. \end{figure}
  6081. \begin{figure}[tp]
  6082. \fbox{
  6083. \begin{minipage}{0.96\textwidth}
  6084. \small
  6085. \[
  6086. \begin{array}{lcl}
  6087. \Arg &::=& \gray{ \INT{\Int} \mid \REG{\Reg} \mid \DEREF{\Reg}{\Int}
  6088. \mid \BYTEREG{\Reg}} \\
  6089. &\mid& (\key{Global}~\Var) \\
  6090. x86_2 &::= & \gray{ \PROGRAM{\itm{info}}{\CFG{\key{(}\itm{label} \,\key{.}\, \Block \key{)}\ldots}} }
  6091. \end{array}
  6092. \]
  6093. \end{minipage}
  6094. }
  6095. \caption{The abstract syntax of x86$_2$ (extends x86$_1$ of Figure~\ref{fig:x86-1}).}
  6096. \label{fig:x86-2}
  6097. \end{figure}
  6098. The concrete and abstract syntax of the $x86_2$ language is defined in
  6099. Figures~\ref{fig:x86-2-concrete} and \ref{fig:x86-2}. It differs from
  6100. x86$_1$ just in the addition of the form for global variables.
  6101. %
  6102. Figure~\ref{fig:select-instr-output-gc} shows the output of the
  6103. \code{select-instructions} pass on the running example.
  6104. \begin{figure}[tbp]
  6105. \centering
  6106. % tests/s2_17.rkt
  6107. \begin{minipage}[t]{0.5\textwidth}
  6108. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  6109. block35:
  6110. movq free_ptr(%rip), alloc9024
  6111. addq $16, free_ptr(%rip)
  6112. movq alloc9024, %r11
  6113. movq $131, 0(%r11)
  6114. movq alloc9024, %r11
  6115. movq vecinit9025, 8(%r11)
  6116. movq $0, initret9026
  6117. movq alloc9024, %r11
  6118. movq 8(%r11), tmp9034
  6119. movq tmp9034, %r11
  6120. movq 8(%r11), %rax
  6121. jmp conclusion
  6122. block36:
  6123. movq $0, collectret9027
  6124. jmp block35
  6125. block38:
  6126. movq free_ptr(%rip), alloc9020
  6127. addq $16, free_ptr(%rip)
  6128. movq alloc9020, %r11
  6129. movq $3, 0(%r11)
  6130. movq alloc9020, %r11
  6131. movq vecinit9021, 8(%r11)
  6132. movq $0, initret9022
  6133. movq alloc9020, vecinit9025
  6134. movq free_ptr(%rip), tmp9031
  6135. movq tmp9031, tmp9032
  6136. addq $16, tmp9032
  6137. movq fromspace_end(%rip), tmp9033
  6138. cmpq tmp9033, tmp9032
  6139. jl block36
  6140. jmp block37
  6141. block37:
  6142. movq %r15, %rdi
  6143. movq $16, %rsi
  6144. callq 'collect
  6145. jmp block35
  6146. block39:
  6147. movq $0, collectret9023
  6148. jmp block38
  6149. \end{lstlisting}
  6150. \end{minipage}
  6151. \begin{minipage}[t]{0.45\textwidth}
  6152. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  6153. start:
  6154. movq $42, vecinit9021
  6155. movq free_ptr(%rip), tmp9028
  6156. movq tmp9028, tmp9029
  6157. addq $16, tmp9029
  6158. movq fromspace_end(%rip), tmp9030
  6159. cmpq tmp9030, tmp9029
  6160. jl block39
  6161. jmp block40
  6162. block40:
  6163. movq %r15, %rdi
  6164. movq $16, %rsi
  6165. callq 'collect
  6166. jmp block38
  6167. \end{lstlisting}
  6168. \end{minipage}
  6169. \caption{Output of the \code{select-instructions} pass.}
  6170. \label{fig:select-instr-output-gc}
  6171. \end{figure}
  6172. \clearpage
  6173. \section{Register Allocation}
  6174. \label{sec:reg-alloc-gc}
  6175. \index{register allocation}
  6176. As discussed earlier in this chapter, the garbage collector needs to
  6177. access all the pointers in the root set, that is, all variables that
  6178. are vectors. It will be the responsibility of the register allocator
  6179. to make sure that:
  6180. \begin{enumerate}
  6181. \item the root stack is used for spilling vector-typed variables, and
  6182. \item if a vector-typed variable is live during a call to the
  6183. collector, it must be spilled to ensure it is visible to the
  6184. collector.
  6185. \end{enumerate}
  6186. The later responsibility can be handled during construction of the
  6187. interference graph, by adding interference edges between the call-live
  6188. vector-typed variables and all the callee-saved registers. (They
  6189. already interfere with the caller-saved registers.) The type
  6190. information for variables is in the \code{Program} form, so we
  6191. recommend adding another parameter to the \code{build-interference}
  6192. function to communicate this alist.
  6193. The spilling of vector-typed variables to the root stack can be
  6194. handled after graph coloring, when choosing how to assign the colors
  6195. (integers) to registers and stack locations. The \code{Program} output
  6196. of this pass changes to also record the number of spills to the root
  6197. stack.
  6198. % build-interference
  6199. %
  6200. % callq
  6201. % extra parameter for var->type assoc. list
  6202. % update 'program' and 'if'
  6203. % allocate-registers
  6204. % allocate spilled vectors to the rootstack
  6205. % don't change color-graph
  6206. \section{Print x86}
  6207. \label{sec:print-x86-gc}
  6208. \index{prelude}\index{conclusion}
  6209. Figure~\ref{fig:print-x86-output-gc} shows the output of the
  6210. \code{print-x86} pass on the running example. In the prelude and
  6211. conclusion of the \code{main} function, we treat the root stack very
  6212. much like the regular stack in that we move the root stack pointer
  6213. (\code{r15}) to make room for the spills to the root stack, except
  6214. that the root stack grows up instead of down. For the running
  6215. example, there was just one spill so we increment \code{r15} by 8
  6216. bytes. In the conclusion we decrement \code{r15} by 8 bytes.
  6217. One issue that deserves special care is that there may be a call to
  6218. \code{collect} prior to the initializing assignments for all the
  6219. variables in the root stack. We do not want the garbage collector to
  6220. accidentally think that some uninitialized variable is a pointer that
  6221. needs to be followed. Thus, we zero-out all locations on the root
  6222. stack in the prelude of \code{main}. In
  6223. Figure~\ref{fig:print-x86-output-gc}, the instruction
  6224. %
  6225. \lstinline{movq $0, (%r15)}
  6226. %
  6227. accomplishes this task. The garbage collector tests each root to see
  6228. if it is null prior to dereferencing it.
  6229. \begin{figure}[htbp]
  6230. \begin{minipage}[t]{0.5\textwidth}
  6231. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  6232. block35:
  6233. movq free_ptr(%rip), %rcx
  6234. addq $16, free_ptr(%rip)
  6235. movq %rcx, %r11
  6236. movq $131, 0(%r11)
  6237. movq %rcx, %r11
  6238. movq -8(%r15), %rax
  6239. movq %rax, 8(%r11)
  6240. movq $0, %rdx
  6241. movq %rcx, %r11
  6242. movq 8(%r11), %rcx
  6243. movq %rcx, %r11
  6244. movq 8(%r11), %rax
  6245. jmp conclusion
  6246. block36:
  6247. movq $0, %rcx
  6248. jmp block35
  6249. block38:
  6250. movq free_ptr(%rip), %rcx
  6251. addq $16, free_ptr(%rip)
  6252. movq %rcx, %r11
  6253. movq $3, 0(%r11)
  6254. movq %rcx, %r11
  6255. movq %rbx, 8(%r11)
  6256. movq $0, %rdx
  6257. movq %rcx, -8(%r15)
  6258. movq free_ptr(%rip), %rcx
  6259. addq $16, %rcx
  6260. movq fromspace_end(%rip), %rdx
  6261. cmpq %rdx, %rcx
  6262. jl block36
  6263. movq %r15, %rdi
  6264. movq $16, %rsi
  6265. callq collect
  6266. jmp block35
  6267. block39:
  6268. movq $0, %rcx
  6269. jmp block38
  6270. \end{lstlisting}
  6271. \end{minipage}
  6272. \begin{minipage}[t]{0.45\textwidth}
  6273. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  6274. start:
  6275. movq $42, %rbx
  6276. movq free_ptr(%rip), %rdx
  6277. addq $16, %rdx
  6278. movq fromspace_end(%rip), %rcx
  6279. cmpq %rcx, %rdx
  6280. jl block39
  6281. movq %r15, %rdi
  6282. movq $16, %rsi
  6283. callq collect
  6284. jmp block38
  6285. .globl main
  6286. main:
  6287. pushq %rbp
  6288. movq %rsp, %rbp
  6289. pushq %r13
  6290. pushq %r12
  6291. pushq %rbx
  6292. pushq %r14
  6293. subq $0, %rsp
  6294. movq $16384, %rdi
  6295. movq $16384, %rsi
  6296. callq initialize
  6297. movq rootstack_begin(%rip), %r15
  6298. movq $0, (%r15)
  6299. addq $8, %r15
  6300. jmp start
  6301. conclusion:
  6302. subq $8, %r15
  6303. addq $0, %rsp
  6304. popq %r14
  6305. popq %rbx
  6306. popq %r12
  6307. popq %r13
  6308. popq %rbp
  6309. retq
  6310. \end{lstlisting}
  6311. \end{minipage}
  6312. \caption{Output of the \code{print-x86} pass.}
  6313. \label{fig:print-x86-output-gc}
  6314. \end{figure}
  6315. \begin{figure}[p]
  6316. \begin{tikzpicture}[baseline=(current bounding box.center)]
  6317. \node (R3) at (0,2) {\large $R_3$};
  6318. \node (R3-2) at (3,2) {\large $R_3$};
  6319. \node (R3-3) at (6,2) {\large $R_3$};
  6320. \node (R3-4) at (9,2) {\large $R_3$};
  6321. \node (R3-5) at (12,2) {\large $R'_3$};
  6322. \node (C2-4) at (3,0) {\large $C_2$};
  6323. \node (x86-2) at (3,-2) {\large $\text{x86}^{*}_2$};
  6324. \node (x86-3) at (6,-2) {\large $\text{x86}^{*}_2$};
  6325. \node (x86-4) at (9,-2) {\large $\text{x86}^{*}_2$};
  6326. \node (x86-5) at (9,-4) {\large $\text{x86}^{\dagger}_2$};
  6327. \node (x86-2-1) at (3,-4) {\large $\text{x86}^{*}_2$};
  6328. \node (x86-2-2) at (6,-4) {\large $\text{x86}^{*}_2$};
  6329. %\path[->,bend left=15] (R3) edge [above] node {\ttfamily\footnotesize type-check} (R3-2);
  6330. \path[->,bend left=15] (R3) edge [above] node {\ttfamily\footnotesize shrink} (R3-2);
  6331. \path[->,bend left=15] (R3-2) edge [above] node {\ttfamily\footnotesize uniquify} (R3-3);
  6332. \path[->,bend left=15] (R3-3) edge [above] node {\ttfamily\footnotesize expose-alloc.} (R3-4);
  6333. \path[->,bend left=15] (R3-4) edge [above] node {\ttfamily\footnotesize remove-complex.} (R3-5);
  6334. \path[->,bend left=20] (R3-5) edge [left] node {\ttfamily\footnotesize explicate-control} (C2-4);
  6335. \path[->,bend left=15] (C2-4) edge [right] node {\ttfamily\footnotesize select-instr.} (x86-2);
  6336. \path[->,bend right=15] (x86-2) edge [left] node {\ttfamily\footnotesize uncover-live} (x86-2-1);
  6337. \path[->,bend right=15] (x86-2-1) edge [below] node {\ttfamily\footnotesize build-inter.} (x86-2-2);
  6338. \path[->,bend right=15] (x86-2-2) edge [right] node {\ttfamily\footnotesize allocate-reg.} (x86-3);
  6339. \path[->,bend left=15] (x86-3) edge [above] node {\ttfamily\footnotesize patch-instr.} (x86-4);
  6340. \path[->,bend left=15] (x86-4) edge [right] node {\ttfamily\footnotesize print-x86} (x86-5);
  6341. \end{tikzpicture}
  6342. \caption{Diagram of the passes for $R_3$, a language with tuples.}
  6343. \label{fig:R3-passes}
  6344. \end{figure}
  6345. Figure~\ref{fig:R3-passes} gives an overview of all the passes needed
  6346. for the compilation of $R_3$.
  6347. \section{Challenge: Simple Structures}
  6348. \label{sec:simple-structures}
  6349. \index{struct}
  6350. \index{structure}
  6351. Figure~\ref{fig:r3s-concrete-syntax} defines the concrete syntax for
  6352. $R^s_3$, which extends $R^3$ with support for simple structures.
  6353. Recall that a \code{struct} in Typed Racket is a user-defined data
  6354. type that contains named fields and that is heap allocated, similar to
  6355. a vector. The following is an example of a structure definition, in
  6356. this case the definition of a \code{point} type.
  6357. \begin{lstlisting}
  6358. (struct point ([x : Integer] [y : Integer]) #:mutable)
  6359. \end{lstlisting}
  6360. \begin{figure}[tbp]
  6361. \centering
  6362. \fbox{
  6363. \begin{minipage}{0.96\textwidth}
  6364. \[
  6365. \begin{array}{lcl}
  6366. \Type &::=& \gray{\key{Integer} \mid \key{Boolean}
  6367. \mid (\key{Vector}\;\Type \ldots) \mid \key{Void} } \mid \Var \\
  6368. \itm{cmp} &::= & \gray{ \key{eq?} \mid \key{<} \mid \key{<=} \mid \key{>} \mid \key{>=} } \\
  6369. \Exp &::=& \gray{ \Int \mid (\key{read}) \mid (\key{-}\;\Exp) \mid (\key{+} \; \Exp\;\Exp) \mid (\key{-}\;\Exp\;\Exp) } \\
  6370. &\mid& \gray{ \Var \mid (\key{let}~([\Var~\Exp])~\Exp) }\\
  6371. &\mid& \gray{ \key{\#t} \mid \key{\#f}
  6372. \mid (\key{and}\;\Exp\;\Exp)
  6373. \mid (\key{or}\;\Exp\;\Exp)
  6374. \mid (\key{not}\;\Exp) } \\
  6375. &\mid& \gray{ (\itm{cmp}\;\Exp\;\Exp)
  6376. \mid (\key{if}~\Exp~\Exp~\Exp) } \\
  6377. &\mid& \gray{ (\key{vector}\;\Exp \ldots)
  6378. \mid (\key{vector-ref}\;\Exp\;\Int) } \\
  6379. &\mid& \gray{ (\key{vector-set!}\;\Exp\;\Int\;\Exp) }\\
  6380. &\mid& \gray{ (\key{void}) } \mid (\Var\;\Exp \ldots)\\
  6381. \Def &::=& (\key{struct}\; \Var \; ([\Var \,\key{:}\, \Type] \ldots)\; \code{\#:mutable})\\
  6382. R_3 &::=& \Def \ldots \; \Exp
  6383. \end{array}
  6384. \]
  6385. \end{minipage}
  6386. }
  6387. \caption{The concrete syntax of $R^s_3$, extending $R_3$
  6388. (Figure~\ref{fig:r3-concrete-syntax}).}
  6389. \label{fig:r3s-concrete-syntax}
  6390. \end{figure}
  6391. An instance of a structure is created using function call syntax, with
  6392. the name of the structure in the function position:
  6393. \begin{lstlisting}
  6394. (point 7 12)
  6395. \end{lstlisting}
  6396. Function-call syntax is also used to read the value in a field of a
  6397. structure. The function name is formed by the structure name, a dash,
  6398. and the field name. The following example uses \code{point-x} and
  6399. \code{point-y} to access the \code{x} and \code{y} fields of two point
  6400. instances.
  6401. \begin{center}
  6402. \begin{lstlisting}
  6403. (let ([pt1 (point 7 12)])
  6404. (let ([pt2 (point 4 3)])
  6405. (+ (- (point-x pt1) (point-x pt2))
  6406. (- (point-y pt1) (point-y pt2)))))
  6407. \end{lstlisting}
  6408. \end{center}
  6409. Similarly, to write to a field of a structure, use its set function,
  6410. whose name starts with \code{set-}, followed by the structure name,
  6411. then a dash, then the field name, and concluded with an exclamation
  6412. mark. The following example uses \code{set-point-x!} to change the
  6413. \code{x} field from \code{7} to \code{42}.
  6414. \begin{center}
  6415. \begin{lstlisting}
  6416. (let ([pt (point 7 12)])
  6417. (let ([_ (set-point-x! pt 42)])
  6418. (point-x pt)))
  6419. \end{lstlisting}
  6420. \end{center}
  6421. \begin{exercise}\normalfont
  6422. Extend your compiler with support for simple structures, compiling
  6423. $R^s_3$ to x86 assembly code. Create five new test cases that use
  6424. structures and test your compiler.
  6425. \end{exercise}
  6426. \section{Challenge: Generational Collection}
  6427. The copying collector described in Section~\ref{sec:GC} can incur
  6428. significant runtime overhead because the call to \code{collect} takes
  6429. time proportional to all of the live data. One way to reduce this
  6430. overhead is to reduce how much data is inspected in each call to
  6431. \code{collect}. In particular, researchers have observed that recently
  6432. allocated data is more likely to become garbage then data that has
  6433. survived one or more previous calls to \code{collect}. This insight
  6434. motivated the creation of \emph{generational garbage collectors}
  6435. \index{generational garbage collector} that
  6436. 1) segregates data according to its age into two or more generations,
  6437. 2) allocates less space for younger generations, so collecting them is
  6438. faster, and more space for the older generations, and 3) performs
  6439. collection on the younger generations more frequently then for older
  6440. generations~\citep{Wilson:1992fk}.
  6441. For this challenge assignment, the goal is to adapt the copying
  6442. collector implemented in \code{runtime.c} to use two generations, one
  6443. for young data and one for old data. Each generation consists of a
  6444. FromSpace and a ToSpace. The following is a sketch of how to adapt the
  6445. \code{collect} function to use the two generations.
  6446. \begin{enumerate}
  6447. \item Copy the young generation's FromSpace to its ToSpace then switch
  6448. the role of the ToSpace and FromSpace
  6449. \item If there is enough space for the requested number of bytes in
  6450. the young FromSpace, then return from \code{collect}.
  6451. \item If there is not enough space in the young FromSpace for the
  6452. requested bytes, then move the data from the young generation to the
  6453. old one with the following steps:
  6454. \begin{enumerate}
  6455. \item If there is enough room in the old FromSpace, copy the young
  6456. FromSpace to the old FromSpace and then return.
  6457. \item If there is not enough room in the old FromSpace, then collect
  6458. the old generation by copying the old FromSpace to the old ToSpace
  6459. and swap the roles of the old FromSpace and ToSpace.
  6460. \item If there is enough room now, copy the young FromSpace to the
  6461. old FromSpace and return. Otherwise, allocate a larger FromSpace
  6462. and ToSpace for the old generation. Copy the young FromSpace and
  6463. the old FromSpace into the larger FromSpace for the old
  6464. generation and then return.
  6465. \end{enumerate}
  6466. \end{enumerate}
  6467. We recommend that you generalize the \code{cheney} function so that it
  6468. can be used for all the copies mentioned above: between the young
  6469. FromSpace and ToSpace, between the old FromSpace and ToSpace, and
  6470. between the young FromSpace and old FromSpace. This can be
  6471. accomplished by adding parameters to \code{cheney} that replace its
  6472. use of the global variables \code{fromspace\_begin},
  6473. \code{fromspace\_end}, \code{tospace\_begin}, and \code{tospace\_end}.
  6474. Note that the collection of the young generation does not traverse the
  6475. old generation. This introduces a potential problem: there may be
  6476. young data that is only reachable through pointers in the old
  6477. generation. If these pointers are not taken into account, the
  6478. collector could throw away young data that is live! One solution,
  6479. called \emph{pointer recording}, is to maintain a set of all the
  6480. pointers from the old generation into the new generation and consider
  6481. this set as part of the root set. To maintain this set, the compiler
  6482. must insert extra instructions around every \code{vector-set!}. If the
  6483. vector being modified is in the old generation, and if the value being
  6484. written is a pointer into the new generation, than that pointer must
  6485. be added to the set. Also, if the value being overwritten was a
  6486. pointer into the new generation, then that pointer should be removed
  6487. from the set.
  6488. \begin{exercise}\normalfont
  6489. Adapt the \code{collect} function in \code{runtime.c} to implement
  6490. generational garbage collection, as outlined in this section.
  6491. Update the code generation for \code{vector-set!} to implement
  6492. pointer recording. Make sure that your new compiler and runtime
  6493. passes your test suite.
  6494. \end{exercise}
  6495. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  6496. \chapter{Functions}
  6497. \label{ch:functions}
  6498. \index{function}
  6499. This chapter studies the compilation of functions similar to those
  6500. found in the C language. This corresponds to a subset of Typed Racket
  6501. in which only top-level function definitions are allowed. This kind of
  6502. function is an important stepping stone to implementing
  6503. lexically-scoped functions, that is, \key{lambda} abstractions, which
  6504. is the topic of Chapter~\ref{ch:lambdas}.
  6505. \section{The $R_4$ Language}
  6506. The concrete and abstract syntax for function definitions and function
  6507. application is shown in Figures~\ref{fig:r4-concrete-syntax} and
  6508. \ref{fig:r4-syntax}, where we define the $R_4$ language. Programs in
  6509. $R_4$ begin with zero or more function definitions. The function
  6510. names from these definitions are in-scope for the entire program,
  6511. including all other function definitions (so the ordering of function
  6512. definitions does not matter). The concrete syntax for function
  6513. application\index{function application} is $(\Exp \; \Exp \ldots)$
  6514. where the first expression must
  6515. evaluate to a function and the rest are the arguments.
  6516. The abstract syntax for function application is
  6517. $\APPLY{\Exp}{\Exp\ldots}$.
  6518. %% The syntax for function application does not include an explicit
  6519. %% keyword, which is error prone when using \code{match}. To alleviate
  6520. %% this problem, we translate the syntax from $(\Exp \; \Exp \ldots)$ to
  6521. %% $(\key{app}\; \Exp \; \Exp \ldots)$ during type checking.
  6522. Functions are first-class in the sense that a function pointer
  6523. \index{function pointer} is data and can be stored in memory or passed
  6524. as a parameter to another function. Thus, we introduce a function
  6525. type, written
  6526. \begin{lstlisting}
  6527. (|$\Type_1$| |$\cdots$| |$\Type_n$| -> |$\Type_r$|)
  6528. \end{lstlisting}
  6529. for a function whose $n$ parameters have the types $\Type_1$ through
  6530. $\Type_n$ and whose return type is $\Type_r$. The main limitation of
  6531. these functions (with respect to Racket functions) is that they are
  6532. not lexically scoped. That is, the only external entities that can be
  6533. referenced from inside a function body are other globally-defined
  6534. functions. The syntax of $R_4$ prevents functions from being nested
  6535. inside each other.
  6536. \begin{figure}[tp]
  6537. \centering
  6538. \fbox{
  6539. \begin{minipage}{0.96\textwidth}
  6540. \small
  6541. \[
  6542. \begin{array}{lcl}
  6543. \Type &::=& \gray{ \key{Integer} \mid \key{Boolean}
  6544. \mid (\key{Vector}\;\Type\ldots) \mid \key{Void} } \mid (\Type \ldots \; \key{->}\; \Type) \\
  6545. \itm{cmp} &::= & \gray{ \key{eq?} \mid \key{<} \mid \key{<=} \mid \key{>} \mid \key{>=} } \\
  6546. \Exp &::=& \gray{ \Int \mid \CREAD{} \mid \CNEG{\Exp} \mid \CADD{\Exp}{\Exp} \mid \CSUB{\Exp}{\Exp} } \\
  6547. &\mid& \gray{ \Var \mid \CLET{\Var}{\Exp}{\Exp} }\\
  6548. &\mid& \gray{ \key{\#t} \mid \key{\#f}
  6549. \mid (\key{and}\;\Exp\;\Exp)
  6550. \mid (\key{or}\;\Exp\;\Exp)
  6551. \mid (\key{not}\;\Exp)} \\
  6552. &\mid& \gray{(\itm{cmp}\;\Exp\;\Exp) \mid \CIF{\Exp}{\Exp}{\Exp} } \\
  6553. &\mid& \gray{(\key{vector}\;\Exp\ldots) \mid
  6554. (\key{vector-ref}\;\Exp\;\Int)} \\
  6555. &\mid& \gray{(\key{vector-set!}\;\Exp\;\Int\;\Exp)\mid (\key{void})
  6556. \mid \LP\key{has-type}~\Exp~\Type\RP } \\
  6557. &\mid& \LP\Exp \; \Exp \ldots\RP \\
  6558. \Def &::=& \CDEF{\Var}{\LS\Var \key{:} \Type\RS \ldots}{\Type}{\Exp} \\
  6559. R_4 &::=& \Def \ldots \; \Exp
  6560. \end{array}
  6561. \]
  6562. \end{minipage}
  6563. }
  6564. \caption{The concrete syntax of $R_4$, extending $R_3$ (Figure~\ref{fig:r3-concrete-syntax}).}
  6565. \label{fig:r4-concrete-syntax}
  6566. \end{figure}
  6567. \begin{figure}[tp]
  6568. \centering
  6569. \fbox{
  6570. \begin{minipage}{0.96\textwidth}
  6571. \small
  6572. \[
  6573. \begin{array}{lcl}
  6574. \Exp &::=& \gray{ \INT{\Int} \VAR{\Var} \mid \LET{\Var}{\Exp}{\Exp} } \\
  6575. &\mid& \gray{ \PRIM{\itm{op}}{\Exp\ldots} }\\
  6576. &\mid& \gray{ \BOOL{\itm{bool}}
  6577. \mid \IF{\Exp}{\Exp}{\Exp} } \\
  6578. &\mid& \gray{ \VOID{} \mid \LP\key{HasType}~\Exp~\Type \RP }
  6579. \mid \APPLY{\Exp}{\Exp\ldots}\\
  6580. \Def &::=& \FUNDEF{\Var}{\LP[\Var \code{:} \Type]\ldots\RP}{\Type}{\code{'()}}{\Exp}\\
  6581. R_4 &::=& \PROGRAMDEFSEXP{\code{'()}}{\LP\Def\ldots\RP)}{\Exp}
  6582. \end{array}
  6583. \]
  6584. \end{minipage}
  6585. }
  6586. \caption{The abstract syntax of $R_4$, extending $R_3$ (Figure~\ref{fig:r3-syntax}).}
  6587. \label{fig:r4-syntax}
  6588. \end{figure}
  6589. The program in Figure~\ref{fig:r4-function-example} is a
  6590. representative example of defining and using functions in $R_4$. We
  6591. define a function \code{map-vec} that applies some other function
  6592. \code{f} to both elements of a vector and returns a new
  6593. vector containing the results. We also define a function \code{add1}.
  6594. The program applies
  6595. \code{map-vec} to \code{add1} and \code{(vector 0 41)}. The result is
  6596. \code{(vector 1 42)}, from which we return the \code{42}.
  6597. \begin{figure}[tbp]
  6598. \begin{lstlisting}
  6599. (define (map-vec [f : (Integer -> Integer)]
  6600. [v : (Vector Integer Integer)])
  6601. : (Vector Integer Integer)
  6602. (vector (f (vector-ref v 0)) (f (vector-ref v 1))))
  6603. (define (add1 [x : Integer]) : Integer
  6604. (+ x 1))
  6605. (vector-ref (map-vec add1 (vector 0 41)) 1)
  6606. \end{lstlisting}
  6607. \caption{Example of using functions in $R_4$.}
  6608. \label{fig:r4-function-example}
  6609. \end{figure}
  6610. The definitional interpreter for $R_4$ is in
  6611. Figure~\ref{fig:interp-R4}. The case for the \code{ProgramDefsExp} form is
  6612. responsible for setting up the mutual recursion between the top-level
  6613. function definitions. We use the classic back-patching \index{back-patching}
  6614. approach that uses mutable variables and makes two passes over the function
  6615. definitions~\citep{Kelsey:1998di}. In the first pass we set up the
  6616. top-level environment using a mutable cons cell for each function
  6617. definition. Note that the \code{lambda} value for each function is
  6618. incomplete; it does not yet include the environment. Once the
  6619. top-level environment is constructed, we then iterate over it and
  6620. update the \code{lambda} values to use the top-level environment.
  6621. \begin{figure}[tp]
  6622. \begin{lstlisting}
  6623. (define interp-R4-class
  6624. (class interp-R3-class
  6625. (super-new)
  6626. (define/override ((interp-exp env) e)
  6627. (define recur (interp-exp env))
  6628. (match e
  6629. [(Var x) (unbox (dict-ref env x))]
  6630. [(Let x e body)
  6631. (define new-env (dict-set env x (box (recur e))))
  6632. ((interp-exp new-env) body)]
  6633. [(Apply fun args)
  6634. (define fun-val (recur fun))
  6635. (define arg-vals (for/list ([e args]) (recur e)))
  6636. (match fun-val
  6637. [`(function (,xs ...) ,body ,fun-env)
  6638. (define params-args (for/list ([x xs] [arg arg-vals])
  6639. (cons x (box arg))))
  6640. (define new-env (append params-args fun-env))
  6641. ((interp-exp new-env) body)]
  6642. [else (error 'interp-exp "expected function, not ~a" fun-val)])]
  6643. [else ((super interp-exp env) e)]
  6644. ))
  6645. (define/public (interp-def d)
  6646. (match d
  6647. [(Def f (list `[,xs : ,ps] ...) rt _ body)
  6648. (cons f (box `(function ,xs ,body ())))]))
  6649. (define/override (interp-program p)
  6650. (match p
  6651. [(ProgramDefsExp info ds body)
  6652. (let ([top-level (for/list ([d ds]) (interp-def d))])
  6653. (for/list ([f (in-dict-values top-level)])
  6654. (set-box! f (match (unbox f)
  6655. [`(function ,xs ,body ())
  6656. `(function ,xs ,body ,top-level)])))
  6657. ((interp-exp top-level) body))]))
  6658. ))
  6659. (define (interp-R4 p)
  6660. (send (new interp-R4-class) interp-program p))
  6661. \end{lstlisting}
  6662. \caption{Interpreter for the $R_4$ language.}
  6663. \label{fig:interp-R4}
  6664. \end{figure}
  6665. \margincomment{TODO: explain type checker}
  6666. The type checker for $R_4$ is is in Figure~\ref{fig:type-check-R4}.
  6667. \begin{figure}[tp]
  6668. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  6669. (define type-check-R4-class
  6670. (class type-check-R3-class
  6671. (super-new)
  6672. (inherit check-type-equal?)
  6673. (define/public (type-check-apply env e es)
  6674. (define-values (e^ ty) ((type-check-exp env) e))
  6675. (define-values (e* ty*) (for/lists (e* ty*) ([e (in-list es)])
  6676. ((type-check-exp env) e)))
  6677. (match ty
  6678. [`(,ty^* ... -> ,rt)
  6679. (for ([arg-ty ty*] [param-ty ty^*])
  6680. (check-type-equal? arg-ty param-ty (Apply e es)))
  6681. (values e^ e* rt)]))
  6682. (define/override (type-check-exp env)
  6683. (lambda (e)
  6684. (match e
  6685. [(FunRef f)
  6686. (values (FunRef f) (dict-ref env f))]
  6687. [(Apply e es)
  6688. (define-values (e^ es^ rt) (type-check-apply env e es))
  6689. (values (Apply e^ es^) rt)]
  6690. [(Call e es)
  6691. (define-values (e^ es^ rt) (type-check-apply env e es))
  6692. (values (Call e^ es^) rt)]
  6693. [else ((super type-check-exp env) e)])))
  6694. (define/public (type-check-def env)
  6695. (lambda (e)
  6696. (match e
  6697. [(Def f (and p:t* (list `[,xs : ,ps] ...)) rt info body)
  6698. (define new-env (append (map cons xs ps) env))
  6699. (define-values (body^ ty^) ((type-check-exp new-env) body))
  6700. (check-type-equal? ty^ rt body)
  6701. (Def f p:t* rt info body^)])))
  6702. (define/public (fun-def-type d)
  6703. (match d
  6704. [(Def f (list `[,xs : ,ps] ...) rt info body) `(,@ps -> ,rt)]))
  6705. (define/override (type-check-program e)
  6706. (match e
  6707. [(ProgramDefsExp info ds body)
  6708. (define new-env (for/list ([d ds])
  6709. (cons (Def-name d) (fun-def-type d))))
  6710. (define ds^ (for/list ([d ds]) ((type-check-def new-env) d)))
  6711. (define-values (body^ ty) ((type-check-exp new-env) body))
  6712. (check-type-equal? ty 'Integer body)
  6713. (ProgramDefsExp info ds^ body^)]))))
  6714. (define (type-check-R4 p)
  6715. (send (new type-check-R4-class) type-check-program p))
  6716. \end{lstlisting}
  6717. \caption{Type checker for the $R_4$ language.}
  6718. \label{fig:type-check-R4}
  6719. \end{figure}
  6720. \section{Functions in x86}
  6721. \label{sec:fun-x86}
  6722. \margincomment{\tiny Make sure callee-saved registers are discussed
  6723. in enough depth, especially updating Fig 6.4 \\ --Jeremy }
  6724. \margincomment{\tiny Talk about the return address on the
  6725. stack and what callq and retq does.\\ --Jeremy }
  6726. The x86 architecture provides a few features to support the
  6727. implementation of functions. We have already seen that x86 provides
  6728. labels so that one can refer to the location of an instruction, as is
  6729. needed for jump instructions. Labels can also be used to mark the
  6730. beginning of the instructions for a function. Going further, we can
  6731. obtain the address of a label by using the \key{leaq} instruction and
  6732. PC-relative addressing. For example, the following puts the
  6733. address of the \code{add1} label into the \code{rbx} register.
  6734. \begin{lstlisting}
  6735. leaq add1(%rip), %rbx
  6736. \end{lstlisting}
  6737. The instruction pointer register \key{rip} (aka. the program counter
  6738. \index{program counter}) always points to the next instruction to be
  6739. executed. When combined with an label, as in \code{add1(\%rip)}, the
  6740. linker computes the distance $d$ between the address of \code{add1}
  6741. and where the \code{rip} would be at that moment and then changes
  6742. \code{add1(\%rip)} to \code{$d$(\%rip)}, which at runtime will compute
  6743. the address of \code{add1}.
  6744. In Section~\ref{sec:x86} we used of the \code{callq} instruction to
  6745. jump to a function whose location is given by a label. To support
  6746. function calls in this chapter we instead will be jumping to a
  6747. function whose location is given by an address in a register, that is,
  6748. we need to make an \emph{indirect function call}. The x86 syntax for
  6749. this is a \code{callq} instruction but with an asterisk before the
  6750. register name.\index{indirect function call}
  6751. \begin{lstlisting}
  6752. callq *%rbx
  6753. \end{lstlisting}
  6754. \subsection{Calling Conventions}
  6755. \index{calling conventions}
  6756. The \code{callq} instruction provides partial support for implementing
  6757. functions: it pushes the return address on the stack and it jumps to
  6758. the target. However, \code{callq} does not handle
  6759. \begin{enumerate}
  6760. \item parameter passing,
  6761. \item pushing frames on the procedure call stack and popping them off,
  6762. or
  6763. \item determining how registers are shared by different functions.
  6764. \end{enumerate}
  6765. Regarding (1) parameter passing, recall that the following six
  6766. registers are used to pass arguments to a function, in this order.
  6767. \begin{lstlisting}
  6768. rdi rsi rdx rcx r8 r9
  6769. \end{lstlisting}
  6770. If there are
  6771. more than six arguments, then the convention is to use space on the
  6772. frame of the caller for the rest of the arguments. However, to ease
  6773. the implementation of efficient tail calls
  6774. (Section~\ref{sec:tail-call}), we arrange to never need more than six
  6775. arguments.
  6776. %
  6777. Also recall that the register \code{rax} is for the return value of
  6778. the function.
  6779. \index{prelude}\index{conclusion}
  6780. Regarding (2) frames \index{frame} and the procedure call stack,
  6781. \index{procedure call stack} recall from Section~\ref{sec:x86} that
  6782. the stack grows down, with each function call using a chunk of space
  6783. called a frame. The caller sets the stack pointer, register
  6784. \code{rsp}, to the last data item in its frame. The callee must not
  6785. change anything in the caller's frame, that is, anything that is at or
  6786. above the stack pointer. The callee is free to use locations that are
  6787. below the stack pointer.
  6788. Recall that we are storing variables of vector type on the root stack.
  6789. So the prelude needs to move the root stack pointer \code{r15} up and
  6790. the conclusion needs to move the root stack pointer back down. Also,
  6791. the prelude must initialize to \code{0} this frame's slots in the root
  6792. stack to signal to the garbage collector that those slots do not yet
  6793. contain a pointer to a vector. Otherwise the garbage collector will
  6794. interpret the garbage bits in those slots as memory addresses and try
  6795. to traverse them, causing serious mayhem!
  6796. Regarding (3) the sharing of registers between different functions,
  6797. recall from Section~\ref{sec:calling-conventions} that the registers
  6798. are divided into two groups, the caller-saved registers and the
  6799. callee-saved registers. The caller should assume that all the
  6800. caller-saved registers get overwritten with arbitrary values by the
  6801. callee. That is why we recommend in
  6802. Section~\ref{sec:calling-conventions} that variables that are live
  6803. during a function call should not be assigned to caller-saved
  6804. registers.
  6805. On the flip side, if the callee wants to use a callee-saved register,
  6806. the callee must save the contents of those registers on their stack
  6807. frame and then put them back prior to returning to the caller. That
  6808. is why we recommended in Section~\ref{sec:calling-conventions} that if
  6809. the register allocator assigns a variable to a callee-saved register,
  6810. then the prelude of the \code{main} function must save that register
  6811. to the stack and the conclusion of \code{main} must restore it. This
  6812. recommendation now generalizes to all functions.
  6813. Also recall that the base pointer, register \code{rbp}, is used as a
  6814. point-of-reference within a frame, so that each local variable can be
  6815. accessed at a fixed offset from the base pointer
  6816. (Section~\ref{sec:x86}).
  6817. %
  6818. Figure~\ref{fig:call-frames} shows the general layout of the caller
  6819. and callee frames.
  6820. \begin{figure}[tbp]
  6821. \centering
  6822. \begin{tabular}{r|r|l|l} \hline
  6823. Caller View & Callee View & Contents & Frame \\ \hline
  6824. 8(\key{\%rbp}) & & return address & \multirow{5}{*}{Caller}\\
  6825. 0(\key{\%rbp}) & & old \key{rbp} \\
  6826. -8(\key{\%rbp}) & & callee-saved $1$ \\
  6827. \ldots & & \ldots \\
  6828. $-8j$(\key{\%rbp}) & & callee-saved $j$ \\
  6829. $-8(j+1)$(\key{\%rbp}) & & local variable $1$ \\
  6830. \ldots & & \ldots \\
  6831. $-8(j+k)$(\key{\%rbp}) & & local variable $k$ \\
  6832. %% & & \\
  6833. %% $8n-8$\key{(\%rsp)} & $8n+8$(\key{\%rbp})& argument $n$ \\
  6834. %% & \ldots & \ldots \\
  6835. %% 0\key{(\%rsp)} & 16(\key{\%rbp}) & argument $1$ & \\
  6836. \hline
  6837. & 8(\key{\%rbp}) & return address & \multirow{5}{*}{Callee}\\
  6838. & 0(\key{\%rbp}) & old \key{rbp} \\
  6839. & -8(\key{\%rbp}) & callee-saved $1$ \\
  6840. & \ldots & \ldots \\
  6841. & $-8n$(\key{\%rbp}) & callee-saved $n$ \\
  6842. & $-8(n+1)$(\key{\%rbp}) & local variable $1$ \\
  6843. & \ldots & \ldots \\
  6844. & $-8(n+m)$(\key{\%rsp}) & local variable $m$\\ \hline
  6845. \end{tabular}
  6846. \caption{Memory layout of caller and callee frames.}
  6847. \label{fig:call-frames}
  6848. \end{figure}
  6849. %% Recall from Section~\ref{sec:x86} that the stack is also used for
  6850. %% local variables and for storing the values of callee-saved registers
  6851. %% (we shall refer to all of these collectively as ``locals''), and that
  6852. %% at the beginning of a function we move the stack pointer \code{rsp}
  6853. %% down to make room for them.
  6854. %% We recommend storing the local variables
  6855. %% first and then the callee-saved registers, so that the local variables
  6856. %% can be accessed using \code{rbp} the same as before the addition of
  6857. %% functions.
  6858. %% To make additional room for passing arguments, we shall
  6859. %% move the stack pointer even further down. We count how many stack
  6860. %% arguments are needed for each function call that occurs inside the
  6861. %% body of the function and find their maximum. Adding this number to the
  6862. %% number of locals gives us how much the \code{rsp} should be moved at
  6863. %% the beginning of the function. In preparation for a function call, we
  6864. %% offset from \code{rsp} to set up the stack arguments. We put the first
  6865. %% stack argument in \code{0(\%rsp)}, the second in \code{8(\%rsp)}, and
  6866. %% so on.
  6867. %% Upon calling the function, the stack arguments are retrieved by the
  6868. %% callee using the base pointer \code{rbp}. The address \code{16(\%rbp)}
  6869. %% is the location of the first stack argument, \code{24(\%rbp)} is the
  6870. %% address of the second, and so on. Figure~\ref{fig:call-frames} shows
  6871. %% the layout of the caller and callee frames. Notice how important it is
  6872. %% that we correctly compute the maximum number of arguments needed for
  6873. %% function calls; if that number is too small then the arguments and
  6874. %% local variables will smash into each other!
  6875. \subsection{Efficient Tail Calls}
  6876. \label{sec:tail-call}
  6877. In general, the amount of stack space used by a program is determined
  6878. by the longest chain of nested function calls. That is, if function
  6879. $f_1$ calls $f_2$, $f_2$ calls $f_3$, $\ldots$, and $f_{n-1}$ calls
  6880. $f_n$, then the amount of stack space is bounded by $O(n)$. The depth
  6881. $n$ can grow quite large in the case of recursive or mutually
  6882. recursive functions. However, in some cases we can arrange to use only
  6883. constant space, i.e. $O(1)$, instead of $O(n)$.
  6884. If a function call is the last action in a function body, then that
  6885. call is said to be a \emph{tail call}\index{tail call}.
  6886. For example, in the following
  6887. program, the recursive call to \code{tail-sum} is a tail call.
  6888. \begin{center}
  6889. \begin{lstlisting}
  6890. (define (tail-sum [n : Integer] [r : Integer]) : Integer
  6891. (if (eq? n 0)
  6892. r
  6893. (tail-sum (- n 1) (+ n r))))
  6894. (+ (tail-sum 5 0) 27)
  6895. \end{lstlisting}
  6896. \end{center}
  6897. At a tail call, the frame of the caller is no longer needed, so we
  6898. can pop the caller's frame before making the tail call. With this
  6899. approach, a recursive function that only makes tail calls will only
  6900. use $O(1)$ stack space. Functional languages like Racket typically
  6901. rely heavily on recursive functions, so they typically guarantee that
  6902. all tail calls will be optimized in this way.
  6903. \index{frame}
  6904. However, some care is needed with regards to argument passing in tail
  6905. calls. As mentioned above, for arguments beyond the sixth, the
  6906. convention is to use space in the caller's frame for passing
  6907. arguments. But for a tail call we pop the caller's frame and can no
  6908. longer use it. Another alternative is to use space in the callee's
  6909. frame for passing arguments. However, this option is also problematic
  6910. because the caller and callee's frame overlap in memory. As we begin
  6911. to copy the arguments from their sources in the caller's frame, the
  6912. target locations in the callee's frame might overlap with the sources
  6913. for later arguments! We solve this problem by not using the stack for
  6914. passing more than six arguments but instead using the heap, as we
  6915. describe in the Section~\ref{sec:limit-functions-r4}.
  6916. As mentioned above, for a tail call we pop the caller's frame prior to
  6917. making the tail call. The instructions for popping a frame are the
  6918. instructions that we usually place in the conclusion of a
  6919. function. Thus, we also need to place such code immediately before
  6920. each tail call. These instructions include restoring the callee-saved
  6921. registers, so it is good that the argument passing registers are all
  6922. caller-saved registers.
  6923. One last note regarding which instruction to use to make the tail
  6924. call. When the callee is finished, it should not return to the current
  6925. function, but it should return to the function that called the current
  6926. one. Thus, the return address that is already on the stack is the
  6927. right one, and we should not use \key{callq} to make the tail call, as
  6928. that would unnecessarily overwrite the return address. Instead we can
  6929. simply use the \key{jmp} instruction. Like the indirect function call,
  6930. we write an \emph{indirect jump}\index{indirect jump} with a register
  6931. prefixed with an asterisk. We recommend using \code{rax} to hold the
  6932. jump target because the preceding conclusion overwrites just about
  6933. everything else.
  6934. \begin{lstlisting}
  6935. jmp *%rax
  6936. \end{lstlisting}
  6937. \section{Shrink $R_4$}
  6938. \label{sec:shrink-r4}
  6939. The \code{shrink} pass performs a minor modification to ease the
  6940. later passes. This pass introduces an explicit \code{main} function
  6941. and changes the top \code{ProgramDefsExp} form to
  6942. \code{ProgramDefs} as follows.
  6943. \begin{lstlisting}
  6944. (ProgramDefsExp |$\itm{info}$| (|$\Def\ldots$|) |$\Exp$|)
  6945. |$\Rightarrow$| (ProgramDefs |$\itm{info}$| (|$\Def\ldots$| |$\itm{mainDef}$|))
  6946. \end{lstlisting}
  6947. where $\itm{mainDef}$ is
  6948. \begin{lstlisting}
  6949. (Def 'main '() 'Integer '() |$\Exp'$|)
  6950. \end{lstlisting}
  6951. \section{Reveal Functions and the $F_1$ language}
  6952. \label{sec:reveal-functions-r4}
  6953. The syntax of $R_4$ is inconvenient for purposes of compilation in one
  6954. respect: it conflates the use of function names and local
  6955. variables. This is a problem because we need to compile the use of a
  6956. function name differently than the use of a local variable; we need to
  6957. use \code{leaq} to convert the function name (a label in x86) to an
  6958. address in a register. Thus, it is a good idea to create a new pass
  6959. that changes function references from just a symbol $f$ to
  6960. $\FUNREF{f}$. This pass is named \code{reveal-functions} and the
  6961. output language, $F_1$, is defined in Figure~\ref{fig:f1-syntax}.
  6962. The concrete syntax for a function reference is $\CFUNREF{f}$.
  6963. \begin{figure}[tp]
  6964. \centering
  6965. \fbox{
  6966. \begin{minipage}{0.96\textwidth}
  6967. \[
  6968. \begin{array}{lcl}
  6969. \Exp &::=& \ldots \mid \FUNREF{\Var}\\
  6970. \Def &::=& \gray{ \FUNDEF{\Var}{([\Var \code{:} \Type]\ldots)}{\Type}{\code{'()}}{\Exp} }\\
  6971. F_1 &::=& \PROGRAMDEFS{\code{'()}}{\LP \Def\ldots \RP}
  6972. \end{array}
  6973. \]
  6974. \end{minipage}
  6975. }
  6976. \caption{The abstract syntax $F_1$, an extension of $R_4$
  6977. (Figure~\ref{fig:r4-syntax}).}
  6978. \label{fig:f1-syntax}
  6979. \end{figure}
  6980. % TODO: rename $F_1$ to $R'_4$
  6981. %% Distinguishing between calls in tail position and non-tail position
  6982. %% requires the pass to have some notion of context. We recommend using
  6983. %% two mutually recursive functions, one for processing expressions in
  6984. %% tail position and another for the rest.
  6985. Placing this pass after \code{uniquify} will make sure that there are
  6986. no local variables and functions that share the same name. On the
  6987. other hand, \code{reveal-functions} needs to come before the
  6988. \code{explicate-control} pass because that pass helps us compile
  6989. \code{FunRef} forms into assignment statements.
  6990. \section{Limit Functions}
  6991. \label{sec:limit-functions-r4}
  6992. Recall that we wish to limit the number of function parameters to six
  6993. so that we do not need to use the stack for argument passing, which
  6994. makes it easier to implement efficient tail calls. However, because
  6995. the input language $R_4$ supports arbitrary numbers of function
  6996. arguments, we have some work to do!
  6997. This pass transforms functions and function calls that involve more
  6998. than six arguments to pass the first five arguments as usual, but it
  6999. packs the rest of the arguments into a vector and passes it as the
  7000. sixth argument.
  7001. Each function definition with too many parameters is transformed as
  7002. follows.
  7003. \begin{lstlisting}
  7004. (Def |$f$| ([|$x_1$|:|$T_1$|] |$\ldots$| [|$x_n$|:|$T_n$|]) |$T_r$| |$\itm{info}$| |$\itm{body}$|)
  7005. |$\Rightarrow$|
  7006. (Def |$f$| ([|$x_1$|:|$T_1$|] |$\ldots$| [|$x_5$|:|$T_5$|] [vec : (Vector |$T_6 \ldots T_n$|)]) |$T_r$| |$\itm{info}$| |$\itm{body}'$|)
  7007. \end{lstlisting}
  7008. where the $\itm{body}$ is transformed into $\itm{body}'$ by replacing
  7009. the occurrences of the later parameters with vector references.
  7010. \begin{lstlisting}
  7011. (Var |$x_i$|) |$\Rightarrow$| (Prim 'vector-ref (list vec (Int |$(i - 6)$|)))
  7012. \end{lstlisting}
  7013. For function calls with too many arguments, the \code{limit-functions}
  7014. pass transforms them in the following way.
  7015. \begin{tabular}{lll}
  7016. \begin{minipage}{0.2\textwidth}
  7017. \begin{lstlisting}
  7018. (|$e_0$| |$e_1$| |$\ldots$| |$e_n$|)
  7019. \end{lstlisting}
  7020. \end{minipage}
  7021. &
  7022. $\Rightarrow$
  7023. &
  7024. \begin{minipage}{0.4\textwidth}
  7025. \begin{lstlisting}
  7026. (|$e_0$| |$e_1 \ldots e_5$| (vector |$e_6 \ldots e_n$|))
  7027. \end{lstlisting}
  7028. \end{minipage}
  7029. \end{tabular}
  7030. \section{Remove Complex Operands}
  7031. \label{sec:rco-r4}
  7032. The primary decisions to make for this pass is whether to classify
  7033. \code{FunRef} and \code{Apply} as either atomic or complex
  7034. expressions. Recall that a simple expression will eventually end up as
  7035. just an immediate argument of an x86 instruction. Function
  7036. application will be translated to a sequence of instructions, so
  7037. \code{Apply} must be classified as complex expression.
  7038. On the other hand, the arguments of \code{Apply} should be
  7039. atomic expressions.
  7040. %
  7041. Regarding \code{FunRef}, as discussed above, the function label needs
  7042. to be converted to an address using the \code{leaq} instruction. Thus,
  7043. even though \code{FunRef} seems rather simple, it needs to be
  7044. classified as a complex expression so that we generate an assignment
  7045. statement with a left-hand side that can serve as the target of the
  7046. \code{leaq}. Figure~\ref{fig:r4-anf-syntax} defines the
  7047. output language $R_4^{\dagger}$ of this pass.
  7048. \begin{figure}[tp]
  7049. \centering
  7050. \fbox{
  7051. \begin{minipage}{0.96\textwidth}
  7052. \small
  7053. \[
  7054. \begin{array}{rcl}
  7055. \Atm &::=& \gray{ \INT{\Int} \mid \VAR{\Var} \mid \BOOL{\itm{bool}}
  7056. \mid \VOID{} } \\
  7057. \Exp &::=& \gray{ \Atm \mid \READ{} } \\
  7058. &\mid& \gray{ \NEG{\Atm} \mid \ADD{\Atm}{\Atm} } \\
  7059. &\mid& \gray{ \LET{\Var}{\Exp}{\Exp} } \\
  7060. &\mid& \gray{ \UNIOP{\key{'not}}{\Atm} } \\
  7061. &\mid& \gray{ \BINOP{\itm{cmp}}{\Atm}{\Atm} \mid \IF{\Exp}{\Exp}{\Exp} }\\
  7062. &\mid& \gray{ \LP\key{Collect}~\Int\RP \mid \LP\key{Allocate}~\Int~\Type\RP
  7063. \mid \LP\key{GlobalValue}~\Var\RP }\\
  7064. &\mid& \FUNREF{\Var} \mid \APPLY{\Atm}{\Atm\ldots}\\
  7065. \Def &::=& \gray{ \FUNDEF{\Var}{([\Var \code{:} \Type]\ldots)}{\Type}{\code{'()}}{\Exp} }\\
  7066. R^{\dagger}_4 &::=& \gray{ \PROGRAMDEFS{\code{'()}}{\Def} }
  7067. \end{array}
  7068. \]
  7069. \end{minipage}
  7070. }
  7071. \caption{$R_4^{\dagger}$ is $R_4$ in administrative normal form (ANF).}
  7072. \label{fig:r4-anf-syntax}
  7073. \end{figure}
  7074. \section{Explicate Control and the $C_3$ language}
  7075. \label{sec:explicate-control-r4}
  7076. Figure~\ref{fig:c3-syntax} defines the abstract syntax for $C_3$, the
  7077. output of \key{explicate-control}. (The concrete syntax is given in
  7078. Figure~\ref{fig:c3-concrete-syntax} of the Appendix.) The auxiliary
  7079. functions for assignment and tail contexts should be updated with
  7080. cases for \code{Apply} and \code{FunRef} and the function for
  7081. predicate context should be updated for \code{Apply} but not
  7082. \code{FunRef}. (A \code{FunRef} can't be a Boolean.) In assignment
  7083. and predicate contexts, \code{Apply} becomes \code{Call}, whereas in
  7084. tail position \code{Apply} becomes \code{TailCall}. We recommend
  7085. defining a new auxiliary function for processing function definitions.
  7086. This code is similar to the case for \code{Program} in $R_3$. The
  7087. top-level \code{explicate-control} function that handles the
  7088. \code{ProgramDefs} form of $R_4$ can then apply this new function to
  7089. all the function definitions.
  7090. \begin{figure}[tp]
  7091. \fbox{
  7092. \begin{minipage}{0.96\textwidth}
  7093. \small
  7094. \[
  7095. \begin{array}{lcl}
  7096. \Atm &::=& \gray{ \INT{\Int} \mid \VAR{\Var} \mid \BOOL{\itm{bool}} }\\
  7097. \itm{cmp} &::= & \gray{ \key{eq?} \mid \key{<} } \\
  7098. \Exp &::= & \gray{ \Atm \mid \READ{} } \\
  7099. &\mid& \gray{ \NEG{\Atm} \mid \ADD{\Atm}{\Atm} }\\
  7100. &\mid& \gray{ \UNIOP{\key{not}}{\Atm} \mid \BINOP{\itm{cmp}}{\Atm}{\Atm} } \\
  7101. &\mid& \gray{ \LP\key{Allocate} \,\itm{int}\,\itm{type}\RP } \\
  7102. &\mid& \gray{ \BINOP{\key{'vector-ref}}{\Atm}{\INT{\Int}} }\\
  7103. &\mid& \gray{ \LP\key{Prim}~\key{'vector-set!}\,\LP\key{list}\,\Atm\,\INT{\Int}\,\Atm\RP\RP }\\
  7104. &\mid& \gray{ \LP\key{GlobalValue} \,\Var\RP \mid \LP\key{Void}\RP }\\
  7105. &\mid& \FUNREF{\itm{label}} \mid \CALL{\Atm}{\LP\Atm\ldots\RP} \\
  7106. \Stmt &::=& \gray{ \ASSIGN{\VAR{\Var}}{\Exp}
  7107. \mid \LP\key{Collect} \,\itm{int}\RP } \\
  7108. \Tail &::= & \gray{ \RETURN{\Exp} \mid \SEQ{\Stmt}{\Tail}
  7109. \mid \GOTO{\itm{label}} } \\
  7110. &\mid& \gray{ \IFSTMT{\BINOP{\itm{cmp}}{\Atm}{\Atm}}{\GOTO{\itm{label}}}{\GOTO{\itm{label}}} }\\
  7111. &\mid& \TAILCALL{\Atm}{\Atm\ldots} \\
  7112. \Def &::=& \DEF{\itm{label}}{\LP[\Var\key{:}\Type]\ldots\RP}{\Type}{\itm{info}}{\LP\LP\itm{label}\,\key{.}\,\Tail\RP\ldots\RP}\\
  7113. C_3 & ::= & \PROGRAMDEFS{\itm{info}}{\LP\Def\ldots\RP}
  7114. \end{array}
  7115. \]
  7116. \end{minipage}
  7117. }
  7118. \caption{The abstract syntax of $C_3$, extending $C_2$ (Figure~\ref{fig:c2-syntax}).}
  7119. \label{fig:c3-syntax}
  7120. \end{figure}
  7121. \section{Select Instructions and the x86$_3$ Language}
  7122. \label{sec:select-r4}
  7123. \index{instruction selection}
  7124. The output of select instructions is a program in the x86$_3$
  7125. language, whose syntax is defined in Figure~\ref{fig:x86-3}.
  7126. \index{x86}
  7127. \begin{figure}[tp]
  7128. \fbox{
  7129. \begin{minipage}{0.96\textwidth}
  7130. \small
  7131. \[
  7132. \begin{array}{lcl}
  7133. \Arg &::=& \gray{ \key{\$}\Int \mid \key{\%}\Reg \mid \Int\key{(}\key{\%}\Reg\key{)} \mid \key{\%}\itm{bytereg} } \mid \Var \key{(\%rip)}
  7134. \mid \LP\key{fun-ref}\; \itm{label}\RP\\
  7135. \itm{cc} & ::= & \gray{ \key{e} \mid \key{l} \mid \key{le} \mid \key{g} \mid \key{ge} } \\
  7136. \Instr &::=& \ldots
  7137. \mid \key{callq}\;\key{*}\Arg \mid \key{tailjmp}\;\Arg
  7138. \mid \key{leaq}\;\Arg\key{,}\;\key{\%}\Reg \\
  7139. \Block &::= & \Instr\ldots \\
  7140. \Def &::= & \LP\key{define} \; \LP\itm{label}\RP \;\LP\LP\itm{label} \,\key{.}\, \Block\RP\ldots\RP\RP\\
  7141. x86_3 &::= & \Def\ldots
  7142. \end{array}
  7143. \]
  7144. \end{minipage}
  7145. }
  7146. \caption{The concrete syntax of x86$_3$ (extends x86$_2$ of Figure~\ref{fig:x86-2-concrete}).}
  7147. \label{fig:x86-3-concrete}
  7148. \end{figure}
  7149. \begin{figure}[tp]
  7150. \fbox{
  7151. \begin{minipage}{0.96\textwidth}
  7152. \small
  7153. \[
  7154. \begin{array}{lcl}
  7155. \Arg &::=& \gray{ \INT{\Int} \mid \REG{\Reg} \mid \DEREF{\Reg}{\Int}
  7156. \mid \BYTEREG{\Reg} } \\
  7157. &\mid& \gray{ (\key{Global}~\Var) } \mid \FUNREF{\itm{label}} \\
  7158. \Instr &::=& \ldots \mid \INDCALLQ{\Arg}{\itm{int}}
  7159. \mid \TAILJMP{\Arg}{\itm{int}}\\
  7160. &\mid& \BININSTR{\code{'leaq}}{\Arg}{\REG{\Reg}}\\
  7161. \Block &::= & \BLOCK{\itm{info}}{\LP\Instr\ldots\RP}\\
  7162. \Def &::= & \DEF{\itm{label}}{\code{'()}}{\Type}{\itm{info}}{\LP\LP\itm{label}\,\key{.}\,\Block\RP\ldots\RP} \\
  7163. x86_3 &::= & \PROGRAMDEFS{\itm{info}}{\LP\Def\ldots\RP}
  7164. \end{array}
  7165. \]
  7166. \end{minipage}
  7167. }
  7168. \caption{The abstract syntax of x86$_3$ (extends x86$_2$ of Figure~\ref{fig:x86-2}).}
  7169. \label{fig:x86-3}
  7170. \end{figure}
  7171. An assignment of a function reference to a variable becomes a
  7172. load-effective-address instruction as follows: \\
  7173. \begin{tabular}{lcl}
  7174. \begin{minipage}{0.35\textwidth}
  7175. \begin{lstlisting}
  7176. |$\itm{lhs}$| = (fun-ref |$f$|);
  7177. \end{lstlisting}
  7178. \end{minipage}
  7179. &
  7180. $\Rightarrow$\qquad\qquad
  7181. &
  7182. \begin{minipage}{0.3\textwidth}
  7183. \begin{lstlisting}
  7184. leaq (fun-ref |$f$|), |$\itm{lhs}'$|
  7185. \end{lstlisting}
  7186. \end{minipage}
  7187. \end{tabular} \\
  7188. Regarding function definitions, we need to remove the parameters and
  7189. instead perform parameter passing using the conventions discussed in
  7190. Section~\ref{sec:fun-x86}. That is, the arguments are passed in
  7191. registers. We recommend turning the parameters into local variables
  7192. and generating instructions at the beginning of the function to move
  7193. from the argument passing registers to these local variables.
  7194. \begin{lstlisting}
  7195. (Def |$f$| '([|$x_1$| : |$T_1$|] [|$x_2$| : |$T_2$|] |$\ldots$| ) |$T_r$| |$\itm{info}$| |$G$|)
  7196. |$\Rightarrow$|
  7197. (Def |$f$| '() 'Integer |$\itm{info}'$| |$G'$|)
  7198. \end{lstlisting}
  7199. The $G'$ control-flow graph is the same as $G$ except that the
  7200. \code{start} block is modified to add the instructions for moving from
  7201. the argument registers to the parameter variables. So the \code{start}
  7202. block of $G$ shown on the left is changed to the code on the right.
  7203. \begin{center}
  7204. \begin{minipage}{0.3\textwidth}
  7205. \begin{lstlisting}
  7206. start:
  7207. |$\itm{instr}_1$|
  7208. |$\vdots$|
  7209. |$\itm{instr}_n$|
  7210. \end{lstlisting}
  7211. \end{minipage}
  7212. $\Rightarrow$
  7213. \begin{minipage}{0.3\textwidth}
  7214. \begin{lstlisting}
  7215. start:
  7216. movq %rdi, |$x_1$|
  7217. movq %rsi, |$x_2$|
  7218. |$\vdots$|
  7219. |$\itm{instr}_1$|
  7220. |$\vdots$|
  7221. |$\itm{instr}_n$|
  7222. \end{lstlisting}
  7223. \end{minipage}
  7224. \end{center}
  7225. By changing the parameters to local variables, we are giving the
  7226. register allocator control over which registers or stack locations to
  7227. use for them. If you implemented the move-biasing challenge
  7228. (Section~\ref{sec:move-biasing}), the register allocator will try to
  7229. assign the parameter variables to the corresponding argument register,
  7230. in which case the \code{patch-instructions} pass will remove the
  7231. \code{movq} instruction. This happens in the example translation in
  7232. Figure~\ref{fig:add-fun} of Section~\ref{sec:functions-example}, in
  7233. the \code{add} function.
  7234. %
  7235. Also, note that the register allocator will perform liveness analysis
  7236. on this sequence of move instructions and build the interference
  7237. graph. So, for example, $x_1$ will be marked as interfering with
  7238. \code{rsi} and that will prevent the assignment of $x_1$ to
  7239. \code{rsi}, which is good, because that would overwrite the argument
  7240. that needs to move into $x_2$.
  7241. Next, consider the compilation of function calls. In the mirror image
  7242. of handling the parameters of function definitions, the arguments need
  7243. to be moved to the argument passing registers. The function call
  7244. itself is performed with an indirect function call. The return value
  7245. from the function is stored in \code{rax}, so it needs to be moved
  7246. into the \itm{lhs}.
  7247. \begin{lstlisting}
  7248. |\itm{lhs}| = (call |\itm{fun}| |$\itm{arg}_1~\itm{arg}_2\ldots$|));
  7249. |$\Rightarrow$|
  7250. movq |$\itm{arg}_1$|, %rdi
  7251. movq |$\itm{arg}_2$|, %rsi
  7252. |$\vdots$|
  7253. callq *|\itm{fun}|
  7254. movq %rax, |\itm{lhs}|
  7255. \end{lstlisting}
  7256. The \code{IndirectCallq} AST node includes an integer for the arity of
  7257. the function, i.e., the number of parameters. That information is
  7258. useful in the \code{uncover-live} pass for determining which
  7259. argument-passing registers are potentially read during the call.
  7260. For tail calls, the parameter passing is the same as non-tail calls:
  7261. generate instructions to move the arguments into to the argument
  7262. passing registers. After that we need to pop the frame from the
  7263. procedure call stack. However, we do not yet know how big the frame
  7264. is; that gets determined during register allocation. So instead of
  7265. generating those instructions here, we invent a new instruction that
  7266. means ``pop the frame and then do an indirect jump'', which we name
  7267. \code{TailJmp}. The abstract syntax for this instruction includes an
  7268. argument that specifies where to jump and an integer that represents
  7269. the arity of the function being called.
  7270. Recall that in Section~\ref{sec:explicate-control-r1} we recommended
  7271. using the label \code{start} for the initial block of a program, and
  7272. in Section~\ref{sec:select-r1} we recommended labeling the conclusion
  7273. of the program with \code{conclusion}, so that $(\key{Return}\;\Arg)$
  7274. can be compiled to an assignment to \code{rax} followed by a jump to
  7275. \code{conclusion}. With the addition of function definitions, we will
  7276. have a starting block and conclusion for each function, but their
  7277. labels need to be unique. We recommend prepending the function's name
  7278. to \code{start} and \code{conclusion}, respectively, to obtain unique
  7279. labels. (Alternatively, one could \code{gensym} labels for the start
  7280. and conclusion and store them in the $\itm{info}$ field of the
  7281. function definition.)
  7282. \section{Register Allocation}
  7283. \label{sec:register-allocation-r4}
  7284. \subsection{Liveness Analysis}
  7285. \label{sec:liveness-analysis-r4}
  7286. \index{liveness analysis}
  7287. %% The rest of the passes need only minor modifications to handle the new
  7288. %% kinds of AST nodes: \code{fun-ref}, \code{indirect-callq}, and
  7289. %% \code{leaq}.
  7290. The \code{IndirectCallq} instruction should be treated like
  7291. \code{Callq} regarding its written locations $W$, in that they should
  7292. include all the caller-saved registers. Recall that the reason for
  7293. that is to force call-live variables to be assigned to callee-saved
  7294. registers or to be spilled to the stack.
  7295. Regarding the set of read locations $R$ the arity field of
  7296. \code{TailJmp} and \code{IndirectCallq} determines how many of the
  7297. argument-passing registers should be considered as read by those
  7298. instructions.
  7299. \subsection{Build Interference Graph}
  7300. \label{sec:build-interference-r4}
  7301. With the addition of function definitions, we compute an interference
  7302. graph for each function (not just one for the whole program).
  7303. Recall that in Section~\ref{sec:reg-alloc-gc} we discussed the need to
  7304. spill vector-typed variables that are live during a call to the
  7305. \code{collect}. With the addition of functions to our language, we
  7306. need to revisit this issue. Many functions perform allocation and
  7307. therefore have calls to the collector inside of them. Thus, we should
  7308. not only spill a vector-typed variable when it is live during a call
  7309. to \code{collect}, but we should spill the variable if it is live
  7310. during any function call. Thus, in the \code{build-interference} pass,
  7311. we recommend adding interference edges between call-live vector-typed
  7312. variables and the callee-saved registers (in addition to the usual
  7313. addition of edges between call-live variables and the caller-saved
  7314. registers).
  7315. \subsection{Allocate Registers}
  7316. The primary change to the \code{allocate-registers} pass is adding an
  7317. auxiliary function for handling definitions (the \Def{} non-terminal
  7318. in Figure~\ref{fig:x86-3}) with one case for function definitions. The
  7319. logic is the same as described in
  7320. Chapter~\ref{ch:register-allocation-r1}, except now register
  7321. allocation is performed many times, once for each function definition,
  7322. instead of just once for the whole program.
  7323. \section{Patch Instructions}
  7324. In \code{patch-instructions}, you should deal with the x86
  7325. idiosyncrasy that the destination argument of \code{leaq} must be a
  7326. register. Additionally, you should ensure that the argument of
  7327. \code{TailJmp} is \itm{rax}, our reserved register---this is to make
  7328. code generation more convenient, because we trample many registers
  7329. before the tail call (as explained in the next section).
  7330. \section{Print x86}
  7331. For the \code{print-x86} pass, the cases for \code{FunRef} and
  7332. \code{IndirectCallq} are straightforward: output their concrete
  7333. syntax.
  7334. \begin{lstlisting}
  7335. (FunRef |\itm{label}|) |$\Rightarrow$| |\itm{label}|(%rip)
  7336. (IndirectCallq |\itm{arg}| |\itm{int}|) |$\Rightarrow$| callq *|\itm{arg}'|
  7337. \end{lstlisting}
  7338. The \code{TailJmp} node requires a bit work. A straightforward
  7339. translation of \code{TailJmp} would be \code{jmp *$\itm{arg}$}, but
  7340. before the jump we need to pop the current frame. This sequence of
  7341. instructions is the same as the code for the conclusion of a function,
  7342. except the \code{retq} is replaced with \code{jmp *$\itm{arg}$}.
  7343. Regarding function definitions, you will need to generate a prelude
  7344. and conclusion for each one. This code is similar to the prelude and
  7345. conclusion that you generated for the \code{main} function in
  7346. Chapter~\ref{ch:tuples}. To review, the prelude of every function
  7347. should carry out the following steps.
  7348. \begin{enumerate}
  7349. \item Start with \code{.global} and \code{.align} directives followed
  7350. by the label for the function. (See Figure~\ref{fig:add-fun} for an
  7351. example.)
  7352. \item Push \code{rbp} to the stack and set \code{rbp} to current stack
  7353. pointer.
  7354. \item Push to the stack all of the callee-saved registers that were
  7355. used for register allocation.
  7356. \item Move the stack pointer \code{rsp} down by the size of the stack
  7357. frame for this function, which depends on the number of regular
  7358. spills. (Aligned to 16 bytes.)
  7359. \item Move the root stack pointer \code{r15} up by the size of the
  7360. root-stack frame for this function, which depends on the number of
  7361. spilled vectors. \label{root-stack-init}
  7362. \item Initialize to zero all of the entries in the root-stack frame.
  7363. \item Jump to the start block.
  7364. \end{enumerate}
  7365. The prelude of the \code{main} function has one additional task: call
  7366. the \code{initialize} function to set up the garbage collector and
  7367. move the value of the global \code{rootstack\_begin} in
  7368. \code{r15}. This should happen before step \ref{root-stack-init}
  7369. above, which depends on \code{r15}.
  7370. The conclusion of every function should do the following.
  7371. \begin{enumerate}
  7372. \item Move the stack pointer back up by the size of the stack frame
  7373. for this function.
  7374. \item Restore the callee-saved registers by popping them from the
  7375. stack.
  7376. \item Move the root stack pointer back down by the size of the
  7377. root-stack frame for this function.
  7378. \item Restore \code{rbp} by popping it from the stack.
  7379. \item Return to the caller with the \code{retq} instruction.
  7380. \end{enumerate}
  7381. \begin{exercise}\normalfont
  7382. Expand your compiler to handle $R_4$ as outlined in this chapter.
  7383. Create 5 new programs that use functions, including examples that pass
  7384. functions and return functions from other functions, recursive
  7385. functions, functions that create vectors, and functions that make tail
  7386. calls. Test your compiler on these new programs and all of your
  7387. previously created test programs.
  7388. \end{exercise}
  7389. \begin{figure}[tbp]
  7390. \begin{tikzpicture}[baseline=(current bounding box.center)]
  7391. \node (R4) at (0,2) {\large $R_4$};
  7392. \node (R4-1) at (3,2) {\large $R_4$};
  7393. \node (R4-2) at (6,2) {\large $R_4$};
  7394. \node (F1-1) at (12,0) {\large $F_1$};
  7395. \node (F1-2) at (9,0) {\large $F_1$};
  7396. \node (F1-3) at (6,0) {\large $F_1$};
  7397. \node (F1-4) at (3,0) {\large $F_1$};
  7398. \node (C3-2) at (3,-2) {\large $C_3$};
  7399. \node (x86-2) at (3,-4) {\large $\text{x86}^{*}_3$};
  7400. \node (x86-3) at (6,-4) {\large $\text{x86}^{*}_3$};
  7401. \node (x86-4) at (9,-4) {\large $\text{x86}_3$};
  7402. \node (x86-5) at (9,-6) {\large $\text{x86}^{\dagger}_3$};
  7403. \node (x86-2-1) at (3,-6) {\large $\text{x86}^{*}_3$};
  7404. \node (x86-2-2) at (6,-6) {\large $\text{x86}^{*}_3$};
  7405. \path[->,bend left=15] (R4) edge [above] node
  7406. {\ttfamily\footnotesize shrink} (R4-1);
  7407. \path[->,bend left=15] (R4-1) edge [above] node
  7408. {\ttfamily\footnotesize uniquify} (R4-2);
  7409. \path[->,bend left=15] (R4-2) edge [right] node
  7410. {\ttfamily\footnotesize ~~reveal-functions} (F1-1);
  7411. \path[->,bend left=15] (F1-1) edge [below] node
  7412. {\ttfamily\footnotesize limit-functions} (F1-2);
  7413. \path[->,bend right=15] (F1-2) edge [above] node
  7414. {\ttfamily\footnotesize expose-alloc.} (F1-3);
  7415. \path[->,bend right=15] (F1-3) edge [above] node
  7416. {\ttfamily\footnotesize remove-complex.} (F1-4);
  7417. \path[->,bend left=15] (F1-4) edge [right] node
  7418. {\ttfamily\footnotesize explicate-control} (C3-2);
  7419. \path[->,bend right=15] (C3-2) edge [left] node
  7420. {\ttfamily\footnotesize select-instr.} (x86-2);
  7421. \path[->,bend left=15] (x86-2) edge [left] node
  7422. {\ttfamily\footnotesize uncover-live} (x86-2-1);
  7423. \path[->,bend right=15] (x86-2-1) edge [below] node
  7424. {\ttfamily\footnotesize build-inter.} (x86-2-2);
  7425. \path[->,bend right=15] (x86-2-2) edge [left] node
  7426. {\ttfamily\footnotesize allocate-reg.} (x86-3);
  7427. \path[->,bend left=15] (x86-3) edge [above] node
  7428. {\ttfamily\footnotesize patch-instr.} (x86-4);
  7429. \path[->,bend right=15] (x86-4) edge [left] node {\ttfamily\footnotesize print-x86} (x86-5);
  7430. \end{tikzpicture}
  7431. \caption{Diagram of the passes for $R_4$, a language with functions.}
  7432. \label{fig:R4-passes}
  7433. \end{figure}
  7434. Figure~\ref{fig:R4-passes} gives an overview of the passes for
  7435. compiling $R_4$ to x86.
  7436. \section{An Example Translation}
  7437. \label{sec:functions-example}
  7438. Figure~\ref{fig:add-fun} shows an example translation of a simple
  7439. function in $R_4$ to x86. The figure also includes the results of the
  7440. \code{explicate-control} and \code{select-instructions} passes.
  7441. \begin{figure}[htbp]
  7442. \begin{tabular}{ll}
  7443. \begin{minipage}{0.5\textwidth}
  7444. % s3_2.rkt
  7445. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  7446. (define (add [x : Integer] [y : Integer])
  7447. : Integer
  7448. (+ x y))
  7449. (add 40 2)
  7450. \end{lstlisting}
  7451. $\Downarrow$
  7452. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  7453. (define (add86 [x87 : Integer]
  7454. [y88 : Integer]) : Integer
  7455. add86start:
  7456. return (+ x87 y88);
  7457. )
  7458. (define (main) : Integer ()
  7459. mainstart:
  7460. tmp89 = (fun-ref add86);
  7461. (tail-call tmp89 40 2)
  7462. )
  7463. \end{lstlisting}
  7464. \end{minipage}
  7465. &
  7466. $\Rightarrow$
  7467. \begin{minipage}{0.5\textwidth}
  7468. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  7469. (define (add86) : Integer
  7470. add86start:
  7471. movq %rdi, x87
  7472. movq %rsi, y88
  7473. movq x87, %rax
  7474. addq y88, %rax
  7475. jmp add11389conclusion
  7476. )
  7477. (define (main) : Integer
  7478. mainstart:
  7479. leaq (fun-ref add86), tmp89
  7480. movq $40, %rdi
  7481. movq $2, %rsi
  7482. tail-jmp tmp89
  7483. )
  7484. \end{lstlisting}
  7485. $\Downarrow$
  7486. \end{minipage}
  7487. \end{tabular}
  7488. \begin{tabular}{ll}
  7489. \begin{minipage}{0.3\textwidth}
  7490. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  7491. .globl add86
  7492. .align 16
  7493. add86:
  7494. pushq %rbp
  7495. movq %rsp, %rbp
  7496. jmp add86start
  7497. add86start:
  7498. movq %rdi, %rax
  7499. addq %rsi, %rax
  7500. jmp add86conclusion
  7501. add86conclusion:
  7502. popq %rbp
  7503. retq
  7504. \end{lstlisting}
  7505. \end{minipage}
  7506. &
  7507. \begin{minipage}{0.5\textwidth}
  7508. \begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
  7509. .globl main
  7510. .align 16
  7511. main:
  7512. pushq %rbp
  7513. movq %rsp, %rbp
  7514. movq $16384, %rdi
  7515. movq $16384, %rsi
  7516. callq initialize
  7517. movq rootstack_begin(%rip), %r15
  7518. jmp mainstart
  7519. mainstart:
  7520. leaq add86(%rip), %rcx
  7521. movq $40, %rdi
  7522. movq $2, %rsi
  7523. movq %rcx, %rax
  7524. popq %rbp
  7525. jmp *%rax
  7526. mainconclusion:
  7527. popq %rbp
  7528. retq
  7529. \end{lstlisting}
  7530. \end{minipage}
  7531. \end{tabular}
  7532. \caption{Example compilation of a simple function to x86.}
  7533. \label{fig:add-fun}
  7534. \end{figure}
  7535. % Challenge idea: inlining! (simple version)
  7536. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  7537. \chapter{Lexically Scoped Functions}
  7538. \label{ch:lambdas}
  7539. \index{lambda}
  7540. \index{lexical scoping}
  7541. This chapter studies lexically scoped functions as they appear in
  7542. functional languages such as Racket. By lexical scoping we mean that a
  7543. function's body may refer to variables whose binding site is outside
  7544. of the function, in an enclosing scope.
  7545. %
  7546. Consider the example in Figure~\ref{fig:lexical-scoping} written in
  7547. $R_5$, which extends $R_4$ with anonymous functions using the
  7548. \key{lambda} form. The body of the \key{lambda}, refers to three
  7549. variables: \code{x}, \code{y}, and \code{z}. The binding sites for
  7550. \code{x} and \code{y} are outside of the \key{lambda}. Variable
  7551. \code{y} is bound by the enclosing \key{let} and \code{x} is a
  7552. parameter of function \code{f}. The \key{lambda} is returned from the
  7553. function \code{f}. The main expression of the program includes two
  7554. calls to \code{f} with different arguments for \code{x}, first
  7555. \code{5} then \code{3}. The functions returned from \code{f} are bound
  7556. to variables \code{g} and \code{h}. Even though these two functions
  7557. were created by the same \code{lambda}, they are really different
  7558. functions because they use different values for \code{x}. Applying
  7559. \code{g} to \code{11} produces \code{20} whereas applying \code{h} to
  7560. \code{15} produces \code{22}. The result of this program is \code{42}.
  7561. \begin{figure}[btp]
  7562. % s4_6.rkt
  7563. \begin{lstlisting}
  7564. (define (f [x : Integer]) : (Integer -> Integer)
  7565. (let ([y 4])
  7566. (lambda: ([z : Integer]) : Integer
  7567. (+ x (+ y z)))))
  7568. (let ([g (f 5)])
  7569. (let ([h (f 3)])
  7570. (+ (g 11) (h 15))))
  7571. \end{lstlisting}
  7572. \caption{Example of a lexically scoped function.}
  7573. \label{fig:lexical-scoping}
  7574. \end{figure}
  7575. The approach that we take for implementing lexically scoped
  7576. functions is to compile them into top-level function definitions,
  7577. translating from $R_5$ into $R_4$. However, the compiler will need to
  7578. provide special treatment for variable occurrences such as \code{x}
  7579. and \code{y} in the body of the \code{lambda} of
  7580. Figure~\ref{fig:lexical-scoping}. After all, an $R_4$ function may not
  7581. refer to variables defined outside of it. To identify such variable
  7582. occurrences, we review the standard notion of free variable.
  7583. \begin{definition}
  7584. A variable is \emph{free in expression} $e$ if the variable occurs
  7585. inside $e$ but does not have an enclosing binding in $e$.\index{free
  7586. variable}
  7587. \end{definition}
  7588. For example, in the expression \code{(+ x (+ y z))} the variables
  7589. \code{x}, \code{y}, and \code{z} are all free. On the other hand,
  7590. only \code{x} and \code{y} are free in the following expression
  7591. because \code{z} is bound by the \code{lambda}.
  7592. \begin{lstlisting}
  7593. (lambda: ([z : Integer]) : Integer
  7594. (+ x (+ y z)))
  7595. \end{lstlisting}
  7596. So the free variables of a \code{lambda} are the ones that will need
  7597. special treatment. We need to arrange for some way to transport, at
  7598. runtime, the values of those variables from the point where the
  7599. \code{lambda} was created to the point where the \code{lambda} is
  7600. applied. An efficient solution to the problem, due to
  7601. \citet{Cardelli:1983aa}, is to bundle into a vector the values of the
  7602. free variables together with the function pointer for the lambda's
  7603. code, an arrangement called a \emph{flat closure} (which we shorten to
  7604. just ``closure''). \index{closure}\index{flat closure} Fortunately,
  7605. we have all the ingredients to make closures, Chapter~\ref{ch:tuples}
  7606. gave us vectors and Chapter~\ref{ch:functions} gave us function
  7607. pointers. The function pointer resides at index $0$ and the
  7608. values for the free variables will fill in the rest of the vector.
  7609. Let us revisit the example in Figure~\ref{fig:lexical-scoping} to see
  7610. how closures work. It's a three-step dance. The program first calls
  7611. function \code{f}, which creates a closure for the \code{lambda}. The
  7612. closure is a vector whose first element is a pointer to the top-level
  7613. function that we will generate for the \code{lambda}, the second
  7614. element is the value of \code{x}, which is \code{5}, and the third
  7615. element is \code{4}, the value of \code{y}. The closure does not
  7616. contain an element for \code{z} because \code{z} is not a free
  7617. variable of the \code{lambda}. Creating the closure is step 1 of the
  7618. dance. The closure is returned from \code{f} and bound to \code{g}, as
  7619. shown in Figure~\ref{fig:closures}.
  7620. %
  7621. The second call to \code{f} creates another closure, this time with
  7622. \code{3} in the second slot (for \code{x}). This closure is also
  7623. returned from \code{f} but bound to \code{h}, which is also shown in
  7624. Figure~\ref{fig:closures}.
  7625. \begin{figure}[tbp]
  7626. \centering \includegraphics[width=0.6\textwidth]{figs/closures}
  7627. \caption{Example closure representation for the \key{lambda}'s
  7628. in Figure~\ref{fig:lexical-scoping}.}
  7629. \label{fig:closures}
  7630. \end{figure}
  7631. Continuing with the example, consider the application of \code{g} to
  7632. \code{11} in Figure~\ref{fig:lexical-scoping}. To apply a closure, we
  7633. obtain the function pointer in the first element of the closure and
  7634. call it, passing in the closure itself and then the regular arguments,
  7635. in this case \code{11}. This technique for applying a closure is step
  7636. 2 of the dance.
  7637. %
  7638. But doesn't this \code{lambda} only take 1 argument, for parameter
  7639. \code{z}? The third and final step of the dance is generating a
  7640. top-level function for a \code{lambda}. We add an additional
  7641. parameter for the closure and we insert a \code{let} at the beginning
  7642. of the function for each free variable, to bind those variables to the
  7643. appropriate elements from the closure parameter.
  7644. %
  7645. This three-step dance is known as \emph{closure conversion}. We
  7646. discuss the details of closure conversion in
  7647. Section~\ref{sec:closure-conversion} and the code generated from the
  7648. example in Section~\ref{sec:example-lambda}. But first we define the
  7649. syntax and semantics of $R_5$ in Section~\ref{sec:r5}.
  7650. \section{The $R_5$ Language}
  7651. \label{sec:r5}
  7652. The concrete and abstract syntax for $R_5$, a language with anonymous
  7653. functions and lexical scoping, is defined in
  7654. Figures~\ref{fig:r5-concrete-syntax} and ~\ref{fig:r5-syntax}. It adds
  7655. the \key{lambda} form to the grammar for $R_4$, which already has
  7656. syntax for function application.
  7657. \begin{figure}[tp]
  7658. \centering
  7659. \fbox{
  7660. \begin{minipage}{0.96\textwidth}
  7661. \small
  7662. \[
  7663. \begin{array}{lcl}
  7664. \Type &::=& \gray{\key{Integer} \mid \key{Boolean}
  7665. \mid (\key{Vector}\;\Type\ldots) \mid \key{Void}
  7666. \mid (\Type\ldots \; \key{->}\; \Type)} \\
  7667. \Exp &::=& \gray{ \Int \mid \CREAD{} \mid \CNEG{\Exp}
  7668. \mid \CADD{\Exp}{\Exp} \mid \CSUB{\Exp}{\Exp} } \\
  7669. &\mid& \gray{ \Var \mid \CLET{\Var}{\Exp}{\Exp} }\\
  7670. &\mid& \gray{\key{\#t} \mid \key{\#f}
  7671. \mid (\key{and}\;\Exp\;\Exp)
  7672. \mid (\key{or}\;\Exp\;\Exp)
  7673. \mid (\key{not}\;\Exp) } \\
  7674. &\mid& \gray{ (\key{eq?}\;\Exp\;\Exp) \mid \CIF{\Exp}{\Exp}{\Exp} } \\
  7675. &\mid& \gray{ (\key{vector}\;\Exp\ldots) \mid
  7676. (\key{vector-ref}\;\Exp\;\Int)} \\
  7677. &\mid& \gray{(\key{vector-set!}\;\Exp\;\Int\;\Exp)\mid (\key{void})
  7678. \mid (\Exp \; \Exp\ldots) } \\
  7679. &\mid& \LP \key{procedure-arity}~\Exp\RP \\
  7680. &\mid& \CLAMBDA{\LP\LS\Var \key{:} \Type\RS\ldots\RP}{\Type}{\Exp} \\
  7681. \Def &::=& \gray{ \CDEF{\Var}{\LS\Var \key{:} \Type\RS\ldots}{\Type}{\Exp} } \\
  7682. R_5 &::=& \gray{\Def\ldots \; \Exp}
  7683. \end{array}
  7684. \]
  7685. \end{minipage}
  7686. }
  7687. \caption{The concrete syntax of $R_5$, extending $R_4$ (Figure~\ref{fig:r4-concrete-syntax})
  7688. with \key{lambda}.}
  7689. \label{fig:r5-concrete-syntax}
  7690. \end{figure}
  7691. \begin{figure}[tp]
  7692. \centering
  7693. \fbox{
  7694. \begin{minipage}{0.96\textwidth}
  7695. \small
  7696. \[
  7697. \begin{array}{lcl}
  7698. \itm{op} &::=& \ldots \mid \code{procedure-arity} \\
  7699. \Exp &::=& \gray{ \INT{\Int} \VAR{\Var} \mid \LET{\Var}{\Exp}{\Exp} } \\
  7700. &\mid& \gray{ \PRIM{\itm{op}}{\Exp\ldots} }\\
  7701. &\mid& \gray{ \BOOL{\itm{bool}}
  7702. \mid \IF{\Exp}{\Exp}{\Exp} } \\
  7703. &\mid& \gray{ \VOID{} \mid \LP\key{HasType}~\Exp~\Type \RP
  7704. \mid \APPLY{\Exp}{\Exp\ldots} }\\
  7705. &\mid& \LAMBDA{\LP\LS\Var\code{:}\Type\RS\ldots\RP}{\Type}{\Exp}\\
  7706. \Def &::=& \gray{ \FUNDEF{\Var}{\LP\LS\Var \code{:} \Type\RS\ldots\RP}{\Type}{\code{'()}}{\Exp} }\\
  7707. R_5 &::=& \gray{ \PROGRAMDEFSEXP{\code{'()}}{\LP\Def\ldots\RP}{\Exp} }
  7708. \end{array}
  7709. \]
  7710. \end{minipage}
  7711. }
  7712. \caption{The abstract syntax of $R_5$, extending $R_4$ (Figure~\ref{fig:r4-syntax}).}
  7713. \label{fig:r5-syntax}
  7714. \end{figure}
  7715. \index{interpreter}
  7716. \label{sec:interp-R5}
  7717. Figure~\ref{fig:interp-R5} shows the definitional interpreter for
  7718. $R_5$. The clause for \key{lambda} saves the current environment
  7719. inside the returned \key{lambda}. Then the clause for \key{Apply} uses
  7720. the environment from the \key{lambda}, the \code{lam-env}, when
  7721. interpreting the body of the \key{lambda}. The \code{lam-env}
  7722. environment is extended with the mapping of parameters to argument
  7723. values.
  7724. \begin{figure}[tbp]
  7725. \begin{lstlisting}
  7726. (define interp-R5-class
  7727. (class interp-R4-class
  7728. (super-new)
  7729. (define/override (interp-op op)
  7730. (match op
  7731. ['procedure-arity
  7732. (lambda (v)
  7733. (match v
  7734. [`(function (,xs ...) ,body ,lam-env) (length xs)]
  7735. [else (error 'interp-op "expected a function, not ~a" v)]))]
  7736. [else (super interp-op op)]))
  7737. (define/override ((interp-exp env) e)
  7738. (define recur (interp-exp env))
  7739. (match e
  7740. [(Lambda (list `[,xs : ,Ts] ...) rT body)
  7741. `(function ,xs ,body ,env)]
  7742. [else ((super interp-exp env) e)]))
  7743. ))
  7744. (define (interp-R5 p)
  7745. (send (new interp-R5-class) interp-program p))
  7746. \end{lstlisting}
  7747. \caption{Interpreter for $R_5$.}
  7748. \label{fig:interp-R5}
  7749. \end{figure}
  7750. \label{sec:type-check-r5}
  7751. \index{type checking}
  7752. Figure~\ref{fig:type-check-R5} shows how to type check the new
  7753. \key{lambda} form. The body of the \key{lambda} is checked in an
  7754. environment that includes the current environment (because it is
  7755. lexically scoped) and also includes the \key{lambda}'s parameters. We
  7756. require the body's type to match the declared return type.
  7757. \begin{figure}[tbp]
  7758. \begin{lstlisting}
  7759. (define (type-check-R5 env)
  7760. (lambda (e)
  7761. (match e
  7762. [(Lambda (and params `([,xs : ,Ts] ...)) rT body)
  7763. (define-values (new-body bodyT)
  7764. ((type-check-exp (append (map cons xs Ts) env)) body))
  7765. (define ty `(,@Ts -> ,rT))
  7766. (cond
  7767. [(equal? rT bodyT)
  7768. (values (HasType (Lambda params rT new-body) ty) ty)]
  7769. [else
  7770. (error "mismatch in return type" bodyT rT)])]
  7771. ...
  7772. )))
  7773. \end{lstlisting}
  7774. \caption{Type checking the \key{lambda}'s in $R_5$.}
  7775. \label{fig:type-check-R5}
  7776. \end{figure}
  7777. \section{Reveal Functions and the $F_2$ language}
  7778. \label{sec:reveal-functions-r5}
  7779. To support the \code{procedure-arity} operator we need to communicate
  7780. the arity of a function to the point of closure creation. We can
  7781. accomplish this by replacing the $\FUNREF{\Var}$ struct with one that
  7782. has a second field for the arity: $\FUNREFARITY{\Var}{\Int}$. The
  7783. output of this pass is the language $F_2$, whose syntax is defined in
  7784. Figure~\ref{fig:f2-syntax}.
  7785. \begin{figure}[tp]
  7786. \centering
  7787. \fbox{
  7788. \begin{minipage}{0.96\textwidth}
  7789. \[
  7790. \begin{array}{lcl}
  7791. \Exp &::=& \ldots \mid \FUNREFARITY{\Var}{\Int}\\
  7792. \Def &::=& \gray{ \FUNDEF{\Var}{([\Var \code{:} \Type]\ldots)}{\Type}{\code{'()}}{\Exp} }\\
  7793. F_2 &::=& \gray{\PROGRAMDEFS{\code{'()}}{\LP \Def\ldots \RP}}
  7794. \end{array}
  7795. \]
  7796. \end{minipage}
  7797. }
  7798. \caption{The abstract syntax $F_2$, an extension of $R_5$
  7799. (Figure~\ref{fig:r5-syntax}).}
  7800. \label{fig:f2-syntax}
  7801. \end{figure}
  7802. \section{Closure Conversion}
  7803. \label{sec:closure-conversion}
  7804. \index{closure conversion}
  7805. The compiling of lexically-scoped functions into top-level function
  7806. definitions is accomplished in the pass \code{convert-to-closures}
  7807. that comes after \code{reveal-functions} and before
  7808. \code{limit-functions}.
  7809. As usual, we implement the pass as a recursive function over the
  7810. AST. All of the action is in the clauses for \key{Lambda} and
  7811. \key{Apply}. We transform a \key{Lambda} expression into an expression
  7812. that creates a closure, that is, a vector whose first element is a
  7813. function pointer and the rest of the elements are the free variables
  7814. of the \key{Lambda}. We use the struct \code{Closure} here instead of
  7815. using \code{vector} so that we can distinguish closures from vectors
  7816. in Section~\ref{sec:optimize-closures} and to record the arity. In
  7817. the generated code below, the \itm{name} is a unique symbol generated
  7818. to identify the function and the \itm{arity} is the number of
  7819. parameters (the length of \itm{ps}).
  7820. \begin{lstlisting}
  7821. (Lambda |\itm{ps}| |\itm{rt}| |\itm{body}|)
  7822. |$\Rightarrow$|
  7823. (Closure |\itm{arity}| (cons (FunRef |\itm{name}|) |\itm{fvs}|))
  7824. \end{lstlisting}
  7825. In addition to transforming each \key{Lambda} into a \key{Closure}, we
  7826. create a top-level function definition for each \key{Lambda}, as
  7827. shown below.\\
  7828. \begin{minipage}{0.8\textwidth}
  7829. \begin{lstlisting}
  7830. (Def |\itm{name}| ([clos : (Vector _ |\itm{fvts}| ...)] |\itm{ps'}| ...) |\itm{rt'}|
  7831. (Let |$\itm{fvs}_1$| (Prim 'vector-ref (list (Var clos) (Int 1)))
  7832. ...
  7833. (Let |$\itm{fvs}_n$| (Prim 'vector-ref (list (Var clos) (Int |$n$|)))
  7834. |\itm{body'}|)...))
  7835. \end{lstlisting}
  7836. \end{minipage}\\
  7837. The \code{clos} parameter refers to the closure. Translate the type
  7838. annotations in \itm{ps} and the return type \itm{rt}, as discussed in
  7839. the next paragraph, to obtain \itm{ps'} and \itm{rt'}. The types
  7840. $\itm{fvts}$ are the types of the free variables in the lambda and the
  7841. underscore \code{\_} is a dummy type that we use because it is rather
  7842. difficult to give a type to the function in the closure's
  7843. type.\footnote{To give an accurate type to a closure, we would need to
  7844. add existential types to the type checker~\citep{Minamide:1996ys}.}
  7845. The dummy type is considered to be equal to any other type during type
  7846. checking. The sequence of \key{Let} forms bind the free variables to
  7847. their values obtained from the closure.
  7848. Closure conversion turns functions into vectors, so the type
  7849. annotations in the program must also be translated. We recommend
  7850. defining a auxiliary recursive function for this purpose. Function
  7851. types should be translated as follows.
  7852. \begin{lstlisting}
  7853. (|$T_1, \ldots, T_n$| -> |$T_r$|)
  7854. |$\Rightarrow$|
  7855. (Vector ((Vector _) |$T'_1, \ldots, T'_n$| -> |$T'_r$|))
  7856. \end{lstlisting}
  7857. The above type says that the first thing in the vector is a function
  7858. pointer. The first parameter of the function pointer is a vector (a
  7859. closure) and the rest of the parameters are the ones from the original
  7860. function, with types $T'_1, \ldots, T'_n$. The \code{Vector} type for
  7861. the closure omits the types of the free variables because 1) those
  7862. types are not available in this context and 2) we do not need them in
  7863. the code that is generated for function application.
  7864. We transform function application into code that retrieves the
  7865. function pointer from the closure and then calls the function, passing
  7866. in the closure as the first argument. We bind $e'$ to a temporary
  7867. variable to avoid code duplication.
  7868. \begin{lstlisting}
  7869. (Apply |$e$| |\itm{es}|)
  7870. |$\Rightarrow$|
  7871. (Let |\itm{tmp}| |$e'$|
  7872. (Apply (Prim 'vector-ref (list (Var |\itm{tmp}|) (Int 0))) (cons |\itm{tmp}| |\itm{es'}|)))
  7873. \end{lstlisting}
  7874. There is also the question of what to do with references top-level
  7875. function definitions. To maintain a uniform translation of function
  7876. application, we turn function references into closures.
  7877. \begin{tabular}{lll}
  7878. \begin{minipage}{0.3\textwidth}
  7879. \begin{lstlisting}
  7880. (FunRefArity |$f$| |$n$|)
  7881. \end{lstlisting}
  7882. \end{minipage}
  7883. &
  7884. $\Rightarrow$
  7885. &
  7886. \begin{minipage}{0.5\textwidth}
  7887. \begin{lstlisting}
  7888. (Closure |$n$| (FunRef |$f$|) '())
  7889. \end{lstlisting}
  7890. \end{minipage}
  7891. \end{tabular} \\
  7892. %
  7893. The top-level function definitions need to be updated as well to take
  7894. an extra closure parameter.
  7895. \section{An Example Translation}
  7896. \label{sec:example-lambda}
  7897. Figure~\ref{fig:lexical-functions-example} shows the result of
  7898. \code{reveal-functions} and \code{convert-to-closures} for the example
  7899. program demonstrating lexical scoping that we discussed at the
  7900. beginning of this chapter.
  7901. \begin{figure}[tbp]
  7902. \begin{minipage}{0.8\textwidth}
  7903. % tests/lambda_test_6.rkt
  7904. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  7905. (define (f6 [x7 : Integer]) : (Integer -> Integer)
  7906. (let ([y8 4])
  7907. (lambda: ([z9 : Integer]) : Integer
  7908. (+ x7 (+ y8 z9)))))
  7909. (define (main) : Integer
  7910. (let ([g0 ((fun-ref-arity f6 1) 5)])
  7911. (let ([h1 ((fun-ref-arity f6 1) 3)])
  7912. (+ (g0 11) (h1 15)))))
  7913. \end{lstlisting}
  7914. $\Rightarrow$
  7915. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  7916. (define (f6 [fvs4 : _] [x7 : Integer]) : (Vector ((Vector _) Integer -> Integer))
  7917. (let ([y8 4])
  7918. (closure 1 (list (fun-ref lambda2) x7 y8))))
  7919. (define (lambda2 [fvs3 : (Vector _ Integer Integer)] [z9 : Integer]) : Integer
  7920. (let ([x7 (vector-ref fvs3 1)])
  7921. (let ([y8 (vector-ref fvs3 2)])
  7922. (+ x7 (+ y8 z9)))))
  7923. (define (main) : Integer
  7924. (let ([g0 (let ([clos5 (closure 1 (list (fun-ref f6)))])
  7925. ((vector-ref clos5 0) clos5 5))])
  7926. (let ([h1 (let ([clos6 (closure 1 (list (fun-ref f6)))])
  7927. ((vector-ref clos6 0) clos6 3))])
  7928. (+ ((vector-ref g0 0) g0 11) ((vector-ref h1 0) h1 15)))))
  7929. \end{lstlisting}
  7930. \end{minipage}
  7931. \caption{Example of closure conversion.}
  7932. \label{fig:lexical-functions-example}
  7933. \end{figure}
  7934. \begin{exercise}\normalfont
  7935. Expand your compiler to handle $R_5$ as outlined in this chapter.
  7936. Create 5 new programs that use \key{lambda} functions and make use of
  7937. lexical scoping. Test your compiler on these new programs and all of
  7938. your previously created test programs.
  7939. \end{exercise}
  7940. \section{Expose Allocation}
  7941. \label{sec:expose-allocation-r5}
  7942. Compile the $\CLOSURE{\itm{arity}}{\LP\Exp\ldots\RP}$ form into code
  7943. that allocates and initializes a vector, similar to the translation of
  7944. the \code{vector} operator in Section~\ref{sec:expose-allocation}.
  7945. The only difference is replacing the use of
  7946. \ALLOC{\itm{len}}{\itm{type}} with
  7947. \ALLOCCLOS{\itm{len}}{\itm{type}}{\itm{arity}}.
  7948. \section{Explicate Control and $C_4$}
  7949. \label{sec:explicate-r5}
  7950. The output language of \code{explicate-control} is $C_4$ whose
  7951. abstract syntax is defined in Figure~\ref{fig:c4-syntax}. The only
  7952. difference with respect to $C_3$ is the addition of the
  7953. \code{AllocateClosure} form to the grammar for $\Exp$. The handling
  7954. of \code{AllocateClosure} in the \code{explicate-control} pass is
  7955. similar to the handling of other expressions such as primitive
  7956. operators.
  7957. \begin{figure}[tp]
  7958. \fbox{
  7959. \begin{minipage}{0.96\textwidth}
  7960. \small
  7961. \[
  7962. \begin{array}{lcl}
  7963. \Exp &::= & \ldots
  7964. \mid \ALLOCCLOS{\Int}{\Type}{\Int} \\
  7965. \Stmt &::=& \gray{ \ASSIGN{\VAR{\Var}}{\Exp}
  7966. \mid \LP\key{Collect} \,\itm{int}\RP } \\
  7967. \Tail &::= & \gray{ \RETURN{\Exp} \mid \SEQ{\Stmt}{\Tail}
  7968. \mid \GOTO{\itm{label}} } \\
  7969. &\mid& \gray{ \IFSTMT{\BINOP{\itm{cmp}}{\Atm}{\Atm}}{\GOTO{\itm{label}}}{\GOTO{\itm{label}}} }\\
  7970. &\mid& \gray{ \TAILCALL{\Atm}{\Atm\ldots} } \\
  7971. \Def &::=& \gray{ \DEF{\itm{label}}{\LP[\Var\key{:}\Type]\ldots\RP}{\Type}{\itm{info}}{\LP\LP\itm{label}\,\key{.}\,\Tail\RP\ldots\RP} }\\
  7972. C_4 & ::= & \gray{ \PROGRAMDEFS{\itm{info}}{\LP\Def\ldots\RP} }
  7973. \end{array}
  7974. \]
  7975. \end{minipage}
  7976. }
  7977. \caption{The abstract syntax of $C_4$, extending $C_3$ (Figure~\ref{fig:c3-syntax}).}
  7978. \label{fig:c4-syntax}
  7979. \end{figure}
  7980. \section{Select Instructions}
  7981. \label{sec:select-instructions-R5}
  7982. Compile \ALLOCCLOS{\itm{len}}{\itm{type}}{\itm{arity}} in almost the
  7983. same way as the \ALLOC{\itm{len}}{\itm{type}} form
  7984. (Section~\ref{sec:select-instructions-gc}). The only difference is
  7985. that you should place the \itm{arity} in the tag that is stored at
  7986. position $0$ of the vector. Recall that in
  7987. Section~\ref{sec:select-instructions-gc} we used the first $56$ bits
  7988. of the 64-bit tag, but that the rest were unused. So the arity goes
  7989. into the tag in bit positions $57$ through $63$.
  7990. Compile the \code{procedure-arity} operator into a sequence of
  7991. instructions that access the tag from position $0$ of the vector and
  7992. shift it by $57$ bits to the right.
  7993. \begin{figure}[p]
  7994. \begin{tikzpicture}[baseline=(current bounding box.center)]
  7995. \node (R4) at (0,2) {\large $R_4$};
  7996. \node (R4-2) at (3,2) {\large $R_4$};
  7997. \node (R4-3) at (6,2) {\large $R_4$};
  7998. \node (F1-1) at (12,0) {\large $F_1$};
  7999. \node (F1-2) at (9,0) {\large $F_1$};
  8000. \node (F1-3) at (6,0) {\large $F_1$};
  8001. \node (F1-4) at (3,0) {\large $F_1$};
  8002. \node (F1-5) at (0,0) {\large $F_1$};
  8003. \node (C3-2) at (3,-2) {\large $C_3$};
  8004. \node (x86-2) at (3,-4) {\large $\text{x86}^{*}_3$};
  8005. \node (x86-3) at (6,-4) {\large $\text{x86}^{*}_3$};
  8006. \node (x86-4) at (9,-4) {\large $\text{x86}^{*}_3$};
  8007. \node (x86-5) at (9,-6) {\large $\text{x86}^{\dagger}_3$};
  8008. \node (x86-2-1) at (3,-6) {\large $\text{x86}^{*}_3$};
  8009. \node (x86-2-2) at (6,-6) {\large $\text{x86}^{*}_3$};
  8010. \path[->,bend left=15] (R4) edge [above] node
  8011. {\ttfamily\footnotesize shrink} (R4-2);
  8012. \path[->,bend left=15] (R4-2) edge [above] node
  8013. {\ttfamily\footnotesize uniquify} (R4-3);
  8014. \path[->,bend left=15] (R4-3) edge [right] node
  8015. {\ttfamily\footnotesize reveal-functions} (F1-1);
  8016. \path[->,bend left=15] (F1-1) edge [below] node
  8017. {\ttfamily\footnotesize convert-to-clos.} (F1-2);
  8018. \path[->,bend right=15] (F1-2) edge [above] node
  8019. {\ttfamily\footnotesize limit-fun.} (F1-3);
  8020. \path[->,bend right=15] (F1-3) edge [above] node
  8021. {\ttfamily\footnotesize expose-alloc.} (F1-4);
  8022. \path[->,bend right=15] (F1-4) edge [above] node
  8023. {\ttfamily\footnotesize remove-complex.} (F1-5);
  8024. \path[->,bend right=15] (F1-5) edge [right] node
  8025. {\ttfamily\footnotesize explicate-control} (C3-2);
  8026. \path[->,bend left=15] (C3-2) edge [left] node
  8027. {\ttfamily\footnotesize select-instr.} (x86-2);
  8028. \path[->,bend right=15] (x86-2) edge [left] node
  8029. {\ttfamily\footnotesize uncover-live} (x86-2-1);
  8030. \path[->,bend right=15] (x86-2-1) edge [below] node
  8031. {\ttfamily\footnotesize build-inter.} (x86-2-2);
  8032. \path[->,bend right=15] (x86-2-2) edge [left] node
  8033. {\ttfamily\footnotesize allocate-reg.} (x86-3);
  8034. \path[->,bend left=15] (x86-3) edge [above] node
  8035. {\ttfamily\footnotesize patch-instr.} (x86-4);
  8036. \path[->,bend left=15] (x86-4) edge [right] node
  8037. {\ttfamily\footnotesize print-x86} (x86-5);
  8038. \end{tikzpicture}
  8039. \caption{Diagram of the passes for $R_5$, a language with lexically-scoped
  8040. functions.}
  8041. \label{fig:R5-passes}
  8042. \end{figure}
  8043. Figure~\ref{fig:R5-passes} provides an overview of all the passes needed
  8044. for the compilation of $R_5$.
  8045. \clearpage
  8046. \section{Challenge: Optimize Closures}
  8047. \label{sec:optimize-closures}
  8048. In this chapter we compiled lexically-scoped functions into a
  8049. relatively efficient representation: flat closures. However, even this
  8050. representation comes with some overhead. For example, consider the
  8051. following program with a function \code{tail-sum} that does not have
  8052. any free variables and where all the uses of \code{tail-sum} are in
  8053. applications where we know that only \code{tail-sum} is being applied
  8054. (and not any other functions).
  8055. \begin{center}
  8056. \begin{minipage}{0.95\textwidth}
  8057. \begin{lstlisting}
  8058. (define (tail-sum [n : Integer] [r : Integer]) : Integer
  8059. (if (eq? n 0)
  8060. r
  8061. (tail-sum (- n 1) (+ n r))))
  8062. (+ (tail-sum 5 0) 27)
  8063. \end{lstlisting}
  8064. \end{minipage}
  8065. \end{center}
  8066. As described in this chapter, we uniformly apply closure conversion to
  8067. all functions, obtaining the following output for this program.
  8068. \begin{center}
  8069. \begin{minipage}{0.95\textwidth}
  8070. \begin{lstlisting}
  8071. (define (tail_sum1 [fvs5 : _] [n2 : Integer] [r3 : Integer]) : Integer
  8072. (if (eq? n2 0)
  8073. r3
  8074. (let ([clos4 (closure (list (fun-ref tail_sum1)))])
  8075. ((vector-ref clos4 0) clos4 (+ n2 -1) (+ n2 r3)))))
  8076. (define (main) : Integer
  8077. (+ (let ([clos6 (closure (list (fun-ref tail_sum1)))])
  8078. ((vector-ref clos6 0) clos6 5 0)) 27))
  8079. \end{lstlisting}
  8080. \end{minipage}
  8081. \end{center}
  8082. In the previous Chapter, there would be no allocation in the program
  8083. and the calls to \code{tail-sum} would be direct calls. In contrast,
  8084. the above program allocates memory for each \code{closure} and the
  8085. calls to \code{tail-sum} are indirect. These two differences incur
  8086. considerable overhead in a program such as this one, where the
  8087. allocations and indirect calls occur inside a tight loop.
  8088. One might think that this problem is trivial to solve: can't we just
  8089. recognize calls of the form \code{((fun-ref $f$) $e_1 \ldots e_n$)}
  8090. and compile them to direct calls \code{((fun-ref $f$) $e'_1 \ldots
  8091. e'_n$)} instead of treating it like a call to a closure? We would
  8092. also drop the \code{fvs5} parameter of \code{tail\_sum1}.
  8093. %
  8094. However, this problem is not so trivial because a global function may
  8095. ``escape'' and become involved in applications that also involve
  8096. closures. Consider the following example in which the application
  8097. \code{(f 41)} needs to be compiled into a closure application, because
  8098. the \code{lambda} may get bound to \code{f}, but the \code{add1}
  8099. function might also get bound to \code{f}.
  8100. \begin{lstlisting}
  8101. (define (add1 [x : Integer]) : Integer
  8102. (+ x 1))
  8103. (let ([y (read)])
  8104. (let ([f (if (eq? (read) 0)
  8105. add1
  8106. (lambda: ([x : Integer]) : Integer (- x y)))])
  8107. (f 41)))
  8108. \end{lstlisting}
  8109. If a global function name is used in any way other than as the
  8110. operator in a direct call, then we say that the function
  8111. \emph{escapes}. If a global function does not escape, then we do not
  8112. need to perform closure conversion on the function.
  8113. \begin{exercise}\normalfont
  8114. Implement an auxiliary function for detecting which global
  8115. functions escape. Using that function, implement an improved version
  8116. of closure conversion that does not apply closure conversion to
  8117. global functions that do not escape but instead compiles them as
  8118. regular functions. Create several new test cases that check whether
  8119. you properly detect whether global functions escape or not.
  8120. \end{exercise}
  8121. So far we have reduced the overhead of calling global functions, but
  8122. it would also be nice to reduce the overhead of calling a
  8123. \code{lambda} when we can determine at compile time which
  8124. \code{lambda} will be called. We refer to such calls as \emph{known
  8125. calls}. Consider the following example in which a \code{lambda} is
  8126. bound to \code{f} and then applied.
  8127. \begin{lstlisting}
  8128. (let ([y (read)])
  8129. (let ([f (lambda: ([x : Integer]) : Integer
  8130. (+ x y))])
  8131. (f 21)))
  8132. \end{lstlisting}
  8133. Closure conversion compiles \code{(f 21)} into an indirect call:
  8134. \begin{lstlisting}
  8135. (define (lambda5 [fvs6 : (Vector _ Integer)] [x3 : Integer]) : Integer
  8136. (let ([y2 (vector-ref fvs6 1)])
  8137. (+ x3 y2)))
  8138. (define (main) : Integer
  8139. (let ([y2 (read)])
  8140. (let ([f4 (Closure 1 (list (fun-ref lambda5) y2))])
  8141. ((vector-ref f4 0) f4 21))))
  8142. \end{lstlisting}
  8143. but we can instead compile the application \code{(f 21)} into a direct call
  8144. to \code{lambda5}:
  8145. \begin{lstlisting}
  8146. (define (main) : Integer
  8147. (let ([y2 (read)])
  8148. (let ([f4 (Closure 1 (list (fun-ref lambda5) y2))])
  8149. ((fun-ref lambda5) f4 21))))
  8150. \end{lstlisting}
  8151. The problem of determining which lambda will be called from a
  8152. particular application is quite challenging in general and the topic
  8153. of considerable research~\citep{Shivers:1988aa,Gilray:2016aa}. For the
  8154. following exercise we recommend that you compile an application to a
  8155. direct call when the operator is a variable and the variable is
  8156. \code{let}-bound to a closure. This can be accomplished by maintaining
  8157. an environment mapping \code{let}-bound variables to function names.
  8158. Extend the environment whenever you encounter a closure on the
  8159. right-hand side of a \code{let}, mapping the \code{let}-bound variable
  8160. to the name of the global function for the closure. This pass should
  8161. come after closure conversion.
  8162. \begin{exercise}\normalfont
  8163. Implement a compiler pass, named \code{optimize-known-calls}, that
  8164. compiles known calls into direct calls. Verify that your compiler is
  8165. successful in this regard on several example programs.
  8166. \end{exercise}
  8167. These exercises only scratches the surface of optimizing of
  8168. closures. A good next step for the interested reader is to look at the
  8169. work of \citet{Keep:2012ab}.
  8170. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  8171. \chapter{Dynamic Typing}
  8172. \label{ch:type-dynamic}
  8173. \index{dynamic typing}
  8174. In this chapter we discuss the compilation of $R_7$, a dynamically
  8175. typed language and a subset of the Racket language. This is in
  8176. contrast to the previous chapters, which have studied the compilation
  8177. of Typed Racket. In dynamically typed languages such as $R_7$, a given
  8178. expression may produce a value of a different type each time it is
  8179. executed. Consider the following example with a conditional \code{if}
  8180. expression that may return a Boolean or an integer depending on the
  8181. input to the program.
  8182. \begin{lstlisting}
  8183. (not (if (eq? (read) 1) #f 0))
  8184. \end{lstlisting}
  8185. Languages that allow expressions to produce different kinds of values
  8186. are called \emph{polymorphic}, a word composed of the Greek roots
  8187. ``poly'', meaning ``many'', and ``morph'', meaning ``shape''. There
  8188. are several kinds of polymorphism in programming languages, such as
  8189. subtype polymorphism and parametric
  8190. polymorphism~\citep{Cardelli:1985kx}. The kind of polymorphism we
  8191. study in this chapter does not have a special name but it is the kind
  8192. that arises in dynamically typed languages.
  8193. Another characteristic of dynamically typed languages is that
  8194. primitive operations, such as \code{not}, are often defined to operate
  8195. on many different types of values. In fact, in Racket, the \code{not}
  8196. operator produces a result for any kind of value: given \code{\#f} it
  8197. returns \code{\#t} and given anything else it returns \code{\#f}.
  8198. Furthermore, even when primitive operations restrict their inputs to
  8199. values of a certain type, this restriction is enforced at runtime
  8200. instead of during compilation. For example, the following vector
  8201. reference results in a run-time contract violation because the index
  8202. must be in integer, not a Boolean such as \code{\#t}.
  8203. \begin{lstlisting}
  8204. (vector-ref (vector 42) #t)
  8205. \end{lstlisting}
  8206. \begin{figure}[tp]
  8207. \centering
  8208. \fbox{
  8209. \begin{minipage}{0.97\textwidth}
  8210. \[
  8211. \begin{array}{rcl}
  8212. \itm{cmp} &::= & \key{eq?} \mid \key{<} \mid \key{<=} \mid \key{>} \mid \key{>=} \\
  8213. \Exp &::=& \Int \mid \CREAD{} \mid \CNEG{\Exp}
  8214. \mid \CADD{\Exp}{\Exp} \mid \CSUB{\Exp}{\Exp} \\
  8215. &\mid& \Var \mid \CLET{\Var}{\Exp}{\Exp} \\
  8216. &\mid& \key{\#t} \mid \key{\#f}
  8217. \mid \CBINOP{\key{and}}{\Exp}{\Exp}
  8218. \mid \CBINOP{\key{or}}{\Exp}{\Exp}
  8219. \mid \CUNIOP{\key{not}}{\Exp} \\
  8220. &\mid& \LP\itm{cmp}\;\Exp\;\Exp\RP \mid \CIF{\Exp}{\Exp}{\Exp} \\
  8221. &\mid& \LP\key{vector}\;\Exp\ldots\RP \mid
  8222. \LP\key{vector-ref}\;\Exp\;\Exp\RP \\
  8223. &\mid& \LP\key{vector-set!}\;\Exp\;\Exp\;\Exp\RP \mid \LP\key{void}\RP \\
  8224. &\mid& \LP\Exp \; \Exp\ldots\RP
  8225. \mid \LP\key{lambda}\;\LP\Var\ldots\RP\;\Exp\RP \\
  8226. & \mid & \LP\key{boolean?}\;\Exp\RP \mid \LP\key{integer?}\;\Exp\RP\\
  8227. & \mid & \LP\key{vector?}\;\Exp\RP \mid \LP\key{procedure?}\;\Exp\RP \mid \LP\key{void?}\;\Exp\RP \\
  8228. \Def &::=& \LP\key{define}\; \LP\Var \; \Var\ldots\RP \; \Exp\RP \\
  8229. R_7 &::=& \Def\ldots\; \Exp
  8230. \end{array}
  8231. \]
  8232. \end{minipage}
  8233. }
  8234. \caption{Syntax of $R_7$, an untyped language (a subset of Racket).}
  8235. \label{fig:r7-concrete-syntax}
  8236. \end{figure}
  8237. \begin{figure}[tp]
  8238. \centering
  8239. \fbox{
  8240. \begin{minipage}{0.96\textwidth}
  8241. \small
  8242. \[
  8243. \begin{array}{lcl}
  8244. \Exp &::=& \INT{\Int} \mid \VAR{\Var} \mid \LET{\Var}{\Exp}{\Exp} \\
  8245. &\mid& \PRIM{\itm{op}}{\Exp\ldots} \\
  8246. &\mid& \BOOL{\itm{bool}}
  8247. \mid \IF{\Exp}{\Exp}{\Exp} \\
  8248. &\mid& \VOID{} \mid \APPLY{\Exp}{\Exp\ldots} \\
  8249. &\mid& \LAMBDA{\LP\Var\ldots\RP}{\code{'Any}}{\Exp}\\
  8250. \Def &::=& \FUNDEF{\Var}{\LP\Var\ldots\RP}{\code{'Any}}{\code{'()}}{\Exp} \\
  8251. R_7 &::=& \PROGRAMDEFSEXP{\code{'()}}{\LP\Def\ldots\RP}{\Exp}
  8252. \end{array}
  8253. \]
  8254. \end{minipage}
  8255. }
  8256. \caption{The abstract syntax of $R_7$.}
  8257. \label{fig:r7-syntax}
  8258. \end{figure}
  8259. The concrete and abstract syntax of $R_7$, our subset of Racket, is
  8260. defined in Figures~\ref{fig:r7-concrete-syntax} and
  8261. \ref{fig:r7-syntax}.
  8262. %
  8263. There is no type checker for $R_7$ because it is not a statically
  8264. typed language (it's dynamically typed!).
  8265. %
  8266. The definitional interpreter for $R_7$ is presented in
  8267. Figure~\ref{fig:interp-R7}.
  8268. \begin{figure}[tbp]
  8269. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  8270. (define (interp-R7-exp env)
  8271. (lambda (ast)
  8272. (define recur (interp-R7-exp env))
  8273. (match ast
  8274. [(Var x) (lookup x env)]
  8275. [(Int n) `(tagged ,n Integer)]
  8276. [(Bool b) `(tagged ,b Boolean)]
  8277. [(Prim 'read '()) `(tagged ,(read-fixnum) Integer)]
  8278. [(Lambda xs rt body)
  8279. `(tagged (lambda ,xs ,body ,env) (,@(for/list ([x xs]) 'Any) -> Any))]
  8280. [(Prim 'vector es)
  8281. `(tagged ,(apply vector (for/list ([e es]) (recur e)))
  8282. (Vector ,@(for/list ([e es]) 'Any)))]
  8283. [(Prim 'vector-set! (list e1 n e2))
  8284. (define vec (value-of-any (recur e1)))
  8285. (define i (value-of-any (recur n)))
  8286. (vector-set! vec i (recur e2))
  8287. `(tagged ,(void) Void)]
  8288. [(Prim 'vector-ref (list e1 n))
  8289. (define vec (value-of-any (recur e1)))
  8290. (define i (value-of-any (recur n)))
  8291. (vector-ref vec i)]
  8292. [(Let x e body)
  8293. (define v (recur e))
  8294. ((interp-R7-exp (cons (cons x v) env)) body)]
  8295. [(Prim 'and (list e1 e2))
  8296. (recur (If e1 e2 (Bool #f)))]
  8297. [(Prim 'or (list e1 e2))
  8298. (define v1 (recur e1))
  8299. (match (value-of-any v1) [#f (recur e2)] [else v1])]
  8300. [(Prim 'eq? (list l r))
  8301. `(tagged ,(equal? (recur l) (recur r)) Boolean)]
  8302. [(If q t f)
  8303. (match (value-of-any (recur q)) [#f (recur f)] [else (recur t)])]
  8304. [(Prim op es)
  8305. (tag-value
  8306. (apply (interp-op op) (for/list ([e es]) (value-of-any (recur e)))))]
  8307. [(Apply f es)
  8308. (define new-args (map recur es))
  8309. (let ([f-val (value-of-any (recur f))])
  8310. (match f-val
  8311. [`(function (,xs ...) ,body ,lam-env)
  8312. (define new-env (append (map cons xs new-args) lam-env))
  8313. ((interp-R7-exp new-env) body)]
  8314. [else (error "interp-R7-exp, expected function, not" f-val)]))]
  8315. )))
  8316. \end{lstlisting}
  8317. \caption{Interpreter for the $R_7$ language.}
  8318. \label{fig:interp-R7}
  8319. \end{figure}
  8320. Let us consider how we might compile $R_7$ to x86, thinking about the
  8321. first example above. Our bit-level representation of the Boolean
  8322. \code{\#f} is zero and similarly for the integer \code{0}. However,
  8323. \code{(not \#f)} should produce \code{\#t} whereas \code{(not 0)}
  8324. should produce \code{\#f}. Furthermore, the behavior of \code{not}, in
  8325. general, cannot be determined at compile time, but depends on the
  8326. runtime type of its input, as in the example above that depends on the
  8327. result of \code{(read)}.
  8328. The way around this problem is to include information about a value's
  8329. runtime type in the value itself, so that this information can be
  8330. inspected by operators such as \code{not}. In particular, we
  8331. steal the 3 right-most bits from our 64-bit values to encode the
  8332. runtime type. We use $001$ to identify integers, $100$ for
  8333. Booleans, $010$ for vectors, $011$ for procedures, and $101$ for the
  8334. void value. We refer to these 3 bits as the \emph{tag} and we
  8335. define the following auxiliary function.
  8336. \begin{align*}
  8337. \itm{tagof}(\key{Integer}) &= 001 \\
  8338. \itm{tagof}(\key{Boolean}) &= 100 \\
  8339. \itm{tagof}((\key{Vector} \ldots)) &= 010 \\
  8340. \itm{tagof}((\ldots \key{->} \ldots)) &= 011 \\
  8341. \itm{tagof}(\key{Void}) &= 101
  8342. \end{align*}
  8343. This stealing of 3 bits comes at some
  8344. price: our integers are reduced to ranging from $-2^{60}$ to
  8345. $2^{60}$. The stealing does not adversely affect vectors and
  8346. procedures because those values are addresses, and our addresses are
  8347. 8-byte aligned so the rightmost 3 bits are unused, they are always
  8348. $000$. Thus, we do not lose information by overwriting the rightmost 3
  8349. bits with the tag and we can simply zero-out the tag to recover the
  8350. original address.
  8351. In some sense, these tagged values are a new kind of value. Indeed,
  8352. we can extend our \emph{typed} language with tagged values by adding a
  8353. new type to classify them, called \key{Any}, and with operations for
  8354. creating and using tagged values, yielding the $R_6$ language that we
  8355. define in Section~\ref{sec:r6-lang}. The $R_6$ language provides the
  8356. fundamental support for polymorphism and runtime types that we need to
  8357. support dynamic typing.
  8358. There is an interesting interaction between tagged values and garbage
  8359. collection. A variable of type \code{Any} might refer to a vector and
  8360. therefore it might be a root that needs to be inspected and copied
  8361. during garbage collection. Thus, we need to treat variables of type
  8362. \code{Any} in a similar way to variables of type \code{Vector} for
  8363. purposes of register allocation, which we discuss in
  8364. Section~\ref{sec:register-allocation-r6}. One concern is that, if a
  8365. variable of type \code{Any} is spilled, it must be spilled to the root
  8366. stack. But this means that the garbage collector needs to be able to
  8367. differentiate between (1) plain old pointers to tuples, (2) a tagged
  8368. value that points to a tuple, and (3) a tagged value that is not a
  8369. tuple. We enable this differentiation by choosing not to use the tag
  8370. $000$ in $\itm{tagof}$. Instead, that bit pattern is reserved for
  8371. identifying plain old pointers to tuples. That way, if one of the
  8372. first three bits is set, then we have a tagged value and inspecting
  8373. the tag can differentiation between vectors ($010$) and the other
  8374. kinds of values.
  8375. We implement our untyped language $R_7$ by compiling it to $R_6$
  8376. (Section~\ref{sec:compile-r7}), but first we describe the $R_6$
  8377. language.
  8378. \section{The $R_6$ Language: Typed Racket $+$ \key{Any}}
  8379. \label{sec:r6-lang}
  8380. \begin{figure}[tp]
  8381. \centering
  8382. \fbox{
  8383. \begin{minipage}{0.97\textwidth}\small
  8384. \[
  8385. \begin{array}{lcl}
  8386. \Type &::=& \gray{\key{Integer} \mid \key{Boolean}
  8387. \mid \LP\key{Vector}\;\Type\ldots\RP \mid \key{Void}} \\
  8388. &\mid& \gray{\LP\Type\ldots \; \key{->}\; \Type\RP} \mid \key{Any} \\
  8389. \FType &::=& \key{Integer} \mid \key{Boolean} \mid \key{Void}
  8390. \mid \LP\key{Vector}\; \key{Any}\ldots\RP \\
  8391. &\mid& \LP\key{Any}\ldots \; \key{->}\; \key{Any}\RP\\
  8392. \Exp &::=& \ldots \CINJECT{\Exp}{\FType}\RP \mid \CPROJECT{\Exp}{\FType}\\
  8393. &\mid& \LP\key{any-vector-length}\;\Exp\RP
  8394. \mid \LP\key{any-vector-ref}\;\Exp\;\Exp\RP \\
  8395. &\mid& \LP\key{any-vector-set!}\;\Exp\;\Exp\;\Exp\RP\\
  8396. &\mid& \LP\key{boolean?}\;\Exp\RP \mid \LP\key{integer?}\;\Exp\RP
  8397. \mid \LP\key{void?}\;\Exp\RP \\
  8398. &\mid& \LP\key{vector?}\;\Exp\RP \mid \LP\key{procedure?}\;\Exp\RP \\
  8399. \Def &::=& \gray{ \CDEF{\Var}{\LS\Var \key{:} \Type\RS\ldots}{\Type}{\Exp} } \\
  8400. R_6 &::=& \gray{\Def\ldots \; \Exp}
  8401. \end{array}
  8402. \]
  8403. \end{minipage}
  8404. }
  8405. \caption{The concrete syntax of $R_6$, extending $R_5$ (Figure~\ref{fig:r5-syntax})
  8406. with \key{Any}.}
  8407. \label{fig:r6-concrete-syntax}
  8408. \end{figure}
  8409. \begin{figure}[tp]
  8410. \centering
  8411. \fbox{
  8412. \begin{minipage}{0.96\textwidth}
  8413. \small
  8414. \[
  8415. \begin{array}{lcl}
  8416. \itm{op} &::= & \ldots \mid \code{any-vector-length}
  8417. \mid \code{any-vector-ref} \mid \code{any-vector-set!}\\
  8418. &\mid& \code{boolean?} \mid \code{integer?} \mid \code{vector?}
  8419. \mid \code{procedure?} \mid \code{void?} \\
  8420. \Exp &::=& \ldots
  8421. \mid \gray{ \PRIM{\itm{op}}{\Exp\ldots} } \\
  8422. &\mid& \INJECT{\Exp}{\FType} \mid \PROJECT{\Exp}{\FType} \\
  8423. \Def &::=& \gray{ \FUNDEF{\Var}{\LP[\Var \code{:} \Type]\ldots\RP}{\Type}{\code{'()}}{\Exp} }\\
  8424. R_6 &::=& \gray{ \PROGRAMDEFSEXP{\code{'()}}{\LP\Def\ldots\RP}{\Exp} }
  8425. \end{array}
  8426. \]
  8427. \end{minipage}
  8428. }
  8429. \caption{The abstract syntax of $R_6$, extending $R_5$ (Figure~\ref{fig:r5-syntax}).}
  8430. \label{fig:r6-syntax}
  8431. \end{figure}
  8432. The concrete and abstract syntax of $R_6$ is defined in
  8433. Figures~\ref{fig:r6-concrete-syntax} and \ref{fig:r6-syntax}. The
  8434. $\LP\key{inject}\; e\; T\RP$ form converts the value produced by
  8435. expression $e$ of type $T$ into a tagged value. The
  8436. $\LP\key{project}\;e\;T\RP$ form converts the tagged value produced by
  8437. expression $e$ into a value of type $T$ or else halts the program if
  8438. the type tag is not equivalent to $T$.
  8439. %
  8440. Note that in both \key{inject} and \key{project}, the type $T$ is
  8441. restricted to the flat types $\FType$, which simplifies the
  8442. implementation and corresponds with what is needed for compiling
  8443. untyped Racket.
  8444. The \code{any-vector} operators adapt the vector operations so that
  8445. they can be applied to a value of type \code{Any}. They also
  8446. generalize the vector operations in that the index is not restricted
  8447. to be a literal integer in the grammar but is allowed to be any
  8448. expression.
  8449. The type predicates such as $\LP\key{boolean?}\,e\RP$ expect the
  8450. expression $e$ to produce a tagged value; they return \key{\#t} if the
  8451. tag corresponds to the predicate and they return \key{\#f} otherwise.
  8452. The type checker for $R_6$ is shown in
  8453. Figures~\ref{fig:type-check-R6-part-1} and
  8454. \ref{fig:type-check-R6-part-2} and uses the auxiliary functions in
  8455. Figure~\ref{fig:type-check-R6-aux}.
  8456. %
  8457. The interpreter for $R_6$ is in Figure~\ref{fig:interp-R6} and the
  8458. auxiliary function \code{apply-project} is in Figure~\ref{fig:apply-project}.
  8459. \begin{figure}[btp]
  8460. \begin{lstlisting}[basicstyle=\ttfamily\small]
  8461. (define type-check-R6-class
  8462. (class type-check-R5-class
  8463. (super-new)
  8464. (inherit check-type-equal?)
  8465. (define/override (type-check-exp env)
  8466. (lambda (e)
  8467. (define recur (type-check-exp env))
  8468. (match e
  8469. [(Inject e1 ty)
  8470. (unless (flat-ty? ty)
  8471. (error 'type-check "may only inject from flat type, not ~a" ty))
  8472. (define-values (new-e1 e-ty) (recur e1))
  8473. (check-type-equal? e-ty ty e)
  8474. (values (Inject new-e1 ty) 'Any)]
  8475. [(Project e1 ty)
  8476. (unless (flat-ty? ty)
  8477. (error 'type-check "may only project to flat type, not ~a" ty))
  8478. (define-values (new-e1 e-ty) (recur e1))
  8479. (check-type-equal? e-ty 'Any e)
  8480. (values (Project new-e1 ty) ty)]
  8481. [(Prim 'any-vector-length (list e1))
  8482. (define-values (e1^ t1) (recur e1))
  8483. (check-type-equal? t1 'Any e)
  8484. (values (Prim 'any-vector-length (list e1^)) 'Integer)]
  8485. [(Prim 'any-vector-ref (list e1 e2))
  8486. (define-values (e1^ t1) (recur e1))
  8487. (define-values (e2^ t2) (recur e2))
  8488. (check-type-equal? t1 'Any e)
  8489. (check-type-equal? t2 'Integer e)
  8490. (values (Prim 'any-vector-ref (list e1^ e2^)) 'Any)]
  8491. [(Prim 'any-vector-set! (list e1 e2 e3))
  8492. (define-values (e1^ t1) (recur e1))
  8493. (define-values (e2^ t2) (recur e2))
  8494. (define-values (e3^ t3) (recur e3))
  8495. (check-type-equal? t1 'Any e)
  8496. (check-type-equal? t2 'Integer e)
  8497. (check-type-equal? t3 'Any e)
  8498. (values (Prim 'any-vector-set! (list e1^ e2^ e3^)) 'Void)]
  8499. \end{lstlisting}
  8500. \caption{Type checker for the $R_6$ language, part 1.}
  8501. \label{fig:type-check-R6-part-1}
  8502. \end{figure}
  8503. \begin{figure}[btp]
  8504. \begin{lstlisting}[basicstyle=\ttfamily\small]
  8505. [(ValueOf e ty)
  8506. (define-values (new-e e-ty) (recur e))
  8507. (values (ValueOf new-e ty) ty)]
  8508. [(Prim pred (list e1))
  8509. #:when (set-member? (type-predicates) pred)
  8510. (define-values (new-e1 e-ty) (recur e1))
  8511. (check-type-equal? e-ty 'Any e)
  8512. (values (Prim pred (list new-e1)) 'Boolean)]
  8513. [(If cnd thn els)
  8514. (define-values (cnd^ Tc) (recur cnd))
  8515. (define-values (thn^ Tt) (recur thn))
  8516. (define-values (els^ Te) (recur els))
  8517. (check-type-equal? Tc 'Boolean cnd)
  8518. (check-type-equal? Tt Te e)
  8519. (values (If cnd^ thn^ els^) (combine-types Tt Te))]
  8520. [(Exit) (values (Exit) '_)]
  8521. [(Prim 'eq? (list arg1 arg2))
  8522. (define-values (e1 t1) (recur arg1))
  8523. (define-values (e2 t2) (recur arg2))
  8524. (match* (t1 t2)
  8525. [(`(Vector ,ts1 ...) `(Vector ,ts2 ...)) (void)]
  8526. [(other wise) (check-type-equal? t1 t2 e)])
  8527. (values (Prim 'eq? (list e1 e2)) 'Boolean)]
  8528. [else ((super type-check-exp env) e)])))
  8529. ))
  8530. \end{lstlisting}
  8531. \caption{Type checker for the $R_6$ language, part 2.}
  8532. \label{fig:type-check-R6-part-2}
  8533. \end{figure}
  8534. \begin{figure}[tbp]
  8535. \begin{lstlisting}
  8536. (define/override (operator-types)
  8537. (append
  8538. '((integer? . ((Any) . Boolean))
  8539. (vector? . ((Any) . Boolean))
  8540. (procedure? . ((Any) . Boolean))
  8541. (void? . ((Any) . Boolean))
  8542. (tag-of-any . ((Any) . Integer))
  8543. (make-any . ((_ Integer) . Any))
  8544. )
  8545. (super operator-types)))
  8546. (define/public (type-predicates)
  8547. (set 'boolean? 'integer? 'vector? 'procedure? 'void?))
  8548. (define/public (combine-types t1 t2)
  8549. (match (list t1 t2)
  8550. [(list '_ t2) t2]
  8551. [(list t1 '_) t1]
  8552. [(list `(Vector ,ts1 ...)
  8553. `(Vector ,ts2 ...))
  8554. `(Vector ,@(for/list ([t1 ts1] [t2 ts2])
  8555. (combine-types t1 t2)))]
  8556. [(list `(,ts1 ... -> ,rt1)
  8557. `(,ts2 ... -> ,rt2))
  8558. `(,@(for/list ([t1 ts1] [t2 ts2])
  8559. (combine-types t1 t2))
  8560. -> ,(combine-types rt1 rt2))]
  8561. [else t1]))
  8562. (define/public (flat-ty? ty)
  8563. (match ty
  8564. [(or `Integer `Boolean '_ `Void) #t]
  8565. [`(Vector ,ts ...) (for/and ([t ts]) (eq? t 'Any))]
  8566. [`(,ts ... -> ,rt)
  8567. (and (eq? rt 'Any) (for/and ([t ts]) (eq? t 'Any)))]
  8568. [else #f]))
  8569. \end{lstlisting}
  8570. \caption{Auxiliary methods for type checking $R_6$.}
  8571. \label{fig:type-check-R6-aux}
  8572. \end{figure}
  8573. \begin{figure}[btp]
  8574. \begin{lstlisting}
  8575. (define interp-R6-class
  8576. (class interp-R5-class
  8577. (super-new)
  8578. (define/override (interp-op op)
  8579. (match op
  8580. ['boolean? (match-lambda
  8581. [`(tagged ,v1 ,tg) (equal? tg (any-tag 'Boolean))]
  8582. [else #f])]
  8583. ['integer? (match-lambda
  8584. [`(tagged ,v1 ,tg) (equal? tg (any-tag 'Integer))]
  8585. [else #f])]
  8586. ['vector? (match-lambda
  8587. [`(tagged ,v1 ,tg) (equal? tg (any-tag `(Vector Any)))]
  8588. [else #f])]
  8589. ['procedure? (match-lambda
  8590. [`(tagged ,v1 ,tg) (equal? tg (any-tag `(Any -> Any)))]
  8591. [else #f])]
  8592. ['eq? (match-lambda*
  8593. [`((tagged ,v1^ ,tg1) (tagged ,v2^ ,tg2))
  8594. (and (eq? v1^ v2^) (equal? tg1 tg2))]
  8595. [ls (apply (super interp-op op) ls)])]
  8596. ['make-any (lambda (v tg) `(tagged ,v ,tg))]
  8597. ['tag-of-any
  8598. (match-lambda
  8599. [`(tagged ,v^ ,tg) tg]
  8600. [v (error 'interp-op "expected tagged value, not ~a" v)])]
  8601. [else (super interp-op op)]))
  8602. (define/override ((interp-exp env) e)
  8603. (define recur (interp-exp env))
  8604. (match e
  8605. [(Inject e ty) `(tagged ,(recur e) ,(any-tag ty))]
  8606. [(Project e ty2) (apply-project (recur e) ty2)]
  8607. [(ValueOf e ty)
  8608. (match (recur e)
  8609. [`(tagged ,v^ ,tg) v^]
  8610. [v (error 'interp-op "expected tagged value, not ~a" v)])]
  8611. [(Exit) (error 'interp-exp "exiting")]
  8612. [else ((super interp-exp env) e)]))
  8613. ))
  8614. (define (interp-R6 p)
  8615. (send (new interp-R6-class) interp-program p))
  8616. \end{lstlisting}
  8617. \caption{Interpreter for $R_6$.}
  8618. \label{fig:interp-R6}
  8619. \end{figure}
  8620. \begin{figure}[tbp]
  8621. \begin{lstlisting}
  8622. (define (apply-project v ty2)
  8623. (define tag2 (any-tag ty2))
  8624. (match v
  8625. [`(tagged ,v1 ,tag1)
  8626. (cond [(eq? tag1 tag2)
  8627. (match ty2
  8628. [`(Vector ,ts ...)
  8629. (cond [(eq? (vector-length v1) (length ts)) v1]
  8630. [else
  8631. (error 'apply-project
  8632. "length ~a does not match vector type length ~a"
  8633. (vector-length v1) (length ts))])]
  8634. [`(,ts ... -> ,rt)
  8635. (match v1
  8636. [`(function ,xs ,body ,env)
  8637. (cond [(eq? (length xs) (length ts)) v1]
  8638. [else
  8639. (error 'apply-project
  8640. "arity ~a does not match type arity ~a"
  8641. (length xs) (length ts))])]
  8642. [else (error 'apply-project "expected a function, not ~a" v1)])]
  8643. [else v1])]
  8644. [else (error 'apply-project "tag mismatch ~a != ~a" tag1 tag2)])]
  8645. [else (error 'apply-project "expected tagged value, not ~a" v)]))
  8646. \end{lstlisting}
  8647. \caption{Auxiliary function to apply a projection.}
  8648. \label{fig:apply-project}
  8649. \end{figure}
  8650. \clearpage
  8651. \section{Cast Insertion: Compiling $R_7$ to $R_6$}
  8652. \label{sec:compile-r7}
  8653. The \code{cast-insert} pass compiles from $R_7$ to $R_6$.
  8654. Figure~\ref{fig:compile-r7-r6} shows the compilation of many of the
  8655. $R_7$ forms into $R_6$. An important invariant of this pass is that
  8656. given a subexpression $e$ in the $R_7$ program, the pass will produce
  8657. an expression $e'$ in $R_6$ that has type \key{Any}. For example, the
  8658. first row in Figure~\ref{fig:compile-r7-r6} shows the compilation of
  8659. the Boolean \code{\#t}, which must be injected to produce an
  8660. expression of type \key{Any}.
  8661. %
  8662. The second row of Figure~\ref{fig:compile-r7-r6}, the compilation of
  8663. addition, is representative of compilation for many primitive
  8664. operations: the arguments have type \key{Any} and must be projected to
  8665. \key{Integer} before the addition can be performed.
  8666. The compilation of \key{lambda} (third row of
  8667. Figure~\ref{fig:compile-r7-r6}) shows what happens when we need to
  8668. produce type annotations: we simply use \key{Any}.
  8669. %
  8670. The compilation of \code{if} and \code{eq?} demonstrate how this pass
  8671. has to account for some differences in behavior between $R_7$ and
  8672. $R_6$. The $R_7$ language is more permissive than $R_6$ regarding what
  8673. kind of values can be used in various places. For example, the
  8674. condition of an \key{if} does not have to be a Boolean. For \key{eq?},
  8675. the arguments need not be of the same type (in that case the
  8676. result is \code{\#f}).
  8677. \begin{figure}[btp]
  8678. \centering
  8679. \begin{tabular}{|lll|} \hline
  8680. \begin{minipage}{0.27\textwidth}
  8681. \begin{lstlisting}
  8682. #t
  8683. \end{lstlisting}
  8684. \end{minipage}
  8685. &
  8686. $\Rightarrow$
  8687. &
  8688. \begin{minipage}{0.6\textwidth}
  8689. \begin{lstlisting}
  8690. (inject #t Boolean)
  8691. \end{lstlisting}
  8692. \end{minipage}
  8693. \\[2ex]\hline
  8694. \begin{minipage}{0.27\textwidth}
  8695. \begin{lstlisting}
  8696. (+ |$e_1$| |$e_2$|)
  8697. \end{lstlisting}
  8698. \end{minipage}
  8699. &
  8700. $\Rightarrow$
  8701. &
  8702. \begin{minipage}{0.6\textwidth}
  8703. \begin{lstlisting}
  8704. (inject
  8705. (+ (project |$e'_1$| Integer)
  8706. (project |$e'_2$| Integer))
  8707. Integer)
  8708. \end{lstlisting}
  8709. \end{minipage}
  8710. \\[2ex]\hline
  8711. \begin{minipage}{0.27\textwidth}
  8712. \begin{lstlisting}
  8713. (lambda (|$x_1 \ldots x_n$|) |$e$|)
  8714. \end{lstlisting}
  8715. \end{minipage}
  8716. &
  8717. $\Rightarrow$
  8718. &
  8719. \begin{minipage}{0.6\textwidth}
  8720. \begin{lstlisting}
  8721. (inject
  8722. (lambda: ([|$x_1$|:Any]|$\ldots$|[|$x_n$|:Any]):Any |$e'$|)
  8723. (Any|$\ldots$|Any -> Any))
  8724. \end{lstlisting}
  8725. \end{minipage}
  8726. \\[2ex]\hline
  8727. \begin{minipage}{0.27\textwidth}
  8728. \begin{lstlisting}
  8729. (|$e_0$| |$e_1 \ldots e_n$|)
  8730. \end{lstlisting}
  8731. \end{minipage}
  8732. &
  8733. $\Rightarrow$
  8734. &
  8735. \begin{minipage}{0.6\textwidth}
  8736. \begin{lstlisting}
  8737. ((project |$e'_0$| (Any|$\ldots$|Any -> Any)) |$e'_1 \ldots e'_n$|)
  8738. \end{lstlisting}
  8739. \end{minipage}
  8740. \\[2ex]\hline
  8741. \begin{minipage}{0.27\textwidth}
  8742. \begin{lstlisting}
  8743. (vector-ref |$e_1$| |$e_2$|)
  8744. \end{lstlisting}
  8745. \end{minipage}
  8746. &
  8747. $\Rightarrow$
  8748. &
  8749. \begin{minipage}{0.6\textwidth}
  8750. \begin{lstlisting}
  8751. (any-vector-ref |$e_1'$| |$e_2'$|)
  8752. \end{lstlisting}
  8753. \end{minipage}
  8754. \\[2ex]\hline
  8755. \begin{minipage}{0.27\textwidth}
  8756. \begin{lstlisting}
  8757. (if |$e_1$| |$e_2$| |$e_3$|)
  8758. \end{lstlisting}
  8759. \end{minipage}
  8760. &
  8761. $\Rightarrow$
  8762. &
  8763. \begin{minipage}{0.6\textwidth}
  8764. \begin{lstlisting}
  8765. (if (eq? |$e'_1$| (inject #f Boolean)) |$e'_3$| |$e'_2$|)
  8766. \end{lstlisting}
  8767. \end{minipage}
  8768. \\[2ex]\hline
  8769. \begin{minipage}{0.27\textwidth}
  8770. \begin{lstlisting}
  8771. (eq? |$e_1$| |$e_2$|)
  8772. \end{lstlisting}
  8773. \end{minipage}
  8774. &
  8775. $\Rightarrow$
  8776. &
  8777. \begin{minipage}{0.6\textwidth}
  8778. \begin{lstlisting}
  8779. (inject (eq? |$e'_1$| |$e'_2$|) Boolean)
  8780. \end{lstlisting}
  8781. \end{minipage}
  8782. \\[2ex]\hline
  8783. \end{tabular}
  8784. \caption{Cast Insertion}
  8785. \label{fig:compile-r7-r6}
  8786. \end{figure}
  8787. \section{Reveal Casts}
  8788. \label{sec:reveal-casts-r6}
  8789. % TODO: define R'_6
  8790. In the \code{reveal-casts} pass we recommend compiling \code{project}
  8791. into an \code{if} expression that checks whether the value's tag
  8792. matches the target type; if it does, the value is converted to a value
  8793. of the target type by removing the tag; if it does not, the program
  8794. exits. To perform these actions we need a new primitive operation,
  8795. \code{tag-of-any}, and two new forms, \code{ValueOf} and \code{Exit}.
  8796. The \code{tag-of-any} operation retrieves the type tag from a tagged
  8797. value of type \code{Any}. The \code{ValueOf} form retrieves the
  8798. underlying value from a tagged value. The \code{ValueOf} form
  8799. includes the type for the underlying value which is used by the type
  8800. checker. Finally, the \code{Exit} form ends the execution of the
  8801. program.
  8802. If the target type of the projection is \code{Boolean} or
  8803. \code{Integer}, then \code{Project} can be translated as follows.
  8804. \begin{center}
  8805. \begin{minipage}{1.0\textwidth}
  8806. \begin{lstlisting}
  8807. (Project |$e$| |$\FType$|)
  8808. |$\Rightarrow$|
  8809. (Let |$\itm{tmp}$| |$e'$|
  8810. (If (Prim 'eq? (list (Prim 'tag-of-any (list (Var |$\itm{tmp}$|)))
  8811. (Int |$\itm{tagof}(\FType)$|)))
  8812. (ValueOf |$\itm{tmp}$| |$\FType$|)
  8813. (Exit)))
  8814. \end{lstlisting}
  8815. \end{minipage}
  8816. \end{center}
  8817. If the target type of the projection is a vector or function type,
  8818. then there is a bit more work to do. For vectors, check that the
  8819. length of the vector type matches the length of the vector (using the
  8820. \code{vector-length} primitive). For functions, check that the number
  8821. of parameters in the function type matches the function's arity (using
  8822. \code{procedure-arity}).
  8823. Regarding \code{inject}, we recommend compiling it to a slightly
  8824. lower-level primitive operation named \code{make-any}. This operation
  8825. takes a tag instead of a type.
  8826. \begin{center}
  8827. \begin{minipage}{1.0\textwidth}
  8828. \begin{lstlisting}
  8829. (Inject |$e$| |$\FType$|)
  8830. |$\Rightarrow$|
  8831. (Prim 'make-any (list |$e'$| (Int |$\itm{tagof}(\FType)$|)))
  8832. \end{lstlisting}
  8833. \end{minipage}
  8834. \end{center}
  8835. The type predicates (\code{boolean?}, etc.) can be translated into
  8836. uses of \code{tag-of-any} and \code{eq?} in a similar way as in the
  8837. translation of \code{Project}.
  8838. The \code{any-vector-ref} and \code{any-vector-set!} operations
  8839. combine the projection action with the vector operation. Also, the
  8840. read and write operations allow arbitrary expressions for the index so
  8841. the type checker for $R_6$ (Figure~\ref{fig:type-check-R6-part-1})
  8842. cannot guarantee that the index is within bounds. Thus, we insert code
  8843. to perform bounds checking at runtime. The translation for
  8844. \code{any-vector-ref} is as follows and the other two operations are
  8845. translated in a similar way.
  8846. \begin{lstlisting}
  8847. (Prim 'any-vector-ref (list |$e_1$| |$e_2$|))
  8848. |$\Rightarrow$|
  8849. (Let |$v$| |$e'_1$|
  8850. (Let |$i$| |$e'_2$|
  8851. (If (Prim 'eq? (list (Prim 'tag-of-any (list (Var |$v$|))) (Int 2)))
  8852. (If (Prim '< (list (Var |$i$|)
  8853. (Prim 'any-vector-length (list (Var |$v$|)))))
  8854. (Prim 'any-vector-ref (list (Var |$v$|) (Var |$i$|)))
  8855. (Exit))))
  8856. \end{lstlisting}
  8857. \section{Remove Complex Operands}
  8858. \label{sec:rco-r6}
  8859. The \code{ValueOf} and \code{Exit} forms are both complex expressions.
  8860. The subexpression of \code{ValueOf} must be atomic.
  8861. \section{Explicate Control and $C_5$}
  8862. \label{sec:explicate-r6}
  8863. The output of \code{explicate-control} is the $C_5$ language whose
  8864. syntax is defined in Figure~\ref{fig:c5-syntax}. The \code{ValueOf}
  8865. form that we added to $R_6$ remains an expression and the \code{Exit}
  8866. expression becomes a $\Tail$. Also, note that the index argument of
  8867. \code{vector-ref} and \code{vector-set!} is an $\Atm$ instead
  8868. of an integer, as in $C_2$ (Figure~\ref{fig:c2-syntax}).
  8869. \begin{figure}[tp]
  8870. \fbox{
  8871. \begin{minipage}{0.96\textwidth}
  8872. \small
  8873. \[
  8874. \begin{array}{lcl}
  8875. \Exp &::= & \ldots
  8876. \mid \BINOP{\key{'vector-ref}}{\Atm}{\Atm} \\
  8877. &\mid& (\key{Prim}~\key{'vector-set!}\,(\key{list}\,\Atm\,\Atm\,\Atm))
  8878. \mid \VALUEOF{\Exp}{\FType} \\
  8879. \Stmt &::=& \gray{ \ASSIGN{\VAR{\Var}}{\Exp}
  8880. \mid \LP\key{Collect} \,\itm{int}\RP }\\
  8881. \Tail &::= & \gray{ \RETURN{\Exp} \mid \SEQ{\Stmt}{\Tail}
  8882. \mid \GOTO{\itm{label}} } \\
  8883. &\mid& \gray{ \IFSTMT{\BINOP{\itm{cmp}}{\Atm}{\Atm}}{\GOTO{\itm{label}}}{\GOTO{\itm{label}}} }\\
  8884. &\mid& \gray{ \TAILCALL{\Atm}{\Atm\ldots} }
  8885. \mid \LP\key{Exit}\RP \\
  8886. \Def &::=& \gray{ \DEF{\itm{label}}{\LP[\Var\key{:}\Type]\ldots\RP}{\Type}{\itm{info}}{\LP\LP\itm{label}\,\key{.}\,\Tail\RP\ldots\RP} }\\
  8887. C_4 & ::= & \gray{ \PROGRAMDEFS{\itm{info}}{\LP\Def\ldots\RP} }
  8888. \end{array}
  8889. \]
  8890. \end{minipage}
  8891. }
  8892. \caption{The abstract syntax of $C_5$, extending $C_4$ (Figure~\ref{fig:c4-syntax}).}
  8893. \label{fig:c5-syntax}
  8894. \end{figure}
  8895. \section{Select Instructions}
  8896. \label{sec:select-r6}
  8897. \paragraph{Vector-ref}
  8898. Recall that instruction selection for \code{vector-ref} in
  8899. Section~\ref{sec:select-instructions-gc} depends on knowing the index $n$
  8900. at compile time:
  8901. \begin{lstlisting}
  8902. (Assign |$\itm{lhs}$| (Prim 'vector-ref (list |$a_1$| (Int |$n$|))))
  8903. |$\Longrightarrow$|
  8904. movq |$a_1'$|, %r11
  8905. movq |$\itm{offset}$|(%r11), |$\itm{lhs'}$|
  8906. \end{lstlisting}
  8907. where $\itm{offset} = 8(n+1)$.
  8908. %
  8909. In $R_6$ the index may be an arbitrary atom so instead of
  8910. computing the offset at compile time, instructions need to be
  8911. generated to compute the offset at runtime as follows. Note the use of
  8912. the new instruction \code{imulq}.
  8913. \begin{center}
  8914. \begin{minipage}{0.96\textwidth}
  8915. \begin{lstlisting}
  8916. (Assign |$\itm{lhs}$| (Prim 'vector-ref (list |$a_1$| |$a_2$|)))
  8917. |$\Longrightarrow$|
  8918. movq |$a_2'$|, %r11
  8919. addq $1, %r11
  8920. imulq $8, %r11
  8921. addq |$a_1'$|, %r11
  8922. movq 0(%r11) |$\itm{lhs'}$|
  8923. \end{lstlisting}
  8924. \end{minipage}
  8925. \end{center}
  8926. \paragraph{Vector-set!}
  8927. The above issue also applies to \code{vector-set!}. The index may be
  8928. an arbitrary expression so one must generate instructions to compute
  8929. the offset at runtime.
  8930. %% The same idea applies to `vector-set!`.
  8931. \paragraph{Make-any}
  8932. We recommend compiling the \key{make-any} primitive as follows if the
  8933. tag is for \key{Integer} or \key{Boolean}. The \key{salq} instruction
  8934. shifts the destination to the left by the number of bits specified its
  8935. source argument (in this case $3$, the length of the tag) and it
  8936. preserves the sign of the integer. We use the \key{orq} instruction to
  8937. combine the tag and the value to form the tagged value. \\
  8938. \begin{lstlisting}
  8939. (Assign |\itm{lhs}| (Prim 'make-any (list |$e$| (Int |$\itm{tag}$|))))
  8940. |$\Rightarrow$|
  8941. movq |$e'$|, |\itm{lhs'}|
  8942. salq $3, |\itm{lhs'}|
  8943. orq $|$\itm{tag}$|, |\itm{lhs'}|
  8944. \end{lstlisting}
  8945. The instruction selection for vectors and procedures is different
  8946. because their is no need to shift them to the left. The rightmost 3
  8947. bits are already zeros as described at the beginning of this
  8948. chapter. So we just combine the value and the tag using \key{orq}. \\
  8949. \begin{lstlisting}
  8950. (Assign |\itm{lhs}| (Prim 'make-any (list |$e$| (Int |$\itm{tag}$|))))
  8951. |$\Rightarrow$|
  8952. movq |$e'$|, |\itm{lhs'}|
  8953. orq $|$\itm{tag}$|, |\itm{lhs'}|
  8954. \end{lstlisting}
  8955. \paragraph{Tag-of-any}
  8956. Recall that the \code{tag-of-any} operation extracts the type tag from
  8957. a value of type \code{Any}. The type tag is the bottom three bits, so
  8958. we obtain the tag by taking the bitwise-and of the value with $111$
  8959. ($7$ in decimal).
  8960. \begin{lstlisting}
  8961. (Assign |\itm{lhs}| (Prim 'tag-of-any (list |$e$|)))
  8962. |$\Rightarrow$|
  8963. movq |$e'$|, |\itm{lhs'}|
  8964. andq $7, |\itm{lhs'}|
  8965. \end{lstlisting}
  8966. \paragraph{ValueOf}
  8967. Like \key{make-any}, the instructions for \key{ValueOf} are different
  8968. depending on whether the type $T$ is a pointer (vector or procedure)
  8969. or not (Integer or Boolean). The following shows the instruction
  8970. selection for Integer and Boolean. We produce an untagged value by
  8971. shifting it to the right by 3 bits.
  8972. \begin{lstlisting}
  8973. (Assign |\itm{lhs}| (ValueOf |$e$| |$T$|))
  8974. |$\Rightarrow$|
  8975. movq |$e'$|, |\itm{lhs'}|
  8976. sarq $3, |\itm{lhs'}|
  8977. \end{lstlisting}
  8978. %
  8979. In the case for vectors and procedures, there is no need to
  8980. shift. Instead we just need to zero-out the rightmost 3 bits. We
  8981. accomplish this by creating the bit pattern $\ldots 0111$ ($7$ in
  8982. decimal) and apply \code{bitwise-not} to obtain $\ldots 11111000$ (-8
  8983. in decimal) which we \code{movq} into the destination $\itm{lhs}$. We
  8984. then apply \code{andq} with the tagged value to get the desired
  8985. result. \\
  8986. \begin{lstlisting}
  8987. (Assign |\itm{lhs}| (ValueOf |$e$| |$T$|))
  8988. |$\Rightarrow$|
  8989. movq $|$-8$|, |\itm{lhs'}|
  8990. andq |$e'$|, |\itm{lhs'}|
  8991. \end{lstlisting}
  8992. %% \paragraph{Type Predicates} We leave it to the reader to
  8993. %% devise a sequence of instructions to implement the type predicates
  8994. %% \key{boolean?}, \key{integer?}, \key{vector?}, and \key{procedure?}.
  8995. \section{Register Allocation for $R_6$}
  8996. \label{sec:register-allocation-r6}
  8997. \index{register allocation}
  8998. At the beginning of this chapter we discussed how a variable of type
  8999. \code{Any} might refer to a vector. Thus, the register allocator for
  9000. $R_6$ needs to treat variable of type \code{Any} in the same way that
  9001. it treats variables of type \code{Vector} for purposes of garbage
  9002. collection. In particular,
  9003. \begin{itemize}
  9004. \item If a variable of type \code{Any} is live during a function call,
  9005. then it must be spilled. One way to accomplish this is to augment
  9006. \code{build-interference} to mark all variables that are live after
  9007. a \code{callq} as interfering with all the registers.
  9008. \item If a variable of type \code{Any} is spilled, it must be spilled
  9009. to the root stack instead of the normal procedure call stack.
  9010. \end{itemize}
  9011. \begin{exercise}\normalfont
  9012. Expand your compiler to handle $R_6$ as discussed in the last few
  9013. sections. Create 5 new programs that use the \code{Any} type and the
  9014. new operations (\code{inject}, \code{project}, \code{boolean?},
  9015. etc.). Test your compiler on these new programs and all of your
  9016. previously created test programs.
  9017. \end{exercise}
  9018. \begin{exercise}\normalfont
  9019. Expand your compiler to handle $R_7$ as outlined in this chapter.
  9020. Create tests for $R_7$ by adapting ten of your previous test programs
  9021. by removing type annotations. Add 5 more tests programs that
  9022. specifically rely on the language being dynamically typed. That is,
  9023. they should not be legal programs in a statically typed language, but
  9024. nevertheless, they should be valid $R_7$ programs that run to
  9025. completion without error.
  9026. \end{exercise}
  9027. \begin{figure}[p]
  9028. \begin{tikzpicture}[baseline=(current bounding box.center)]
  9029. \node (R4) at (0,4) {\large $R_7$};
  9030. \node (R4-2) at (3,4) {\large $R_7$};
  9031. \node (R4-3) at (6,4) {\large $R_7$};
  9032. \node (R4-4) at (9,4) {\large $R'_7$};
  9033. \node (R4-5) at (9,2) {\large $R'_6$};
  9034. \node (R4-6) at (12,2) {\large $R'_6$};
  9035. \node (R4-7) at (12,0) {\large $R'_6$};
  9036. \node (F1-2) at (9,0) {\large $R'_6$};
  9037. \node (F1-3) at (6,0) {\large $R'_6$};
  9038. \node (F1-4) at (3,0) {\large $R'_6$};
  9039. \node (F1-5) at (0,0) {\large $R'_6$};
  9040. \node (C3-2) at (3,-2) {\large $C_3$};
  9041. \node (x86-2) at (3,-4) {\large $\text{x86}^{*}_3$};
  9042. \node (x86-3) at (6,-4) {\large $\text{x86}^{*}_3$};
  9043. \node (x86-4) at (9,-4) {\large $\text{x86}^{*}_3$};
  9044. \node (x86-5) at (9,-6) {\large $\text{x86}^{\dagger}_3$};
  9045. \node (x86-2-1) at (3,-6) {\large $\text{x86}^{*}_3$};
  9046. \node (x86-2-2) at (6,-6) {\large $\text{x86}^{*}_3$};
  9047. \path[->,bend left=15] (R4) edge [above] node
  9048. {\ttfamily\footnotesize shrink} (R4-2);
  9049. \path[->,bend left=15] (R4-2) edge [above] node
  9050. {\ttfamily\footnotesize uniquify} (R4-3);
  9051. \path[->,bend left=15] (R4-3) edge [above] node
  9052. {\ttfamily\footnotesize reveal-functions} (R4-4);
  9053. \path[->,bend right=15] (R4-4) edge [left] node
  9054. {\ttfamily\footnotesize cast-insert} (R4-5);
  9055. \path[->,bend left=15] (R4-5) edge [above] node
  9056. {\ttfamily\footnotesize check-bounds} (R4-6);
  9057. \path[->,bend left=15] (R4-6) edge [left] node
  9058. {\ttfamily\footnotesize reveal-casts} (R4-7);
  9059. \path[->,bend left=15] (R4-7) edge [below] node
  9060. {\ttfamily\footnotesize convert-to-clos.} (F1-2);
  9061. \path[->,bend right=15] (F1-2) edge [above] node
  9062. {\ttfamily\footnotesize limit-fun.} (F1-3);
  9063. \path[->,bend right=15] (F1-3) edge [above] node
  9064. {\ttfamily\footnotesize expose-alloc.} (F1-4);
  9065. \path[->,bend right=15] (F1-4) edge [above] node
  9066. {\ttfamily\footnotesize remove-complex.} (F1-5);
  9067. \path[->,bend right=15] (F1-5) edge [right] node
  9068. {\ttfamily\footnotesize explicate-control} (C3-2);
  9069. \path[->,bend left=15] (C3-2) edge [left] node
  9070. {\ttfamily\footnotesize select-instr.} (x86-2);
  9071. \path[->,bend right=15] (x86-2) edge [left] node
  9072. {\ttfamily\footnotesize uncover-live} (x86-2-1);
  9073. \path[->,bend right=15] (x86-2-1) edge [below] node
  9074. {\ttfamily\footnotesize build-inter.} (x86-2-2);
  9075. \path[->,bend right=15] (x86-2-2) edge [left] node
  9076. {\ttfamily\footnotesize allocate-reg.} (x86-3);
  9077. \path[->,bend left=15] (x86-3) edge [above] node
  9078. {\ttfamily\footnotesize patch-instr.} (x86-4);
  9079. \path[->,bend left=15] (x86-4) edge [right] node
  9080. {\ttfamily\footnotesize print-x86} (x86-5);
  9081. \end{tikzpicture}
  9082. \caption{Diagram of the passes for $R_7$, a dynamically typed language.}
  9083. \label{fig:R7-passes}
  9084. \end{figure}
  9085. Figure~\ref{fig:R7-passes} provides an overview of all the passes needed
  9086. for the compilation of $R_7$.
  9087. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  9088. \chapter{Loops and Assignment}
  9089. \label{ch:loop}
  9090. In this chapter we study two features that are the hallmarks of
  9091. imperative programming languages: loops and assignments to local
  9092. variables. The following example demonstrates these new features by
  9093. computing the sum of the first five positive integers.
  9094. % similar to loop_test_1.rkt
  9095. \begin{lstlisting}
  9096. (let ([sum 0])
  9097. (let ([i 5])
  9098. (begin
  9099. (while (> i 0)
  9100. (begin
  9101. (set! sum (+ sum i))
  9102. (set! i (- i 1))))
  9103. sum)))
  9104. \end{lstlisting}
  9105. The \code{while} loop consists of a condition and a body.
  9106. %
  9107. The \code{set!} consists of a variable and a right-hand-side expression.
  9108. %
  9109. The primary purpose of both the \code{while} loop and \code{set!} is
  9110. to cause side effects, so it is convenient to also include in $R_8$ a
  9111. language feature for sequencing side effects: the \code{begin}
  9112. expression. It consists of one or more subexpressions that are
  9113. evaluated left-to-right.
  9114. %
  9115. The concrete syntax of $R_8$ is defined in
  9116. Figure~\ref{fig:r8-concrete-syntax} and its abstract syntax is defined
  9117. in Figure~\ref{fig:r8-syntax}.
  9118. \begin{figure}[tp]
  9119. \centering
  9120. \fbox{
  9121. \begin{minipage}{0.96\textwidth}
  9122. \small
  9123. \[
  9124. \begin{array}{lcl}
  9125. \Exp &::=& \gray{ \Int \mid \CREAD{} \mid \CNEG{\Exp}
  9126. \mid \CADD{\Exp}{\Exp} \mid \CSUB{\Exp}{\Exp} } \\
  9127. &\mid& \gray{ \Var \mid \CLET{\Var}{\Exp}{\Exp} }\\
  9128. &\mid& \gray{\key{\#t} \mid \key{\#f}
  9129. \mid (\key{and}\;\Exp\;\Exp)
  9130. \mid (\key{or}\;\Exp\;\Exp)
  9131. \mid (\key{not}\;\Exp) } \\
  9132. &\mid& \gray{ (\key{eq?}\;\Exp\;\Exp) \mid \CIF{\Exp}{\Exp}{\Exp} } \\
  9133. &\mid& \gray{ (\key{vector}\;\Exp\ldots) \mid
  9134. (\key{vector-ref}\;\Exp\;\Int)} \\
  9135. &\mid& \gray{(\key{vector-set!}\;\Exp\;\Int\;\Exp)\mid (\key{void})
  9136. \mid (\Exp \; \Exp\ldots) } \\
  9137. &\mid& \gray{ \LP \key{procedure-arity}~\Exp\RP
  9138. \mid \CLAMBDA{\LP\LS\Var \key{:} \Type\RS\ldots\RP}{\Type}{\Exp} } \\
  9139. &\mid& \CSETBANG{\Var}{\Exp}
  9140. \mid \CBEGIN{\Exp\ldots}{\Exp}
  9141. \mid \CWHILE{\Exp}{\Exp} \\
  9142. \Def &::=& \gray{ \CDEF{\Var}{\LS\Var \key{:} \Type\RS\ldots}{\Type}{\Exp} } \\
  9143. R_8 &::=& \gray{\Def\ldots \; \Exp}
  9144. \end{array}
  9145. \]
  9146. \end{minipage}
  9147. }
  9148. \caption{The concrete syntax of $R_8$, extending $R_6$ (Figure~\ref{fig:r6-concrete-syntax}).}
  9149. \label{fig:r8-concrete-syntax}
  9150. \end{figure}
  9151. \begin{figure}[tp]
  9152. \centering
  9153. \fbox{
  9154. \begin{minipage}{0.96\textwidth}
  9155. \small
  9156. \[
  9157. \begin{array}{lcl}
  9158. \Exp &::=& \gray{ \INT{\Int} \VAR{\Var} \mid \LET{\Var}{\Exp}{\Exp} } \\
  9159. &\mid& \gray{ \PRIM{\itm{op}}{\Exp\ldots} }\\
  9160. &\mid& \gray{ \BOOL{\itm{bool}}
  9161. \mid \IF{\Exp}{\Exp}{\Exp} } \\
  9162. &\mid& \gray{ \VOID{} \mid \LP\key{HasType}~\Exp~\Type \RP
  9163. \mid \APPLY{\Exp}{\Exp\ldots} }\\
  9164. &\mid& \gray{ \LAMBDA{\LP\LS\Var\code{:}\Type\RS\ldots\RP}{\Type}{\Exp} }\\
  9165. &\mid& \SETBANG{\Var}{\Exp} \mid \BEGIN{\LP\Exp\ldots\RP}{\Exp}
  9166. \mid \WHILE{\Exp}{\Exp} \\
  9167. \Def &::=& \gray{ \FUNDEF{\Var}{\LP\LS\Var \code{:} \Type\RS\ldots\RP}{\Type}{\code{'()}}{\Exp} }\\
  9168. R_8 &::=& \gray{ \PROGRAMDEFSEXP{\code{'()}}{\LP\Def\ldots\RP}{\Exp} }
  9169. \end{array}
  9170. \]
  9171. \end{minipage}
  9172. }
  9173. \caption{The abstract syntax of $R_8$, extending $R_6$ (Figure~\ref{fig:r6-syntax}).}
  9174. \label{fig:r8-syntax}
  9175. \end{figure}
  9176. The definitional interpreter for $R_8$ is shown in
  9177. Figure~\ref{fig:interp-R8}. We add three new cases for \code{SetBang},
  9178. \code{WhileLoop}, and \code{Begin} and we make changes to the cases
  9179. for \code{Var}, \code{Let}, and \code{Apply} regarding variables. To
  9180. support assignment to variables and to make their lifetimes indefinite
  9181. (see the second example in Section~\ref{sec:assignment-scoping}), we
  9182. box the value that is bound to each variable (in \code{Let}) and
  9183. function parameter (in \code{Apply}). The case for \code{Var} unboxes
  9184. the value.
  9185. %
  9186. Now to discuss the new cases. For \code{SetBang}, we lookup the
  9187. variable in the environment to obtain a boxed value and then we change
  9188. it using \code{set-box!} to the result of evaluating the right-hand
  9189. side. The result value of a \code{SetBang} is \code{void}.
  9190. %
  9191. For the \code{WhileLoop}, we repeatedly 1) evaluate the condition, and
  9192. if the result is true, 2) evaluate the body.
  9193. The result value of a \code{while} loop is also \code{void}.
  9194. %
  9195. Finally, the $\BEGIN{\itm{es}}{\itm{body}}$ expression evaluates the
  9196. subexpressions \itm{es} for their effects and then evaluates
  9197. and returns the result from \itm{body}.
  9198. \begin{figure}[tbp]
  9199. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  9200. (define interp-R8-class
  9201. (class interp-R6-class
  9202. (super-new)
  9203. (define/override ((interp-exp env) e)
  9204. (define recur (interp-exp env))
  9205. (match e
  9206. [(SetBang x rhs)
  9207. (set-box! (lookup x env) (recur rhs))]
  9208. [(WhileLoop cnd body)
  9209. (define (loop)
  9210. (cond [(recur cnd) (recur body) (loop)]
  9211. [else (void)]))
  9212. (loop)]
  9213. [(Begin es body)
  9214. (for ([e es]) (recur e))
  9215. (recur body)]
  9216. [else ((super interp-exp env) e)]))
  9217. ))
  9218. (define (interp-R8 p)
  9219. (send (new interp-R8-class) interp-program p))
  9220. \end{lstlisting}
  9221. \caption{Interpreter for $R_8$.}
  9222. \label{fig:interp-R8}
  9223. \end{figure}
  9224. The type checker for $R_8$ is define in
  9225. Figure~\ref{fig:type-check-R8}. For \code{SetBang}, the type of the
  9226. variable and the right-hand-side must agree. The result type is
  9227. \code{Void}. For the \code{WhileLoop}, the condition must be a
  9228. \code{Boolean}. The result type is also \code{Void}. For
  9229. \code{Begin}, the result type is the type of its last subexpression.
  9230. \begin{figure}[tbp]
  9231. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  9232. (define type-check-R8-class
  9233. (class type-check-R6-class
  9234. (super-new)
  9235. (inherit check-type-equal?)
  9236. (define/override (type-check-exp env)
  9237. (lambda (e)
  9238. (define recur (type-check-exp env))
  9239. (match e
  9240. [(SetBang x rhs)
  9241. (define-values (rhs^ rhsT) (recur rhs))
  9242. (define varT (dict-ref env x))
  9243. (check-type-equal? rhsT varT e)
  9244. (values (SetBang x rhs^) 'Void)]
  9245. [(WhileLoop cnd body)
  9246. (define-values (cnd^ Tc) (recur cnd))
  9247. (check-type-equal? Tc 'Boolean e)
  9248. (define-values (body^ Tbody) ((type-check-exp env) body))
  9249. (values (WhileLoop cnd^ body^) 'Void)]
  9250. [(Begin es body)
  9251. (define-values (es^ ts)
  9252. (for/lists (l1 l2) ([e es]) (recur e)))
  9253. (define-values (body^ Tbody) (recur body))
  9254. (values (Begin es^ body^) Tbody)]
  9255. [else ((super type-check-exp env) e)])))
  9256. ))
  9257. (define (type-check-R8 p)
  9258. (send (new type-check-R8-class) type-check-program p))
  9259. \end{lstlisting}
  9260. \caption{Type checking \key{SetBang}, \key{WhileLoop},
  9261. and \code{Begin} in $R_8$.}
  9262. \label{fig:type-check-R8}
  9263. \end{figure}
  9264. At first glance, the translation of these language features to x86
  9265. seems straightforward because the $C_3$ intermediate language already
  9266. supports all of the ingredients that we need: assignment, \code{goto},
  9267. conditional branching, and sequencing. However, there are two
  9268. complications that arise which we discuss in the next two
  9269. sections. After that we introduce one new compiler pass and the
  9270. changes necessary to the existing passes.
  9271. \section{Assignment and Lexically Scoped Functions}
  9272. \label{sec:assignment-scoping}
  9273. The addition of assignment raises a problem with our approach to
  9274. implementing lexically-scoped functions. Consider the following
  9275. example in which function \code{f} has a free variable \code{x} that
  9276. is changed after \code{f} is created but before the call to \code{f}.
  9277. % loop_test_11.rkt
  9278. \begin{lstlisting}
  9279. (let ([x 0])
  9280. (let ([y 0])
  9281. (let ([z 20])
  9282. (let ([f (lambda: ([a : Integer]) : Integer (+ a (+ x z)))])
  9283. (begin
  9284. (set! x 10)
  9285. (set! y 12)
  9286. (f y))))))
  9287. \end{lstlisting}
  9288. The correct output for this example is \code{42} because the call to
  9289. \code{f} is required to use the current value of \code{x} (which is
  9290. \code{10}). Unfortunately, the closure conversion pass
  9291. (Section~\ref{sec:closure-conversion}) generates code for the
  9292. \code{lambda} that copies the old value of \code{x} into a
  9293. closure. Thus, if we naively add support for assignment to our current
  9294. compiler, the output of this program would be \code{32}.
  9295. A first attempt at solving this problem would be to save a pointer to
  9296. \code{x} in the closure and change the occurrences of \code{x} inside
  9297. the lambda to dereference the pointer. Of course, this would require
  9298. assigning \code{x} to the stack and not to a register. However, the
  9299. problem goes a bit deeper. Consider the following example in which we
  9300. create a counter abstraction by creating a pair of functions that
  9301. share the free variable \code{x}.
  9302. % similar to loop_test_10.rkt
  9303. \begin{lstlisting}
  9304. (define (f [x : Integer]) : (Vector ( -> Integer) ( -> Void))
  9305. (vector
  9306. (lambda: () : Integer x)
  9307. (lambda: () : Void (set! x (+ 1 x)))))
  9308. (let ([counter (f 0)])
  9309. (let ([get (vector-ref counter 0)])
  9310. (let ([inc (vector-ref counter 1)])
  9311. (begin
  9312. (inc)
  9313. (get)))))
  9314. \end{lstlisting}
  9315. In this example, the lifetime of \code{x} extends beyond the lifetime
  9316. of the call to \code{f}. Thus, if we were to store \code{x} on the
  9317. stack frame for the call to \code{f}, it would be gone by the time we
  9318. call \code{inc} and \code{get}, leaving us with dangling pointers for
  9319. \code{x}. This example demonstrates that when a variable occurs free
  9320. inside a \code{lambda}, its lifetime becomes indefinite. Thus, the
  9321. value of the variable needs to live on the heap. The verb ``box'' is
  9322. often used for allocating a single value on the heap, producing a
  9323. pointer, and ``unbox'' for dereferencing the pointer.
  9324. We recommend solving these problems by ``boxing'' the local variables
  9325. that are in the intersection of 1) variables that appear on the
  9326. left-hand-side of a \code{set!} and 2) variables that occur free
  9327. inside a \code{lambda}. We shall introduce a new pass named
  9328. \code{convert-assignments} in Section~\ref{sec:convert-assignments} to
  9329. perform this translation. But before diving into the compiler passes,
  9330. we one more problem to discuss.
  9331. \section{Cyclic Control Flow and Dataflow Analysis}
  9332. \label{sec:dataflow-analysis}
  9333. Up until this point the control-flow graphs generated in
  9334. \code{explicate-control} were guaranteed to be acyclic. However, each
  9335. \code{while} loop introduces a cycle in the control-flow graph.
  9336. But does that matter?
  9337. %
  9338. Indeed it does. Recall that for register allocation, the compiler
  9339. performs liveness analysis to determine which variables can share the
  9340. same register. In Section~\ref{sec:liveness-analysis-r2} we analyze
  9341. the control-flow graph in reverse topological order, but topological
  9342. order is only well-defined for acyclic graphs.
  9343. Let us return to the example of computing the sum of the first five
  9344. positive integers. Here is the program after instruction selection but
  9345. before register allocation.
  9346. \begin{center}
  9347. \begin{minipage}{0.45\textwidth}
  9348. \begin{lstlisting}
  9349. (define (main) : Integer
  9350. mainstart:
  9351. movq $0, sum1
  9352. movq $5, i2
  9353. jmp block5
  9354. block5:
  9355. movq i2, tmp3
  9356. cmpq tmp3, $0
  9357. jl block7
  9358. jmp block8
  9359. \end{lstlisting}
  9360. \end{minipage}
  9361. \begin{minipage}{0.45\textwidth}
  9362. \begin{lstlisting}
  9363. block7:
  9364. addq i2, sum1
  9365. movq $1, tmp4
  9366. negq tmp4
  9367. addq tmp4, i2
  9368. jmp block5
  9369. block8:
  9370. movq $27, %rax
  9371. addq sum1, %rax
  9372. jmp mainconclusion
  9373. )
  9374. \end{lstlisting}
  9375. \end{minipage}
  9376. \end{center}
  9377. Recall that liveness analysis works backwards, starting at the end
  9378. of each function. For this example we could start with \code{block8}
  9379. because we know what is live at the beginning of the conclusion,
  9380. just \code{rax} and \code{rsp}. So the live-before set
  9381. for \code{block8} is $\{\ttm{rsp},\ttm{sum1}\}$.
  9382. %
  9383. Next we might try to analyze \code{block5} or \code{block7}, but
  9384. \code{block5} jumps to \code{block7} and vice versa, so it seems that
  9385. we are stuck.
  9386. The way out of this impasse comes from the realization that one can
  9387. perform liveness analysis starting with an empty live-after set to
  9388. compute an under-approximation of the live-before set. By
  9389. \emph{under-approximation}, we mean that the set only contains
  9390. variables that are really live, but it may be missing some. Next, the
  9391. under-approximations for each block can be improved by 1) updating the
  9392. live-after set for each block using the approximate live-before sets
  9393. from the other blocks and 2) perform liveness analysis again on each
  9394. block. In fact, by iterating this process, the under-approximations
  9395. eventually become the correct solutions!
  9396. %
  9397. This approach of iteratively analyzing a control-flow graph is
  9398. applicable to many static analysis problems and goes by the name
  9399. \emph{dataflow analysis}\index{dataflow analysis}. It was invented by
  9400. \citet{Kildall:1973vn} in his Ph.D. thesis at the University of
  9401. Washington.
  9402. Let us apply this approach to the above example. We use the empty set
  9403. for the initial live-before set for each block. Let $m_0$ be the
  9404. following mapping from label names to sets of locations (variables and
  9405. registers).
  9406. \begin{center}
  9407. \begin{lstlisting}
  9408. mainstart: {}
  9409. block5: {}
  9410. block7: {}
  9411. block8: {}
  9412. \end{lstlisting}
  9413. \end{center}
  9414. Using the above live-before approximations, we determine the
  9415. live-after for each block and then apply liveness analysis to each
  9416. block. This produces our next approximation $m_1$ of the live-before
  9417. sets.
  9418. \begin{center}
  9419. \begin{lstlisting}
  9420. mainstart: {}
  9421. block5: {i2}
  9422. block7: {i2, sum1}
  9423. block8: {rsp, sum1}
  9424. \end{lstlisting}
  9425. \end{center}
  9426. For the second round, the live-after for \code{mainstart} is the
  9427. current live-before for \code{block5}, which is \code{\{i2\}}. So the
  9428. liveness analysis for \code{mainstart} computes the empty set. The
  9429. live-after for \code{block5} is the union of the live-before sets for
  9430. \code{block7} and \code{block8}, which is \code{\{i2 , rsp, sum1\}}.
  9431. So the liveness analysis for \code{block5} computes \code{\{i2 , rsp,
  9432. sum1\}}. The live-after for \code{block7} is the live-before for
  9433. \code{block5} (from the previous iteration), which is \code{\{i2\}}.
  9434. So the liveness analysis for \code{block7} remains \code{\{i2,
  9435. sum1\}}. Together these yield the following approximation $m_2$ of
  9436. the live-before sets.
  9437. \begin{center}
  9438. \begin{lstlisting}
  9439. mainstart: {}
  9440. block5: {i2, rsp, sum1}
  9441. block7: {i2, sum1}
  9442. block8: {rsp, sum1}
  9443. \end{lstlisting}
  9444. \end{center}
  9445. In the preceding iteration, only \code{block5} changed, so we can
  9446. limit our attention to \code{mainstart} and \code{block7}, the two
  9447. blocks that jump to \code{block5}. As a result, the live-before sets
  9448. for \code{mainstart} and \code{block7} are updated to include
  9449. \code{rsp}, yielding the following approximation $m_3$.
  9450. \begin{center}
  9451. \begin{lstlisting}
  9452. mainstart: {rsp}
  9453. block5: {i2, rsp, sum1}
  9454. block7: {i2, rsp, sum1}
  9455. block8: {rsp, sum1}
  9456. \end{lstlisting}
  9457. \end{center}
  9458. Because \code{block7} changed, we analyze \code{block5} once more, but
  9459. its live-before set remains \code{\{ i2, rsp, sum1 \}}. At this point
  9460. our approximations have converged, so $m_3$ is the solution.
  9461. This iteration process is guaranteed to converge to a solution by the
  9462. Kleene Fixed-Point Theorem, a general theorem about functions on
  9463. lattices~\citep{Kleene:1952aa}. Roughly speaking, a \emph{lattice} is
  9464. any collection that comes with a partial ordering $\sqsubseteq$ on its
  9465. elements, a least element $\bot$ (pronounced bottom), and a join
  9466. operator $\sqcup$.\index{lattice}\index{bottom}\index{partial
  9467. ordering}\index{join}\footnote{Technically speaking, we will be
  9468. working with join semi-lattices.} When two elements are ordered $m_i
  9469. \sqsubseteq m_j$, it means that $m_j$ contains at least as much
  9470. information as $m_i$, so we can think of $m_j$ as a better-or-equal
  9471. approximation than $m_i$. The bottom element $\bot$ represents the
  9472. complete lack of information, i.e., the worst approximation. The join
  9473. operator takes two lattice elements and combines their information,
  9474. i.e., it produces the least upper bound of the two.\index{least upper
  9475. bound}
  9476. A dataflow analysis typically involves two lattices: one lattice to
  9477. represent abstract states and another lattice that aggregates the
  9478. abstract states of all the blocks in the control-flow graph. For
  9479. liveness analysis, an abstract state is a set of locations. We form
  9480. the lattice $L$ by taking its elements to be sets of locations, the
  9481. ordering to be set inclusion ($\subseteq$), the bottom to be the empty
  9482. set, and the join operator to be set union.
  9483. %
  9484. We form a second lattice $M$ by taking its elements to be mappings
  9485. from the block labels to sets of locations (elements of $L$). We
  9486. order the mappings point-wise, using the ordering of $L$. So given any
  9487. two mappings $m_i$ and $m_j$, $m_i \sqsubseteq_M m_j$ when $m_i(\ell)
  9488. \subseteq m_j(\ell)$ for every block label $\ell$ in the program. The
  9489. bottom element of $M$ is the mapping $\bot_M$ that sends every label
  9490. to the empty set, i.e., $\bot_M(\ell) = \emptyset$.
  9491. We can think of one iteration of liveness analysis as being a function
  9492. $f$ on the lattice $M$. It takes a mapping as input and computes a new
  9493. mapping.
  9494. \[
  9495. f(m_i) = m_{i+1}
  9496. \]
  9497. Next let us think for a moment about what a final solution $m_s$
  9498. should look like. If we perform liveness analysis using the solution
  9499. $m_s$ as input, we should get $m_s$ again as the output. That is, the
  9500. solution should be a \emph{fixed point} of the function $f$.\index{fixed point}
  9501. \[
  9502. f(m_s) = m_s
  9503. \]
  9504. Furthermore, the solution should only include locations that are
  9505. forced to be there by performing liveness analysis on the program, so
  9506. the solution should be the \emph{least} fixed point.\index{least fixed point}
  9507. The Kleene Fixed-Point Theorem states that if a function $f$ is
  9508. monotone (better inputs produce better outputs), then the least fixed
  9509. point of $f$ is the least upper bound of the \emph{ascending Kleene
  9510. chain} obtained by starting at $\bot$ and iterating $f$ as
  9511. follows.\index{Kleene Fixed-Point Theorem}
  9512. \[
  9513. \bot \sqsubseteq f(\bot) \sqsubseteq f(f(\bot)) \sqsubseteq \cdots
  9514. \sqsubseteq f^n(\bot) \sqsubseteq \cdots
  9515. \]
  9516. When a lattice contains only finitely-long ascending chains, then
  9517. every Kleene chain tops out at some fixed point after a number of
  9518. iterations of $f$. So that fixed point is also a least upper
  9519. bound of the chain.
  9520. \[
  9521. \bot \sqsubseteq f(\bot) \sqsubseteq f(f(\bot)) \sqsubseteq \cdots
  9522. \sqsubseteq f^k(\bot) = f^{k+1}(\bot) = m_s
  9523. \]
  9524. The liveness analysis is indeed a monotone function and the lattice
  9525. $M$ only has finitely-long ascending chains because there are only a
  9526. finite number of variables and blocks in the program. Thus we are
  9527. guaranteed that iteratively applying liveness analysis to all blocks
  9528. in the program will eventually produce the least fixed point solution.
  9529. Next let us consider dataflow analysis in general and discuss the
  9530. generic work list algorithm (Figure~\ref{fig:generic-dataflow}).
  9531. %
  9532. The algorithm has four parameters: the control-flow graph \code{G}, a
  9533. function \code{transfer} that applies the analysis to one block, the
  9534. \code{bottom} and \code{join} operator for the lattice of abstract
  9535. states. The algorithm begins by creating the bottom mapping,
  9536. represented by a hash table. It then pushes all of the nodes in the
  9537. control-flow graph onto the work list (a queue). The algorithm repeats
  9538. the \code{while} loop as long as there are items in the work list. In
  9539. each iteration, a node is popped from the work list and processed. The
  9540. \code{input} for the node is computed by taking the join of the
  9541. abstract states of all the predecessor nodes. The \code{transfer}
  9542. function is then applied to obtain the \code{output} abstract
  9543. state. If the output differs from the previous state for this block,
  9544. the mapping for this block is updated and its successor nodes are
  9545. pushed onto the work list.
  9546. \begin{figure}[tb]
  9547. \begin{lstlisting}
  9548. (define (analyze-dataflow G transfer bottom join)
  9549. (define mapping (make-hash))
  9550. (for ([v (in-vertices G)])
  9551. (dict-set! mapping v bottom))
  9552. (define worklist (make-queue))
  9553. (for ([v (in-vertices G)])
  9554. (enqueue! worklist v))
  9555. (define trans-G (transpose G))
  9556. (while (not (queue-empty? worklist))
  9557. (define node (dequeue! worklist))
  9558. (define input (for/fold ([state bottom])
  9559. ([pred (in-neighbors trans-G node)])
  9560. (join state (dict-ref mapping pred))))
  9561. (define output (transfer node input))
  9562. (cond [(not (equal? output (dict-ref mapping node)))
  9563. (dict-set! mapping node output)
  9564. (for ([v (in-neighbors G node)])
  9565. (enqueue! worklist v))]))
  9566. mapping)
  9567. \end{lstlisting}
  9568. \caption{Generic work list algorithm for dataflow analysis}
  9569. \label{fig:generic-dataflow}
  9570. \end{figure}
  9571. Having discussed the two complications that arise from adding support
  9572. for assignment and loops, we turn to discussing the one new compiler
  9573. pass and the significant changes to existing passes.
  9574. \section{Convert Assignments}
  9575. \label{sec:convert-assignments}
  9576. Recall that in Section~\ref{sec:assignment-scoping} we learned that
  9577. the combination of assignments and lexically-scoped functions requires
  9578. that we box those variables that are both assigned-to and that appear
  9579. free inside a \code{lambda}. The purpose of the
  9580. \code{convert-assignments} pass is to carry out that transformation.
  9581. We recommend placing this pass after \code{uniquify} but before
  9582. \code{reveal-functions}.
  9583. Consider again the first example from
  9584. Section~\ref{sec:assignment-scoping}:
  9585. \begin{lstlisting}
  9586. (let ([x 0])
  9587. (let ([y 0])
  9588. (let ([z 20])
  9589. (let ([f (lambda: ([a : Integer]) : Integer (+ a (+ x z)))])
  9590. (begin
  9591. (set! x 10)
  9592. (set! y 12)
  9593. (f y))))))
  9594. \end{lstlisting}
  9595. The variables \code{x} and \code{y} are assigned-to. The variables
  9596. \code{x} and \code{z} occur free inside the \code{lambda}. Thus,
  9597. variable \code{x} needs to be boxed but not \code{y} and \code{z}.
  9598. The boxing of \code{x} consists of three transformations: initialize
  9599. \code{x} with a vector, replace reads from \code{x} with
  9600. \code{vector-ref}'s, and replace each \code{set!} on \code{x} with a
  9601. \code{vector-set!}. The output of \code{convert-assignments} for this
  9602. example is as follows.
  9603. \begin{lstlisting}
  9604. (define (main) : Integer
  9605. (let ([x0 (vector 0)])
  9606. (let ([y1 0])
  9607. (let ([z2 20])
  9608. (let ([f4 (lambda: ([a3 : Integer]) : Integer
  9609. (+ a3 (+ (vector-ref x0 0) z2)))])
  9610. (begin
  9611. (vector-set! x0 0 10)
  9612. (set! y1 12)
  9613. (f4 y1)))))))
  9614. \end{lstlisting}
  9615. \paragraph{Assigned \& Free}
  9616. We recommend defining an auxiliary function named
  9617. \code{assigned\&free} that takes an expression and simultaneously
  9618. computes 1) a set of assigned variables $A$, 2) a set $F$ of variables
  9619. that occur free within lambda's, and 3) a new version of the
  9620. expression that records which bound variables occurred in the
  9621. intersection of $A$ and $F$. You can use the struct
  9622. \code{AssignedFree} to do this. Consider the case for
  9623. $\LET{x}{\itm{rhs}}{\itm{body}}$. Suppose the the recursive call on
  9624. $\itm{rhs}$ produces $\itm{rhs}'$, $A_r$, and $F_r$ and the recursive
  9625. call on the $\itm{body}$ produces $\itm{body}'$, $A_b$, and $F_b$. If
  9626. $x$ is in $A_b\cap F_b$, then transforms the \code{Let} as follows.
  9627. \begin{lstlisting}
  9628. (Let |$x$| |$rhs$| |$body$|)
  9629. |$\Rightarrow$|
  9630. (Let (AssignedFree |$x$|) |$rhs'$| |$body'$|)
  9631. \end{lstlisting}
  9632. If $x$ is not in $A_b\cap F_b$ then omit the use of \code{AssignedFree}.
  9633. The set of assigned variables for this \code{Let} is
  9634. $A_r \cup (A_b - \{x\})$
  9635. and the set of variables free in lambda's is
  9636. $F_r \cup (F_b - \{x\})$.
  9637. The case for $\SETBANG{x}{\itm{rhs}}$ is straightforward but
  9638. important. Recursively process \itm{rhs} to obtain \itm{rhs'}, $A_r$,
  9639. and $F_r$. The result is $\SETBANG{x}{\itm{rhs'}}$, $\{x\} \cup A_r$,
  9640. and $F_r$.
  9641. The case for $\LAMBDA{\itm{params}}{T}{\itm{body}}$ is a bit more
  9642. involved. Let \itm{body'}, $A_b$, and $F_b$ be the result of
  9643. recursively processing \itm{body}. Wrap each of parameter that occurs
  9644. in $A_b \cap F_b$ with \code{AssignedFree} to produce \itm{params'}.
  9645. Let $P$ be the set of parameter names in \itm{params}. The result is
  9646. $\LAMBDA{\itm{params'}}{T}{\itm{body'}}$, $A_b - P$, and $(F_b \cup
  9647. \mathrm{FV}(\itm{body})) - P$, where $\mathrm{FV}$ computes the free
  9648. variables of an expression (see Chapter~\ref{ch:lambdas}).
  9649. \paragraph{Convert Assignments}
  9650. Next we discuss the \code{convert-assignment} pass with its auxiliary
  9651. functions for expressions and definitions. The function for
  9652. expressions, \code{cnvt-assign-exp}, should take an expression and a
  9653. set of assigned-and-free variables (obtained from the result of
  9654. \code{assigned\&free}. In the case for $\VAR{x}$, if $x$ is
  9655. assigned-and-free, then unbox it by translating $\VAR{x}$ to a
  9656. \code{vector-ref}.
  9657. \begin{lstlisting}
  9658. (Var |$x$|)
  9659. |$\Rightarrow$|
  9660. (Prim 'vector-ref (list (Var |$x$|) (Int 0)))
  9661. \end{lstlisting}
  9662. %
  9663. In the case for $\LET{\LP\code{AssignedFree}\,
  9664. x\RP}{\itm{rhs}}{\itm{body}}$, recursively process \itm{rhs} to
  9665. obtain \itm{rhs'}. Next, recursively process \itm{body} to obtain
  9666. \itm{body'} but with $x$ added to the set of assigned-and-free
  9667. variables. Translate the let-expression as follows to bind $x$ to a
  9668. boxed value.
  9669. \begin{lstlisting}
  9670. (Let (AssignedFree |$x$|) |$rhs$| |$body$|)
  9671. |$\Rightarrow$|
  9672. (Let |$x$| (Prim 'vector (list |$rhs'$|)) |$body'$|)
  9673. \end{lstlisting}
  9674. %
  9675. In the case for $\SETBANG{x}{\itm{rhs}}$, recursively process
  9676. \itm{rhs} to obtain \itm{rhs'}. If $x$ is in the assigned-and-free
  9677. variables, translate the \code{set!} into a \code{vector-set!}
  9678. as follows.
  9679. \begin{lstlisting}
  9680. (SetBang |$x$| |$\itm{rhs}$|)
  9681. |$\Rightarrow$|
  9682. (Prim 'vector-set! (list (Var |$x$|) (Int 0) |$\itm{rhs'}$|))
  9683. \end{lstlisting}
  9684. %
  9685. The case for \code{Lambda} is non-trivial, but it is similar to the
  9686. case for function definitions, which we discuss next.
  9687. The auxiliary function for definitions, \code{cnvt-assign-def},
  9688. applies assignment conversion to function definitions.
  9689. We translate a function definition as follows.
  9690. \begin{lstlisting}
  9691. (Def |$f$| |$\itm{params}$| |$T$| |$\itm{info}$| |$\itm{body_1}$|)
  9692. |$\Rightarrow$|
  9693. (Def |$f$| |$\itm{params'}$| |$T$| |$\itm{info}$| |$\itm{body_4}$|)
  9694. \end{lstlisting}
  9695. So it remains to explain \itm{params'} and $\itm{body}_4$.
  9696. Let \itm{body_2}, $A_b$, and $F_b$ be the result of
  9697. \code{assigned\&free} on $\itm{body_1}$.
  9698. Let $P$ be the parameter names in \itm{params}.
  9699. We then apply \code{cnvt-assign-exp} to $\itm{body_2}$ to
  9700. obtain \itm{body_3}, passing $A_b \cap F_b \cap P$
  9701. as the set of assigned-and-free variables.
  9702. Finally, we obtain \itm{body_4} by wrapping \itm{body_3}
  9703. in a sequence of let-expressions that box the parameters
  9704. that are in $A_b \cap F_b$.
  9705. %
  9706. Regarding \itm{params'}, change the names of the parameters that are
  9707. in $A_b \cap F_b$ to maintain uniqueness (and so the let-bound
  9708. variables can retain the original names). Recall the second example in
  9709. Section~\ref{sec:assignment-scoping} involving a counter
  9710. abstraction. The following is the output of assignment version for
  9711. function \code{f}.
  9712. \begin{lstlisting}
  9713. (define (f0 [x1 : Integer]) : (Vector ( -> Integer) ( -> Void))
  9714. (vector
  9715. (lambda: () : Integer x1)
  9716. (lambda: () : Void (set! x1 (+ 1 x1)))))
  9717. |$\Rightarrow$|
  9718. (define (f0 [param_x1 : Integer]) : (Vector (-> Integer) (-> Void))
  9719. (let ([x1 (vector param_x1)])
  9720. (vector (lambda: () : Integer (vector-ref x1 0))
  9721. (lambda: () : Void
  9722. (vector-set! x1 0 (+ 1 (vector-ref x1 0)))))))
  9723. \end{lstlisting}
  9724. \section{Remove Complex Operands}
  9725. \label{sec:rco-loop}
  9726. The three new language forms, \code{while}, \code{set!}, and
  9727. \code{begin} are all complex expressions and their subexpressions are
  9728. allowed to be complex. Figure~\ref{fig:r4-anf-syntax} defines the
  9729. output language $R_4^{\dagger}$ of this pass.
  9730. \begin{figure}[tp]
  9731. \centering
  9732. \fbox{
  9733. \begin{minipage}{0.96\textwidth}
  9734. \small
  9735. \[
  9736. \begin{array}{rcl}
  9737. \Atm &::=& \gray{ \INT{\Int} \mid \VAR{\Var} \mid \BOOL{\itm{bool}}
  9738. \mid \VOID{} } \\
  9739. \Exp &::=& \ldots \mid \gray{ \LET{\Var}{\Exp}{\Exp} } \\
  9740. &\mid& \WHILE{\Exp}{\Exp} \mid \SETBANG{\Var}{\Exp}
  9741. \mid \BEGIN{\LP\Exp\ldots\RP}{\Exp} \\
  9742. \Def &::=& \gray{ \FUNDEF{\Var}{([\Var \code{:} \Type]\ldots)}{\Type}{\code{'()}}{\Exp} }\\
  9743. R^{\dagger}_8 &::=& \gray{ \PROGRAMDEFS{\code{'()}}{\Def} }
  9744. \end{array}
  9745. \]
  9746. \end{minipage}
  9747. }
  9748. \caption{$R_8^{\dagger}$ is $R_8$ in administrative normal form (ANF).}
  9749. \label{fig:r8-anf-syntax}
  9750. \end{figure}
  9751. As usual, when a complex expression appears in a grammar position that
  9752. needs to be atomic, such as the argument of a primitive operator, we
  9753. must introduce a temporary variable and bind it to the complex
  9754. expression. This approach applies, unchanged, to handle the new
  9755. language forms. For example, in the following code there are two
  9756. \code{begin} expressions appearing as arguments to \code{+}. The
  9757. output of \code{rco-exp} is shown below, in which the \code{begin}
  9758. expressions have been bound to temporary variables. Recall that
  9759. \code{let} expressions in $R_8^{\dagger}$ are allowed to have
  9760. arbitrary expressions in their right-hand-side expression, so it is
  9761. fine to place \code{begin} there.
  9762. \begin{lstlisting}
  9763. (let ([x0 10])
  9764. (let ([y1 0])
  9765. (+ (+ (begin (set! y1 (read)) x0)
  9766. (begin (set! x0 (read)) y1))
  9767. x0)))
  9768. |$\Rightarrow$|
  9769. (let ([x0 10])
  9770. (let ([y1 0])
  9771. (let ([tmp2 (begin (set! y1 (read)) x0)])
  9772. (let ([tmp3 (begin (set! x0 (read)) y1)])
  9773. (let ([tmp4 (+ tmp2 tmp3)])
  9774. (+ tmp4 x0))))))
  9775. \end{lstlisting}
  9776. \section{Explicate Control and $C_7$}
  9777. \label{sec:explicate-loop}
  9778. Recall that in the \code{explicate-control} pass we define one helper
  9779. function for each kind of position in the program. For the $R_1$
  9780. language of integers and variables we needed kinds of positions:
  9781. assignment and tail. The \code{if} expressions of $R_2$ introduced
  9782. predicate positions. For $R_8$, the \code{begin} expression introduces
  9783. yet another kind of position: effect position. Except for the last
  9784. subexpression, the subexpressions inside a \code{begin} are evaluated
  9785. only for their effect. Their result values are discarded. We can
  9786. generate better code by taking this fact into account.
  9787. The output language of \code{explicate-control} is $C_7$
  9788. (Figure~\ref{fig:c7-syntax}), which is nearly identical to $C_4$. The
  9789. only difference is that \code{Call}, \code{vector-set!}, and
  9790. \code{read} may also appear as statements.
  9791. \begin{figure}[tp]
  9792. \fbox{
  9793. \begin{minipage}{0.96\textwidth}
  9794. \small
  9795. \[
  9796. \begin{array}{lcl}
  9797. \Stmt &::=& \gray{ \ASSIGN{\VAR{\Var}}{\Exp}
  9798. \mid \LP\key{Collect} \,\itm{int}\RP } \\
  9799. &\mid& \CALL{\Atm}{\LP\Atm\ldots\RP} \mid \READ{}\\
  9800. &\mid& \LP\key{Prim}~\key{'vector-set!}\,\LP\key{list}\,\Atm\,\INT{\Int}\,\Atm\RP\RP \\
  9801. \Def &::=& \DEF{\itm{label}}{\LP\LS\Var\key{:}\Type\RS\ldots\RP}{\Type}{\itm{info}}{\LP\LP\itm{label}\,\key{.}\,\Tail\RP\ldots\RP}\\
  9802. C_7 & ::= & \PROGRAMDEFS{\itm{info}}{\LP\Def\ldots\RP}
  9803. \end{array}
  9804. \]
  9805. \end{minipage}
  9806. }
  9807. \caption{The abstract syntax of $C_7$, extending $C_4$ (Figure~\ref{fig:c4-syntax}).}
  9808. \label{fig:c7-syntax}
  9809. \end{figure}
  9810. The new auxiliary function \code{explicate-effect} takes an expression
  9811. (in an effect position) and a promise of a continuation block. The
  9812. function returns a promise for a $\Tail$ that includes the generated
  9813. code for the input expression followed by the continuation block. If
  9814. the expression is obviously pure, that is, never causes side effects,
  9815. then the expression can be removed, so the result is just the
  9816. continuation block.
  9817. %
  9818. The $\WHILE{\itm{cnd}}{\itm{body}}$ expression is the most interesting
  9819. case. First, you will need a fresh label $\itm{loop}$ for the top of
  9820. the loop. Recursively process the \itm{body} (in effect position)
  9821. with the a \code{goto} to $\itm{loop}$ as the continuation, producing
  9822. \itm{body'}. Next, process the \itm{cnd} (in predicate position) with
  9823. \itm{body'} as the then-branch and the continuation block as the
  9824. else-branch. The result should be added to the control-flow graph with
  9825. the label \itm{loop}. The result for the whole \code{while} loop is a
  9826. \code{goto} to the \itm{loop} label. Note that the loop should only be
  9827. added to the control-flow graph if the loop is indeed used, which can
  9828. be accomplished using \code{delay}.
  9829. The auxiliary functions for tail, assignment, and predicate positions
  9830. need to be updated. The three new language forms, \code{while},
  9831. \code{set!}, and \code{begin}, can appear in assignment and tail
  9832. positions. Only \code{begin} may appear in predicate positions; the
  9833. other two have result type \code{Void}.
  9834. \section{Select Instructions}
  9835. \label{sec:select-instructions-loop}
  9836. Only three small additions are needed in the
  9837. \code{select-instructions} pass to handle the changes to $C_7$. That
  9838. is, \code{Call}, \code{read}, and \code{vector-set!} may now appear as
  9839. stand-alone statements instead of only appearing on the right-hand
  9840. side of an assignment statement. The code generation is nearly
  9841. identical; just leave off the instruction for moving the result into
  9842. the left-hand side.
  9843. \section{Register Allocation}
  9844. \label{sec:register-allocation-loop}
  9845. As discussed in Section~\ref{sec:dataflow-analysis}, the presence of
  9846. loops in $R_8$ means that the control-flow graphs may contain cycles,
  9847. which complicates the liveness analysis needed for register
  9848. allocation.
  9849. \subsection{Liveness Analysis}
  9850. \label{sec:liveness-analysis-r8}
  9851. We recommend using the generic \code{analyze-dataflow} function that
  9852. was presented at the end of Section~\ref{sec:dataflow-analysis} to
  9853. perform liveness analysis, replacing the code in
  9854. \code{uncover-live-CFG} that processed the basic blocks in topological
  9855. order (Section~\ref{sec:liveness-analysis-r2}).
  9856. The \code{analyze-dataflow} function has four parameters.
  9857. \begin{enumerate}
  9858. \item The first parameter \code{G} should be a directed graph from the
  9859. \code{racket/graph} package (see the sidebar in
  9860. Section~\ref{sec:build-interference}) that represents the
  9861. control-flow graph.
  9862. \item The second parameter \code{transfer} is a function that applies
  9863. liveness analysis to a basic block. It takes two parameters: the
  9864. label for the block to analyze and the live-after set for that
  9865. block. The transfer function should return the live-before set for
  9866. the block. Also, as a side-effect, it should update the block's
  9867. $\itm{info}$ with the liveness information for each instruction. To
  9868. implement the \code{transfer} function, you should be able to reuse
  9869. the code you already have for analyzing basic blocks.
  9870. \item The third and fourth parameters of \code{analyze-dataflow} are
  9871. \code{bottom} and \code{join} for the lattice of abstract states,
  9872. i.e. sets of locations. The bottom of the lattice is the empty set
  9873. \code{(set)} and the join operator is \code{set-union}.
  9874. \end{enumerate}
  9875. \begin{figure}[p]
  9876. \begin{tikzpicture}[baseline=(current bounding box.center)]
  9877. \node (R4) at (0,2) {\large $R_8$};
  9878. \node (R4-2) at (3,2) {\large $R_8$};
  9879. \node (R4-3) at (6,2) {\large $R_8$};
  9880. \node (R4-4) at (9,2) {\large $R'_8$};
  9881. \node (F1-1) at (12,0) {\large $R'_8$};
  9882. \node (F1-2) at (9,0) {\large $R'_8$};
  9883. \node (F1-3) at (6,0) {\large $R'_8$};
  9884. \node (F1-4) at (3,0) {\large $R'_8$};
  9885. \node (F1-5) at (0,0) {\large $R'_8$};
  9886. \node (C3-2) at (3,-2) {\large $C_3$};
  9887. \node (x86-2) at (3,-4) {\large $\text{x86}^{*}_3$};
  9888. \node (x86-3) at (6,-4) {\large $\text{x86}^{*}_3$};
  9889. \node (x86-4) at (9,-4) {\large $\text{x86}^{*}_3$};
  9890. \node (x86-5) at (9,-6) {\large $\text{x86}^{\dagger}_3$};
  9891. \node (x86-2-1) at (3,-6) {\large $\text{x86}^{*}_3$};
  9892. \node (x86-2-2) at (6,-6) {\large $\text{x86}^{*}_3$};
  9893. %% \path[->,bend left=15] (R4) edge [above] node
  9894. %% {\ttfamily\footnotesize type-check} (R4-2);
  9895. \path[->,bend left=15] (R4) edge [above] node
  9896. {\ttfamily\footnotesize shrink} (R4-2);
  9897. \path[->,bend left=15] (R4-2) edge [above] node
  9898. {\ttfamily\footnotesize uniquify} (R4-3);
  9899. \path[->,bend left=15] (R4-3) edge [above] node
  9900. {\ttfamily\footnotesize reveal-functions} (R4-4);
  9901. \path[->,bend left=15] (R4-4) edge [right] node
  9902. {\ttfamily\footnotesize convert-assignments} (F1-1);
  9903. \path[->,bend left=15] (F1-1) edge [below] node
  9904. {\ttfamily\footnotesize convert-to-clos.} (F1-2);
  9905. \path[->,bend right=15] (F1-2) edge [above] node
  9906. {\ttfamily\footnotesize limit-fun.} (F1-3);
  9907. \path[->,bend right=15] (F1-3) edge [above] node
  9908. {\ttfamily\footnotesize expose-alloc.} (F1-4);
  9909. \path[->,bend right=15] (F1-4) edge [above] node
  9910. {\ttfamily\footnotesize remove-complex.} (F1-5);
  9911. \path[->,bend right=15] (F1-5) edge [right] node
  9912. {\ttfamily\footnotesize explicate-control} (C3-2);
  9913. \path[->,bend left=15] (C3-2) edge [left] node
  9914. {\ttfamily\footnotesize select-instr.} (x86-2);
  9915. \path[->,bend right=15] (x86-2) edge [left] node
  9916. {\ttfamily\footnotesize uncover-live} (x86-2-1);
  9917. \path[->,bend right=15] (x86-2-1) edge [below] node
  9918. {\ttfamily\footnotesize build-inter.} (x86-2-2);
  9919. \path[->,bend right=15] (x86-2-2) edge [left] node
  9920. {\ttfamily\footnotesize allocate-reg.} (x86-3);
  9921. \path[->,bend left=15] (x86-3) edge [above] node
  9922. {\ttfamily\footnotesize patch-instr.} (x86-4);
  9923. \path[->,bend left=15] (x86-4) edge [right] node {\ttfamily\footnotesize print-x86} (x86-5);
  9924. \end{tikzpicture}
  9925. \caption{Diagram of the passes for $R_8$ (loops and assignment).}
  9926. \label{fig:R8-passes}
  9927. \end{figure}
  9928. Figure~\ref{fig:R8-passes} provides an overview of all the passes needed
  9929. for the compilation of $R_8$.
  9930. % TODO: challenge assignment
  9931. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  9932. \chapter{Gradual Typing}
  9933. \label{ch:gradual-typing}
  9934. \index{gradual typing}
  9935. This chapter studies a language, $R_9$, in which the programmer can
  9936. choose between static and dynamic type checking for different regions
  9937. of a program, thereby mixing the statically typed $R_8$ language with
  9938. the dynamically typed $R_7$. There are several approaches to mixing
  9939. static and dynamic typing, including multi-language
  9940. integration~\citep{Tobin-Hochstadt:2006fk,Matthews:2007zr} and hybrid
  9941. type checking~\citep{Flanagan:2006mn,Gronski:2006uq}. In this chapter
  9942. we focus on \emph{gradual typing}\index{gradual typing}, in which the
  9943. programmer controls the amount of static versus dynamic checking by
  9944. adding or removing type annotations on parameters and
  9945. variables~\citep{Anderson:2002kd,Siek:2006bh}.
  9946. The concrete syntax of $R_9$ is defined in
  9947. Figure~\ref{fig:r9-concrete-syntax} and its abstract syntax is defined
  9948. in Figure~\ref{fig:r9-syntax}.
  9949. \begin{figure}[tp]
  9950. \centering
  9951. \fbox{
  9952. \begin{minipage}{0.96\textwidth}
  9953. \small
  9954. \[
  9955. \begin{array}{lcl}
  9956. \itm{param} &::=& \Var \mid \LS\Var \key{:} \Type\RS \\
  9957. \Exp &::=& \gray{ \Int \mid \CREAD{} \mid \CNEG{\Exp}
  9958. \mid \CADD{\Exp}{\Exp} \mid \CSUB{\Exp}{\Exp} } \\
  9959. &\mid& \gray{ \Var \mid \CLET{\Var}{\Exp}{\Exp} }\\
  9960. &\mid& \gray{\key{\#t} \mid \key{\#f}
  9961. \mid (\key{and}\;\Exp\;\Exp)
  9962. \mid (\key{or}\;\Exp\;\Exp)
  9963. \mid (\key{not}\;\Exp) } \\
  9964. &\mid& \gray{ (\key{eq?}\;\Exp\;\Exp) \mid \CIF{\Exp}{\Exp}{\Exp} } \\
  9965. &\mid& \gray{ (\key{vector}\;\Exp\ldots) \mid
  9966. (\key{vector-ref}\;\Exp\;\Int)} \\
  9967. &\mid& \gray{(\key{vector-set!}\;\Exp\;\Int\;\Exp)\mid (\key{void})
  9968. \mid (\Exp \; \Exp\ldots) } \\
  9969. &\mid& \gray{ \LP \key{procedure-arity}~\Exp\RP }
  9970. \mid \CLAMBDA{\LP\itm{param}\ldots\RP}{\Type}{\Exp} \\
  9971. &\mid& \gray{ \CSETBANG{\Var}{\Exp}
  9972. \mid \CBEGIN{\Exp\ldots}{\Exp}
  9973. \mid \CWHILE{\Exp}{\Exp} } \\
  9974. \Def &::=& \CDEF{\Var}{\itm{param}\ldots}{\Type}{\Exp} \\
  9975. R_9 &::=& \gray{\Def\ldots \; \Exp}
  9976. \end{array}
  9977. \]
  9978. \end{minipage}
  9979. }
  9980. \caption{The concrete syntax of $R_9$, extending $R_8$ (Figure~\ref{fig:r8-concrete-syntax}).}
  9981. \label{fig:r9-concrete-syntax}
  9982. \end{figure}
  9983. \begin{figure}[tp]
  9984. \centering
  9985. \fbox{
  9986. \begin{minipage}{0.96\textwidth}
  9987. \small
  9988. \[
  9989. \begin{array}{lcl}
  9990. \itm{param} &::=& \Var \mid \LS\Var \key{:} \Type\RS \\
  9991. \Exp &::=& \gray{ \INT{\Int} \VAR{\Var} \mid \LET{\Var}{\Exp}{\Exp} } \\
  9992. &\mid& \gray{ \PRIM{\itm{op}}{\Exp\ldots} }\\
  9993. &\mid& \gray{ \BOOL{\itm{bool}}
  9994. \mid \IF{\Exp}{\Exp}{\Exp} } \\
  9995. &\mid& \gray{ \VOID{} \mid \LP\key{HasType}~\Exp~\Type \RP
  9996. \mid \APPLY{\Exp}{\Exp\ldots} }\\
  9997. &\mid& \LAMBDA{\LP\itm{param}\ldots\RP}{\Type}{\Exp} \\
  9998. &\mid& \gray{ \SETBANG{\Var}{\Exp} \mid \BEGIN{\LP\Exp\ldots\RP}{\Exp}
  9999. \mid \WHILE{\Exp}{\Exp} } \\
  10000. \Def &::=& \FUNDEF{\Var}{\LP\itm{param}\ldots\RP}{\Type}{\code{'()}}{\Exp} \\
  10001. R_9 &::=& \gray{ \PROGRAMDEFSEXP{\code{'()}}{\LP\Def\ldots\RP}{\Exp} }
  10002. \end{array}
  10003. \]
  10004. \end{minipage}
  10005. }
  10006. \caption{The abstract syntax of $R_9$, extending $R_8$ (Figure~\ref{fig:r8-syntax}).}
  10007. \label{fig:r8-syntax}
  10008. \end{figure}
  10009. Both the type checker and the interpreter for $R_9$ require some
  10010. interesting changes to enable gradual typing, which we discuss in the
  10011. next two sections while revisiting the \code{map-vec} example from
  10012. Chapter~\ref{ch:functions}. In Figure~\ref{fig:gradual-map-vec} we
  10013. present the example again but this time we leave off the type
  10014. annotations from the \code{add1} function.
  10015. \begin{figure}[btp]
  10016. \begin{lstlisting}
  10017. (define (map-vec [f : (Integer -> Integer)]
  10018. [v : (Vector Integer Integer)])
  10019. : (Vector Integer Integer)
  10020. (vector (f (vector-ref v 0)) (f (vector-ref v 1))))
  10021. (define (add1 x) (+ x 1))
  10022. (vector-ref (map-vec add1 (vector 0 41)) 1)
  10023. \end{lstlisting}
  10024. \caption{A partially-typed version of the \code{map-vec} example.}
  10025. \label{fig:gradual-map-vec}
  10026. \end{figure}
  10027. \section{Type Checking $R_9$}
  10028. \label{sec:gradual-type-check}
  10029. The type checker for $R_9$ uses the \code{Any} type for missing
  10030. parameter and return types. For example, the \code{x} parameter of
  10031. \code{add1} in Figure~\ref{fig:gradual-map-vec} is given the type
  10032. \code{Any} and the return type of \code{add1} is \code{Any}. Next
  10033. consider the \code{+} operator inside \code{add1}. It expects both
  10034. arguments to have type \code{Integer}, but its first argument \code{x}
  10035. has type \code{Any}. In a gradually typed language, such differences
  10036. are allowed so long as the types are \emph{consistent}, that is, they
  10037. are equal except in places where there is an \code{Any} type. The type
  10038. \code{Any} is consistent with every other type.
  10039. Figure~\ref{fig:consistent} defines the \code{consistent?} predicate.
  10040. \begin{figure}[tbp]
  10041. \begin{lstlisting}
  10042. (define (consistent? t1 t2)
  10043. (match* (t1 t2)
  10044. [('Integer 'Integer) #t]
  10045. [('Boolean 'Boolean) #t]
  10046. [('Void 'Void) #t]
  10047. [('Any t2) #t]
  10048. [(t1 'Any) #t]
  10049. [(`(Vector ,ts1 ...) `(Vector ,ts2 ...))
  10050. (for/and ([t1 ts1] [t2 ts2]) (consistent? t1 t2))]
  10051. [(`(,ts1 ... -> ,rt1) `(,ts2 ... -> ,rt2))
  10052. (and (for/and ([t1 ts1] [t2 ts2]) (consistent? t1 t2))
  10053. (consistent? rt1 rt2))]
  10054. [(other wise) #f]))
  10055. \end{lstlisting}
  10056. \caption{The consistency predicate on types.}
  10057. \label{fig:consistent}
  10058. \end{figure}
  10059. Returning to the \code{map-vec} example of
  10060. Figure~\ref{fig:gradual-map-vec}, the \code{add1} function has type
  10061. \code{(Any -> Any)} but parameter \code{f} of \code{map-vec} has type
  10062. \code{(Integer -> Integer)}. The type checker for $R_9$ allows this
  10063. because the two types are consistent. In particular, \code{->} is
  10064. equal to \code{->} and because \code{Any} is consistent with
  10065. \code{Integer}.
  10066. Next consider a program with an error, such as applying the
  10067. \code{map-vec} to a function that sometimes returns a Boolean, as
  10068. shown in Figure~\ref{fig:map-vec-maybe-add1}. The type checker for
  10069. $R_9$ accepts this program because the type of \code{maybe-add1} is
  10070. consistent with the type of parameter \code{f} of \code{map-vec}, that
  10071. is, \code{(Any -> Any)} is consistent with \code{(Integer ->
  10072. Integer)}. One might say that a gradual type checker is optimistic
  10073. in that it accepts programs that might execute without a runtime type
  10074. error.
  10075. %
  10076. Unfortunately, running this program with input \code{1} triggers an
  10077. error when the \code{maybe-add1} function returns \code{\#t}. $R_9$
  10078. performs checking at runtime to ensure the integrity of the static
  10079. types, such as the \code{(Integer -> Integer)} annotation on parameter
  10080. \code{f} of \code{map-vec}. This runtime checking is carried out by a
  10081. new \code{cast} form that is inserted by the type checker. Thus, the
  10082. output of the type checker is a program in the $R'_9$ language, which
  10083. adds \code{cast} to $R_9$.
  10084. % TODO: grammar for $R'_9$
  10085. \begin{figure}[tbp]
  10086. \begin{lstlisting}
  10087. (define (map-vec [f : (Integer -> Integer)]
  10088. [v : (Vector Integer Integer)])
  10089. : (Vector Integer Integer)
  10090. (vector (f (vector-ref v 0)) (f (vector-ref v 1))))
  10091. (define (add1 x) (+ x 1))
  10092. (define (true) #t)
  10093. (define (maybe-add1 x) (if (eq? 0 (read)) (add1 x) (true)))
  10094. (vector-ref (map-vec maybe-add1 (vector 0 41)) 0)
  10095. \end{lstlisting}
  10096. \caption{A variant of the \code{map-vec} example with an error.}
  10097. \label{fig:map-vec-maybe-add1}
  10098. \end{figure}
  10099. Figure~\ref{fig:map-vec-cast} shows the output of the type checker for
  10100. \code{map-vec} and \code{maybe-add1}. The idea is that \code{cast} is
  10101. inserted every time the type checker sees two types that are
  10102. consistent but not equal. In the \code{add1} function, \code{x} is
  10103. cast to \code{Integer} and the result of the \code{+} is cast to
  10104. \code{Any}. In the call to \code{map-vec}, the \code{add1} argument
  10105. is cast from \code{(Any -> Any)} to \code{(Integer -> Integer)}.
  10106. \begin{figure}[btp]
  10107. \begin{lstlisting}
  10108. (define (map-vec [f : (Integer -> Integer)]
  10109. [v : (Vector Integer Integer)])
  10110. : (Vector Integer Integer)
  10111. (vector (f (vector-ref v 0)) (f (vector-ref v 1))))
  10112. (define (add1 [x : Any]) : Any
  10113. (cast (+ (cast x Any Integer) 1) Integer Any))
  10114. (define (true) : Any (cast #t Boolean Any))
  10115. (define (maybe-add1 [x : Any]) : Any
  10116. (if (eq? 0 (read)) (add1 x) (true)))
  10117. (vector-ref (map-vec (cast maybe-add1 (Any -> Any)
  10118. (Integer -> Integer))
  10119. (vector 0 41))
  10120. 0)
  10121. \end{lstlisting}
  10122. \caption{Output from type checking \code{map-vec}
  10123. and \code{maybe-add1}.}
  10124. \label{fig:map-vec-cast}
  10125. \end{figure}
  10126. The type checker for $R_9$ is defined in
  10127. Figures~\ref{fig:type-check-R9-1}, \ref{fig:type-check-R9-2},
  10128. \ref{fig:type-check-R9-3}, and \ref{fig:type-check-R9-4}.
  10129. \begin{figure}[tbp]
  10130. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  10131. (define type-check-gradual-class
  10132. (class type-check-R8-class
  10133. (super-new)
  10134. (inherit check-type-equal? operator-types type-predicates)
  10135. (define/public (check-consistent? t1 t2 e)
  10136. (unless (consistent? t1 t2)
  10137. (error 'type-check "~a is inconsistent with ~a\nin ~v" t1 t2 e)))
  10138. (define/override (type-check-op op arg-types args e)
  10139. (match (dict-ref (operator-types) op)
  10140. [`(,param-types . ,return-type)
  10141. (for ([at arg-types] [pt param-types])
  10142. (check-consistent? at pt e))
  10143. (values return-type
  10144. (for/list ([e args] [s arg-types] [t param-types])
  10145. (make-cast e s t)))]
  10146. [else (error 'type-check-op "unrecognized ~a" op)]))
  10147. (define explicit-prim-ops
  10148. (set-union (type-predicates)
  10149. (set 'procedure-arity 'eq?
  10150. 'vector 'vector-length 'vector-ref 'vector-set!
  10151. 'any-vector-length 'any-vector-ref 'any-vector-set!)))
  10152. (define/override (type-check-exp env)
  10153. (lambda (e)
  10154. (define recur (type-check-exp env))
  10155. (match e
  10156. [(Prim 'eq? (list e1 e2))
  10157. (define-values (e1^ t1) (recur e1))
  10158. (define-values (e2^ t2) (recur e2))
  10159. (check-consistent? t1 t2 e)
  10160. (define T (meet t1 t2))
  10161. (values (Prim 'eq? (list (make-cast e1^ t1 T) (make-cast e2^ t2 T)))
  10162. 'Boolean)]
  10163. [(Prim 'vector-length (list e1))
  10164. (define-values (e1^ t) (recur e1))
  10165. (match t
  10166. ['Any (values (Prim 'any-vector-length (list e1^)) 'Integer)]
  10167. [`(Vector ,ts ...)
  10168. (values (Prim 'vector-length (list e1^)) 'Integer)])]
  10169. \end{lstlisting}
  10170. \caption{Type checker for the $R_9$ language, part 1.}
  10171. \label{fig:type-check-R9-1}
  10172. \end{figure}
  10173. \begin{figure}[tbp]
  10174. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  10175. [(Prim 'vector-ref (list e1 e2))
  10176. (define-values (e1^ t) (recur e1))
  10177. (define-values (e2^ it) (recur e2))
  10178. (check-consistent? it 'Integer e)
  10179. (match (list t e2^)
  10180. [(list 'Any ei)
  10181. (define e2^^ (make-cast e2^ it 'Integer))
  10182. (values (Prim 'any-vector-ref (list e1^ e2^^)) 'Any)]
  10183. [(list `(Vector ,ts ...) (Int i))
  10184. (unless (and (0 . <= . i) (i . < . (length ts)))
  10185. (error 'type-check "invalid index ~a in ~a" i e))
  10186. (values (Prim 'vector-ref (list e1^ (Int i))) (list-ref ts i))])]
  10187. [(Prim 'vector-set! (list e1 e2 e3) )
  10188. (define-values (e1^ t-vec) (recur e1))
  10189. (define-values (e2^ it) (recur e2))
  10190. (define-values (e3^ t-arg) (recur e3))
  10191. (check-consistent? it 'Integer e)
  10192. (match t-vec
  10193. [`(Vector ,ts ...)
  10194. (match e2^
  10195. [(Int i)
  10196. (unless (and (0 . <= . i) (i . < . (length ts)))
  10197. (error 'type-check "invalid index ~a in ~a" i e))
  10198. (check-consistent? (list-ref ts i) t-arg e)
  10199. (define e3^^ (make-cast e3^ t-arg (list-ref ts i)))
  10200. (values (Prim 'vector-set! (list e1^ (Int i) e3^^)) 'Void)])]
  10201. ['Any
  10202. (define e2^^ (make-cast e2^ it 'Integer))
  10203. (define e3^^ (make-cast e3^ t-arg 'Any))
  10204. (values (Prim 'any-vector-set! (list e1^ e2^^ e3^^)) 'Void)]
  10205. [else
  10206. (error 'type-check "expected vector not ~a\nin ~v" t-vec e)])]
  10207. [(Prim op es)
  10208. #:when (not (set-member? explicit-prim-ops op))
  10209. (define-values (new-es ts)
  10210. (for/lists (exprs types) ([e es])
  10211. (recur e)))
  10212. (define-values (t-ret new-es^) (type-check-op op ts new-es e))
  10213. (values (Prim op new-es^) t-ret)]
  10214. [(If cnd thn els)
  10215. (define-values (c Tc) (recur cnd))
  10216. (define-values (t Tt) (recur thn))
  10217. (define-values (e Te) (recur els))
  10218. (check-consistent? Tc 'Boolean e)
  10219. (check-consistent? Tt Te e)
  10220. (define Tb (join Tt Te))
  10221. (values (If (make-cast c Tc 'Boolean) (make-cast t Tt Tb)
  10222. (make-cast e Te Tb)) Tb)]
  10223. \end{lstlisting}
  10224. \caption{Type checker for the $R_9$ language, part 2.}
  10225. \label{fig:type-check-R9-2}
  10226. \end{figure}
  10227. \begin{figure}[tbp]
  10228. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  10229. [(HasType e1 T)
  10230. (define-values (e1^ T1) (recur e1))
  10231. (check-consistent? T1 T)
  10232. (values (make-cast e1^ T1 T) T)]
  10233. [(Apply e es)
  10234. (define-values (e* ty*) (for/lists (e* ty*) ([e (in-list es)])
  10235. (recur e)))
  10236. (define-values (e^ ty) (recur e))
  10237. (match ty
  10238. [`(,ty^* ... -> ,rt)
  10239. (for ([arg-ty ty*] [param-ty ty^*])
  10240. (check-consistent? arg-ty param-ty e))
  10241. (define new-args (for/list ([e e*] [s ty*] [t ty^*])
  10242. (make-cast e s t)))
  10243. (values (Apply e^ new-args) rt)]
  10244. [`Any
  10245. (define new-fun
  10246. (make-cast e^ 'Any `(,@(for/list ([e es]) 'Any) -> Any)))
  10247. (define new-args (for/list ([e e*] [s ty*])
  10248. (make-cast e s 'Any)))
  10249. (values (Apply new-fun new-args) 'Any)]
  10250. [else (error 'type-check
  10251. "expected a function, not ~a\nin ~v" ty e)])]
  10252. [(Lambda params rT body)
  10253. (define-values (xs Ts) (for/lists (l1 l2) ([p params])
  10254. (match p
  10255. [`[,x : ,T] (values x T)]
  10256. [(? symbol? x) (values x 'Any)])))
  10257. (define-values (new-body bodyT)
  10258. ((type-check-exp (append (map cons xs Ts) env)) body))
  10259. (check-consistent? rT bodyT e)
  10260. (values (Lambda (for/list ([x xs] [T Ts]) `[,x : ,T]) rT
  10261. (make-cast new-body bodyT rT)) `(,@Ts -> ,rT))]
  10262. [(SetBang x rhs)
  10263. (define-values (rhs^ rhsT) (recur rhs))
  10264. (define varT (dict-ref env x))
  10265. (check-consistent? rhsT varT e)
  10266. (values (SetBang x (make-cast rhs^ rhsT varT)) 'Void)]
  10267. [(WhileLoop cnd body)
  10268. (define-values (cnd^ Tc) (recur cnd))
  10269. (check-consistent? Tc 'Boolean e)
  10270. (define-values (body^ Tbody) ((type-check-exp env) body))
  10271. (values (WhileLoop (make-cast cnd^ Tc 'Boolean) body^) 'Void)]
  10272. [else ((super type-check-exp env) e)]
  10273. )))
  10274. \end{lstlisting}
  10275. \caption{Type checker for the $R_9$ language, part 3.}
  10276. \label{fig:type-check-R9-3}
  10277. \end{figure}
  10278. \begin{figure}[tbp]
  10279. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  10280. (define/override (fun-def-type d)
  10281. (match d
  10282. [(Def f params rt info body)
  10283. (debug 'fun-def-type "parameters:" params)
  10284. (define ps
  10285. (for/list ([p params])
  10286. (match p
  10287. [`[,x : ,T] T]
  10288. [(? symbol?) 'Any]
  10289. [else (error 'fun-def-type "unmatched parameter ~a" p)])))
  10290. `(,@ps -> ,rt)]
  10291. [else (error 'fun-def-type "ill-formed function definition in ~a" d)]))
  10292. (define/override (type-check-def env)
  10293. (lambda (e)
  10294. (match e
  10295. [(Def f params rt info body)
  10296. (define-values (xs ps) (for/lists (l1 l2) ([p params])
  10297. (match p
  10298. [`[,x : ,T] (values x T)]
  10299. [(? symbol? x) (values x 'Any)])))
  10300. (define new-env (append (map cons xs ps) env))
  10301. (define-values (body^ ty^) ((type-check-exp new-env) body))
  10302. (check-consistent? ty^ rt e)
  10303. (Def f (for/list ([x xs] [T ps]) `[,x : ,T]) rt info
  10304. (make-cast body^ ty^ rt))]
  10305. [else (error 'type-check "ill-formed function definition ~a" e)]
  10306. )))
  10307. (define/override (type-check-program e)
  10308. (match e
  10309. [(Program info body)
  10310. (define-values (body^ ty) ((type-check-exp '()) body))
  10311. (check-consistent? ty 'Integer e)
  10312. (ProgramDefsExp info '() (make-cast body^ ty 'Integer))]
  10313. [(ProgramDefsExp info ds body)
  10314. (define new-env (for/list ([d ds])
  10315. (cons (Def-name d) (fun-def-type d))))
  10316. (define ds^ (for/list ([d ds])
  10317. ((type-check-def new-env) d)))
  10318. (define-values (body^ ty) ((type-check-exp new-env) body))
  10319. (check-consistent? ty 'Integer e)
  10320. (ProgramDefsExp info ds^ (make-cast body^ ty 'Integer))]
  10321. [else (super type-check-program e)]))
  10322. ))
  10323. (define (type-check-gradual p)
  10324. (send (new type-check-gradual-class) type-check-program p))
  10325. \end{lstlisting}
  10326. \caption{Type checker for the $R_9$ language, part 4.}
  10327. \label{fig:type-check-R9-4}
  10328. \end{figure}
  10329. \begin{figure}[tbp]
  10330. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  10331. (define (join t1 t2)
  10332. (match* (t1 t2)
  10333. [('Integer 'Integer) 'Integer]
  10334. [('Boolean 'Boolean) 'Boolean]
  10335. [('Void 'Void) 'Void]
  10336. [('Any t2) t2]
  10337. [(t1 'Any) t1]
  10338. [(`(Vector ,ts1 ...) `(Vector ,ts2 ...))
  10339. `(Vector ,@(for/list ([t1 ts1] [t2 ts2]) (join t1 t2)))]
  10340. [(`(,ts1 ... -> ,rt1) `(,ts2 ... -> ,rt2))
  10341. `(,@(for/list ([t1 ts1] [t2 ts2]) (join t1 t2))
  10342. -> ,(join rt1 rt2))]
  10343. [(other wise) (error 'join "inconsistent types ~a and ~a" t1 t2)]))
  10344. (define (meet t1 t2)
  10345. (match* (t1 t2)
  10346. [('Integer 'Integer) 'Integer]
  10347. [('Boolean 'Boolean) 'Boolean]
  10348. [('Void 'Void) 'Void]
  10349. [('Any t2) 'Any]
  10350. [(t1 'Any) 'Any]
  10351. [(`(Vector ,ts1 ...) `(Vector ,ts2 ...))
  10352. `(Vector ,@(for/list ([t1 ts1] [t2 ts2]) (meet t1 t2)))]
  10353. [(`(,ts1 ... -> ,rt1) `(,ts2 ... -> ,rt2))
  10354. `(,@(for/list ([t1 ts1] [t2 ts2]) (meet t1 t2))
  10355. -> ,(meet rt1 rt2))]
  10356. [(other wise) (error 'meet "inconsistent types ~a and ~a" t1 t2)]))
  10357. (define (make-cast e src tgt)
  10358. (cond [(equal? src tgt) e]
  10359. [else (Cast e src tgt)]))
  10360. \end{lstlisting}
  10361. \caption{Auxiliary functions for type checking $R_9$.}
  10362. \label{fig:type-check-R9-aux}
  10363. \end{figure}
  10364. \clearpage
  10365. \section{Interpreting $R'_9$}
  10366. \label{sec:interp-casts}
  10367. The runtime behavior of first-order casts is straightforward, that is,
  10368. casts involving simple types such as \code{Integer} and
  10369. \code{Boolean}. For example, a cast from \code{Integer} to \code{Any}
  10370. can be accomplished with the \code{inject} operator of $R_6$, which
  10371. puts the integer into a tagged value
  10372. (Figure~\ref{fig:interp-R6}). Similarly, a cast from \code{Any} to
  10373. \code{Integer} is accomplished with the \code{project} operator, that
  10374. is, by checking the value's tag and either retrieving the underlying
  10375. integer or signaling an error if it the tag is not the one for
  10376. integers (Figure~\ref{fig:apply-project}).
  10377. %
  10378. Things get more interesting for higher-order casts, that is, casts
  10379. involving function or vector types.
  10380. Consider the cast of the function \code{maybe-add1} from \code{(Any ->
  10381. Any)} to \code{(Integer -> Integer)}. When a function flows through
  10382. this cast at runtime, we can't know in general whether the function
  10383. will always return an integer.\footnote{Predicting the return value of
  10384. a function is equivalent to the halting problem, which is
  10385. undecidable.} The $R'_9$ interpreter therefore delays the checking
  10386. of the cast until the function is applied. This is accomplished by
  10387. wrapping \code{maybe-add1} in a new function that casts its parameter
  10388. from \code{Integer} to \code{Any}, applies \code{maybe-add1}, and then
  10389. casts the return value from \code{Any} to \code{Integer}.
  10390. Turning our attention to casts involving vector types, we consider the
  10391. example in Figure~\ref{fig:map-vec-bang} that defines a
  10392. partially-typed version of \code{map-vec} whose parameter \code{v} has
  10393. type \code{(Vector Any Any)} and that updates \code{v} in place
  10394. instead of returning a new vector. So we name this function
  10395. \code{map-vec!}. We apply \code{map-vec!} to a vector of integers, so
  10396. the type checker inserts a cast from \code{(Vector Integer Integer)}
  10397. to \code{(Vector Any Any)}. A naive way for the $R'_9$ interpreter to
  10398. cast between vector types would be a build a new vector whose elements
  10399. are the result of casting each of the original elements to the
  10400. appropriate target type. However, this approach is only valid for
  10401. immutable vectors; and our vectors are mutable. In the example of
  10402. Figure~\ref{fig:map-vec-bang}, if the cast created a new vector, then
  10403. the updates inside of \code{map-vec!} would happen to the new vector
  10404. and not the original one.
  10405. \begin{figure}[tbp]
  10406. \begin{lstlisting}
  10407. (define (map-vec! [f : (Any -> Any)]
  10408. [v : (Vector Any Any)]) : Void
  10409. (begin
  10410. (vector-set! v 0 (f (vector-ref v 0)))
  10411. (vector-set! v 1 (f (vector-ref v 1)))))
  10412. (define (add1 x) (+ x 1))
  10413. (let ([v (vector 0 41)])
  10414. (begin (map-vec! add1 v) (vector-ref v 1)))
  10415. \end{lstlisting}
  10416. \caption{An example involving casts on vectors.}
  10417. \label{fig:map-vec-bang}
  10418. \end{figure}
  10419. Instead the interpreter needs to create a new kind of value, a
  10420. \emph{vector proxy}, that interposes on every vector operation. On a
  10421. read, the proxy reads from the underlying vector and then applies a
  10422. cast to the resulting value. On a write, the proxy casts the argument
  10423. value and then performs the write to the underlying vector. For the
  10424. first \code{(vector-ref v 0)} in \code{map-vec!}, the proxy casts
  10425. \code{0} from \code{Integer} to \code{Any}. For the first
  10426. \code{vector-set!}, the proxy casts a tagged \code{1} from \code{Any}
  10427. to \code{Integer}.
  10428. The final category of cast that we need to consider are casts between
  10429. the \code{Any} type and either a function or a
  10430. vector. Figure~\ref{fig:map-vec-any} shows a variant of
  10431. \code{map-vec!} in which parameter \code{v} does not have a type
  10432. annotation, so it is given type \code{Any}. In the call to
  10433. \code{map-vec!}, the vector has type \code{(Vector Integer Integer)}
  10434. so the type checker inserts a cast from \code{(Vector Integer
  10435. Integer)} to \code{Any}. A first thought is to use \code{inject},
  10436. but that doesn't work because \code{(Vector Integer Integer)} is not a
  10437. flat type. Instead, we must first cast to \code{(Vector Any Any)}
  10438. (which is flat) and then inject to \code{Any}.
  10439. \begin{figure}[tbp]
  10440. \begin{lstlisting}
  10441. (define (map-vec! [f : (Any -> Any)] v) : Void
  10442. (begin
  10443. (vector-set! v 0 (f (vector-ref v 0)))
  10444. (vector-set! v 1 (f (vector-ref v 1)))))
  10445. (define (add1 x) (+ x 1))
  10446. (let ([v (vector 0 41)])
  10447. (begin (map-vec! add1 v) (vector-ref v 1)))
  10448. \end{lstlisting}
  10449. \caption{}
  10450. \label{fig:map-vec-any}
  10451. \end{figure}
  10452. The $R'_9$ interpreter uses an auxiliary function named
  10453. \code{apply-cast} to cast a value from a source type to a target type,
  10454. shown in Figure~\ref{fig:apply-cast}. You'll find that it handles all
  10455. of the kinds of casts that we've discussed in this section.
  10456. \begin{figure}[tbp]
  10457. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  10458. (define/public (apply-cast v s t)
  10459. (match* (s t)
  10460. [(t1 t2) #:when (equal? t1 t2) v]
  10461. [('Any t2)
  10462. (match t2
  10463. [`(,ts ... -> ,rt)
  10464. (define any->any `(,@(for/list ([t ts]) 'Any) -> Any))
  10465. (define v^ (apply-project v any->any))
  10466. (apply-cast v^ any->any `(,@ts -> ,rt))]
  10467. [`(Vector ,ts ...)
  10468. (define vec-any `(Vector ,@(for/list ([t ts]) 'Any)))
  10469. (define v^ (apply-project v vec-any))
  10470. (apply-cast v^ vec-any `(Vector ,@ts))]
  10471. [else (apply-project v t2)])]
  10472. [(t1 'Any)
  10473. (match t1
  10474. [`(,ts ... -> ,rt)
  10475. (define any->any `(,@(for/list ([t ts]) 'Any) -> Any))
  10476. (define v^ (apply-cast v `(,@ts -> ,rt) any->any))
  10477. (apply-inject v^ (any-tag any->any))]
  10478. [`(Vector ,ts ...)
  10479. (define vec-any `(Vector ,@(for/list ([t ts]) 'Any)))
  10480. (define v^ (apply-cast v `(Vector ,@ts) vec-any))
  10481. (apply-inject v^ (any-tag vec-any))]
  10482. [else (apply-inject v (any-tag t1))])]
  10483. [(`(Vector ,ts1 ...) `(Vector ,ts2 ...))
  10484. (define x (gensym 'x))
  10485. (define cast-reads (for/list ([t1 ts1] [t2 ts2])
  10486. `(function (,x) ,(Cast (Var x) t1 t2) ())))
  10487. (define cast-writes
  10488. (for/list ([t1 ts1] [t2 ts2])
  10489. `(function (,x) ,(Cast (Var x) t2 t1) ())))
  10490. `(vector-proxy ,(vector v (apply vector cast-reads)
  10491. (apply vector cast-writes)))]
  10492. [(`(,ts1 ... -> ,rt1) `(,ts2 ... -> ,rt2))
  10493. (define xs (for/list ([t2 ts2]) (gensym 'x)))
  10494. `(function ,xs ,(Cast
  10495. (Apply (Value v)
  10496. (for/list ([x xs][t1 ts1][t2 ts2])
  10497. (Cast (Var x) t2 t1)))
  10498. rt1 rt2) ())]
  10499. ))
  10500. \end{lstlisting}
  10501. \caption{The \code{apply-cast} auxiliary method.}
  10502. \label{fig:apply-cast}
  10503. \end{figure}
  10504. The interpreter for $R'_9$ is defined in
  10505. Figure~\ref{fig:interp-R9-prime}, with the case for \code{Cast}
  10506. dispatching to \code{apply-cast}. To handle the addition of vector
  10507. proxies, we update the vector primitives in \code{interp-op} using the
  10508. auxiliary functions in Figure~\ref{fig:guarded-vector}.
  10509. \begin{figure}[tbp]
  10510. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  10511. (define interp-R9-prime-class
  10512. (class interp-R8-class
  10513. (super-new)
  10514. (inherit apply-fun apply-inject apply-project)
  10515. (define/override (interp-op op)
  10516. (match op
  10517. ['vector-length guarded-vector-length]
  10518. ['vector-ref guarded-vector-ref]
  10519. ['vector-set! guarded-vector-set!]
  10520. ['any-vector-ref (lambda (v i)
  10521. (match v [`(tagged ,v^ ,tg)
  10522. (guarded-vector-ref v^ i)]))]
  10523. ['any-vector-set! (lambda (v i a)
  10524. (match v [`(tagged ,v^ ,tg)
  10525. (guarded-vector-set! v^ i a)]))]
  10526. ['any-vector-length (lambda (v)
  10527. (match v [`(tagged ,v^ ,tg)
  10528. (guarded-vector-length v^)]))]
  10529. [else (super interp-op op)]
  10530. ))
  10531. (define/override ((interp-exp env) e)
  10532. (define (recur e) ((interp-exp env) e))
  10533. (match e
  10534. [(Value v) v]
  10535. [(Cast e src tgt) (apply-cast (recur e) src tgt)]
  10536. [else ((super interp-exp env) e)]))
  10537. ))
  10538. (define (interp-R9-prime p)
  10539. (send (new interp-R9-prime-class) interp-program p))
  10540. \end{lstlisting}
  10541. \caption{The interpreter for $R'_9$.}
  10542. \label{fig:interp-R9-prime}
  10543. \end{figure}
  10544. \begin{figure}[tbp]
  10545. \begin{lstlisting}[basicstyle=\ttfamily\footnotesize]
  10546. (define (guarded-vector-ref vec i)
  10547. (match vec
  10548. [`(vector-proxy ,proxy)
  10549. (define val (guarded-vector-ref (vector-ref proxy 0) i))
  10550. (define rd (vector-ref (vector-ref proxy 1) i))
  10551. (apply-fun rd (list val) 'guarded-vector-ref)]
  10552. [else (vector-ref vec i)]))
  10553. (define (guarded-vector-set! vec i arg)
  10554. (match vec
  10555. [`(vector-proxy ,proxy)
  10556. (define wr (vector-ref (vector-ref proxy 2) i))
  10557. (define arg^ (apply-fun wr (list arg) 'guarded-vector-set!))
  10558. (guarded-vector-set! (vector-ref proxy 0) i arg^)]
  10559. [else (vector-set! vec i arg)]))
  10560. (define (guarded-vector-length vec)
  10561. (match vec
  10562. [`(vector-proxy ,proxy)
  10563. (guarded-vector-length (vector-ref proxy 0))]
  10564. [else (vector-length vec)]))
  10565. \end{lstlisting}
  10566. \caption{The guarded-vector auxiliary functions.}
  10567. \label{fig:guarded-vector}
  10568. \end{figure}
  10569. \section{Lower Casts}
  10570. \label{sec:lower-casts}
  10571. \section{Expose Proxies}
  10572. \label{sec:expose-proxies}
  10573. \section{Closure Conversion}
  10574. \section{Explicate Control}
  10575. \section{Select Instructions}
  10576. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  10577. \chapter{Parametric Polymorphism}
  10578. \label{ch:parametric-polymorphism}
  10579. \index{parametric polymorphism}
  10580. \index{generics}
  10581. This chapter may be based on ideas from \citet{Cardelli:1984aa},
  10582. \citet{Leroy:1992qb}, \citet{Shao:1997uj}, or \citet{Harper:1995um}.
  10583. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  10584. %% \chapter{High-level Optimization}
  10585. %% \label{ch:high-level-optimization}
  10586. %% This chapter will present a procedure inlining pass based on the
  10587. %% algorithm of \citet{Waddell:1997fk}.
  10588. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  10589. \chapter{Appendix}
  10590. \section{Interpreters}
  10591. \label{appendix:interp}
  10592. \index{interpreter}
  10593. We provide interpreters for each of the source languages $R_0$, $R_1$,
  10594. $\ldots$ in the files \code{interp-R0.rkt}, \code{interp-R1.rkt}, etc.
  10595. The interpreters for the intermediate languages $C_0$ and $C_1$ are in
  10596. \code{interp-C0.rkt} and \code{interp-C1.rkt}. The interpreters for
  10597. $C_2$, $C_3$, pseudo-x86, and x86 are in the \key{interp.rkt} file.
  10598. \section{Utility Functions}
  10599. \label{appendix:utilities}
  10600. The utility functions described in this section are in the
  10601. \key{utilities.rkt} file of the support code.
  10602. \paragraph{\code{interp-tests}}
  10603. The \key{interp-tests} function runs the compiler passes and the
  10604. interpreters on each of the specified tests to check whether each pass
  10605. is correct. The \key{interp-tests} function has the following
  10606. parameters:
  10607. \begin{description}
  10608. \item[name (a string)] a name to identify the compiler,
  10609. \item[typechecker] a function of exactly one argument that either
  10610. raises an error using the \code{error} function when it encounters a
  10611. type error, or returns \code{\#f} when it encounters a type
  10612. error. If there is no type error, the type checker returns the
  10613. program.
  10614. \item[passes] a list with one entry per pass. An entry is a list with
  10615. four things:
  10616. \begin{enumerate}
  10617. \item a string giving the name of the pass,
  10618. \item the function that implements the pass (a translator from AST
  10619. to AST),
  10620. \item a function that implements the interpreter (a function from
  10621. AST to result value) for the output language,
  10622. \item and a type checker for the output language. Type checkers for
  10623. the $R$ and $C$ languages are provided in the support code. For
  10624. example, the type checkers for $R_1$ and $C_0$ are in
  10625. \code{type-check-R1.rkt}. The type checker entry is optional. The
  10626. support code does not provide type checkers for the x86 languages.
  10627. \end{enumerate}
  10628. \item[source-interp] an interpreter for the source language. The
  10629. interpreters from Appendix~\ref{appendix:interp} make a good choice.
  10630. \item[test-family (a string)] for example, \code{"r1"}, \code{"r2"}, etc.
  10631. \item[tests] a list of test numbers that specifies which tests to
  10632. run. (see below)
  10633. \end{description}
  10634. %
  10635. The \key{interp-tests} function assumes that the subdirectory
  10636. \key{tests} has a collection of Racket programs whose names all start
  10637. with the family name, followed by an underscore and then the test
  10638. number, ending with the file extension \key{.rkt}. Also, for each test
  10639. program that calls \code{read} one or more times, there is a file with
  10640. the same name except that the file extension is \key{.in} that
  10641. provides the input for the Racket program. If the test program is
  10642. expected to fail type checking, then there should be an empty file of
  10643. the same name but with extension \key{.tyerr}.
  10644. \paragraph{\code{compiler-tests}}
  10645. runs the compiler passes to generate x86 (a \key{.s} file) and then
  10646. runs the GNU C compiler (gcc) to generate machine code. It runs the
  10647. machine code and checks that the output is $42$. The parameters to the
  10648. \code{compiler-tests} function are similar to those of the
  10649. \code{interp-tests} function, and consist of
  10650. \begin{itemize}
  10651. \item a compiler name (a string),
  10652. \item a type checker,
  10653. \item description of the passes,
  10654. \item name of a test-family, and
  10655. \item a list of test numbers.
  10656. \end{itemize}
  10657. \paragraph{\code{compile-file}}
  10658. takes a description of the compiler passes (see the comment for
  10659. \key{interp-tests}) and returns a function that, given a program file
  10660. name (a string ending in \key{.rkt}), applies all of the passes and
  10661. writes the output to a file whose name is the same as the program file
  10662. name but with \key{.rkt} replaced with \key{.s}.
  10663. \paragraph{\code{read-program}}
  10664. takes a file path and parses that file (it must be a Racket program)
  10665. into an abstract syntax tree.
  10666. \paragraph{\code{parse-program}}
  10667. takes an S-expression representation of an abstract syntax tree and converts it into
  10668. the struct-based representation.
  10669. \paragraph{\code{assert}}
  10670. takes two parameters, a string (\code{msg}) and Boolean (\code{bool}),
  10671. and displays the message \key{msg} if the Boolean \key{bool} is false.
  10672. \paragraph{\code{lookup}}
  10673. % remove discussion of lookup? -Jeremy
  10674. takes a key and an alist, and returns the first value that is
  10675. associated with the given key, if there is one. If not, an error is
  10676. triggered. The alist may contain both immutable pairs (built with
  10677. \key{cons}) and mutable pairs (built with \key{mcons}).
  10678. %The \key{map2} function ...
  10679. \section{x86 Instruction Set Quick-Reference}
  10680. \label{sec:x86-quick-reference}
  10681. \index{x86}
  10682. Table~\ref{tab:x86-instr} lists some x86 instructions and what they
  10683. do. We write $A \to B$ to mean that the value of $A$ is written into
  10684. location $B$. Address offsets are given in bytes. The instruction
  10685. arguments $A, B, C$ can be immediate constants (such as \code{\$4}),
  10686. registers (such as \code{\%rax}), or memory references (such as
  10687. \code{-4(\%ebp)}). Most x86 instructions only allow at most one memory
  10688. reference per instruction. Other operands must be immediates or
  10689. registers.
  10690. \begin{table}[tbp]
  10691. \centering
  10692. \begin{tabular}{l|l}
  10693. \textbf{Instruction} & \textbf{Operation} \\ \hline
  10694. \texttt{addq} $A$, $B$ & $A + B \to B$\\
  10695. \texttt{negq} $A$ & $- A \to A$ \\
  10696. \texttt{subq} $A$, $B$ & $B - A \to B$\\
  10697. \texttt{callq} $L$ & Pushes the return address and jumps to label $L$ \\
  10698. \texttt{callq} \texttt{*}$A$ & Calls the function at the address $A$. \\
  10699. %\texttt{leave} & $\texttt{ebp} \to \texttt{esp};$ \texttt{popl \%ebp} \\
  10700. \texttt{retq} & Pops the return address and jumps to it \\
  10701. \texttt{popq} $A$ & $*\mathtt{rsp} \to A; \mathtt{rsp} + 8 \to \mathtt{rsp}$ \\
  10702. \texttt{pushq} $A$ & $\texttt{rsp} - 8 \to \texttt{rsp}; A \to *\texttt{rsp}$\\
  10703. \texttt{leaq} $A$,$B$ & $A \to B$ ($B$ must be a register) \\
  10704. \texttt{cmpq} $A$, $B$ & compare $A$ and $B$ and set the flag register ($B$ must not
  10705. be an immediate) \\
  10706. \texttt{je} $L$ & \multirow{5}{3.7in}{Jump to label $L$ if the flag register
  10707. matches the condition code of the instruction, otherwise go to the
  10708. next instructions. The condition codes are \key{e} for ``equal'',
  10709. \key{l} for ``less'', \key{le} for ``less or equal'', \key{g}
  10710. for ``greater'', and \key{ge} for ``greater or equal''.} \\
  10711. \texttt{jl} $L$ & \\
  10712. \texttt{jle} $L$ & \\
  10713. \texttt{jg} $L$ & \\
  10714. \texttt{jge} $L$ & \\
  10715. \texttt{jmp} $L$ & Jump to label $L$ \\
  10716. \texttt{movq} $A$, $B$ & $A \to B$ \\
  10717. \texttt{movzbq} $A$, $B$ &
  10718. \multirow{3}{3.7in}{$A \to B$, \text{where } $A$ is a single-byte register
  10719. (e.g., \texttt{al} or \texttt{cl}), $B$ is a 8-byte register,
  10720. and the extra bytes of $B$ are set to zero.} \\
  10721. & \\
  10722. & \\
  10723. \texttt{notq} $A$ & $\sim A \to A$ \qquad (bitwise complement)\\
  10724. \texttt{orq} $A$, $B$ & $A | B \to B$ \qquad (bitwise-or)\\
  10725. \texttt{andq} $A$, $B$ & $A \& B \to B$ \qquad (bitwise-and)\\
  10726. \texttt{salq} $A$, $B$ & $B$ \texttt{<<} $A \to B$ (arithmetic shift left, where $A$ is a constant)\\
  10727. \texttt{sarq} $A$, $B$ & $B$ \texttt{>>} $A \to B$ (arithmetic shift right, where $A$ is a constant)\\
  10728. \texttt{sete} $A$ & \multirow{5}{3.7in}{If the flag matches the condition code,
  10729. then $1 \to A$, else $0 \to A$. Refer to \texttt{je} above for the
  10730. description of the condition codes. $A$ must be a single byte register
  10731. (e.g., \texttt{al} or \texttt{cl}).} \\
  10732. \texttt{setl} $A$ & \\
  10733. \texttt{setle} $A$ & \\
  10734. \texttt{setg} $A$ & \\
  10735. \texttt{setge} $A$ &
  10736. \end{tabular}
  10737. \vspace{5pt}
  10738. \caption{Quick-reference for the x86 instructions used in this book.}
  10739. \label{tab:x86-instr}
  10740. \end{table}
  10741. \cleardoublepage
  10742. \section{Concrete Syntax for Intermediate Languages}
  10743. The concrete syntax for $C_0$, $C_1$, $C_2$ and $C_3$ is
  10744. defined in Figures~\ref{fig:c0-concrete-syntax},
  10745. \ref{fig:c1-concrete-syntax}, \ref{fig:c2-concrete-syntax},
  10746. and \ref{fig:c3-concrete-syntax}, respectively.
  10747. \begin{figure}[tbp]
  10748. \fbox{
  10749. \begin{minipage}{0.96\textwidth}
  10750. \[
  10751. \begin{array}{lcl}
  10752. \Atm &::=& \Int \mid \Var \\
  10753. \Exp &::=& \Atm \mid \key{(read)} \mid \key{(-}~\Atm\key{)} \mid \key{(+}~\Atm~\Atm\key{)}\\
  10754. \Stmt &::=& \Var~\key{=}~\Exp\key{;} \\
  10755. \Tail &::= & \key{return}~\Exp\key{;} \mid \Stmt~\Tail \\
  10756. C_0 & ::= & (\itm{label}\key{:}~ \Tail)\ldots
  10757. \end{array}
  10758. \]
  10759. \end{minipage}
  10760. }
  10761. \caption{The concrete syntax of the $C_0$ intermediate language.}
  10762. \label{fig:c0-concrete-syntax}
  10763. \end{figure}
  10764. \begin{figure}[tbp]
  10765. \fbox{
  10766. \begin{minipage}{0.96\textwidth}
  10767. \small
  10768. \[
  10769. \begin{array}{lcl}
  10770. \Atm &::=& \gray{ \Int \mid \Var } \mid \itm{bool} \\
  10771. \itm{cmp} &::= & \key{eq?} \mid \key{<} \\
  10772. \Exp &::=& \gray{ \Atm \mid \key{(read)} \mid \key{(-}~\Atm\key{)} \mid \key{(+}~\Atm~\Atm\key{)} } \\
  10773. &\mid& \LP \key{not}~\Atm \RP \mid \LP \itm{cmp}~\Atm~\Atm\RP \\
  10774. \Stmt &::=& \gray{ \Var~\key{=}~\Exp\key{;} } \\
  10775. \Tail &::= & \gray{ \key{return}~\Exp\key{;} \mid \Stmt~\Tail }
  10776. \mid \key{goto}~\itm{label}\key{;}\\
  10777. &\mid& \key{if}~\LP \itm{cmp}~\Atm~\Atm \RP~ \key{goto}~\itm{label}\key{;} ~\key{else}~\key{goto}~\itm{label}\key{;} \\
  10778. C_1 & ::= & \gray{ (\itm{label}\key{:}~ \Tail)\ldots }
  10779. \end{array}
  10780. \]
  10781. \end{minipage}
  10782. }
  10783. \caption{The concrete syntax of the $C_1$ intermediate language.}
  10784. \label{fig:c1-concrete-syntax}
  10785. \end{figure}
  10786. \begin{figure}[tbp]
  10787. \fbox{
  10788. \begin{minipage}{0.96\textwidth}
  10789. \small
  10790. \[
  10791. \begin{array}{lcl}
  10792. \Atm &::=& \gray{ \Int \mid \Var \mid \itm{bool} } \\
  10793. \itm{cmp} &::= & \gray{ \key{eq?} \mid \key{<} } \\
  10794. \Exp &::=& \gray{ \Atm \mid \key{(read)} \mid \key{(-}~\Atm\key{)} \mid \key{(+}~\Atm~\Atm\key{)} } \\
  10795. &\mid& \gray{ \LP \key{not}~\Atm \RP \mid \LP \itm{cmp}~\Atm~\Atm\RP } \\
  10796. &\mid& \LP \key{allocate}~\Int~\Type \RP \\
  10797. &\mid& (\key{vector-ref}\;\Atm\;\Int) \mid (\key{vector-set!}\;\Atm\;\Int\;\Atm)\\
  10798. &\mid& \LP \key{global-value}~\Var \RP \mid \LP \key{void} \RP \\
  10799. \Stmt &::=& \gray{ \Var~\key{=}~\Exp\key{;} } \mid \LP\key{collect}~\Int \RP\\
  10800. \Tail &::= & \gray{ \key{return}~\Exp\key{;} \mid \Stmt~\Tail }
  10801. \mid \gray{ \key{goto}~\itm{label}\key{;} }\\
  10802. &\mid& \gray{ \key{if}~\LP \itm{cmp}~\Atm~\Atm \RP~ \key{goto}~\itm{label}\key{;} ~\key{else}~\key{goto}~\itm{label}\key{;} } \\
  10803. C_2 & ::= & \gray{ (\itm{label}\key{:}~ \Tail)\ldots }
  10804. \end{array}
  10805. \]
  10806. \end{minipage}
  10807. }
  10808. \caption{The concrete syntax of the $C_2$ intermediate language.}
  10809. \label{fig:c2-concrete-syntax}
  10810. \end{figure}
  10811. \begin{figure}[tp]
  10812. \fbox{
  10813. \begin{minipage}{0.96\textwidth}
  10814. \small
  10815. \[
  10816. \begin{array}{lcl}
  10817. \Atm &::=& \gray{ \Int \mid \Var \mid \key{\#t} \mid \key{\#f} }
  10818. \\
  10819. \itm{cmp} &::= & \gray{ \key{eq?} \mid \key{<} } \\
  10820. \Exp &::= & \gray{ \Atm \mid \LP\key{read}\RP \mid \LP\key{-}\;\Atm\RP \mid \LP\key{+} \; \Atm\;\Atm\RP
  10821. \mid \LP\key{not}\;\Atm\RP \mid \LP\itm{cmp}\;\Atm\;\Atm\RP } \\
  10822. &\mid& \gray{ \LP\key{allocate}\,\Int\,\Type\RP
  10823. \mid \LP\key{vector-ref}\, \Atm\, \Int\RP } \\
  10824. &\mid& \gray{ \LP\key{vector-set!}\,\Atm\,\Int\,\Atm\RP \mid \LP\key{global-value} \,\itm{name}\RP \mid \LP\key{void}\RP } \\
  10825. &\mid& \LP\key{fun-ref}~\itm{label}\RP \mid \LP\key{call} \,\Atm\,\Atm\ldots\RP \\
  10826. \Stmt &::=& \gray{ \ASSIGN{\Var}{\Exp} \mid \RETURN{\Exp}
  10827. \mid \LP\key{collect} \,\itm{int}\RP }\\
  10828. \Tail &::= & \gray{\RETURN{\Exp} \mid \LP\key{seq}\;\Stmt\;\Tail\RP} \\
  10829. &\mid& \gray{\LP\key{goto}\,\itm{label}\RP
  10830. \mid \IF{\LP\itm{cmp}\, \Atm\,\Atm\RP}{\LP\key{goto}\,\itm{label}\RP}{\LP\key{goto}\,\itm{label}\RP}} \\
  10831. &\mid& \LP\key{tail-call}\,\Atm\,\Atm\ldots\RP \\
  10832. \Def &::=& \LP\key{define}\; \LP\itm{label} \; [\Var \key{:} \Type]\ldots\RP \key{:} \Type \; \LP\LP\itm{label}\,\key{.}\,\Tail\RP\ldots\RP\RP \\
  10833. C_3 & ::= & \Def\ldots
  10834. \end{array}
  10835. \]
  10836. \end{minipage}
  10837. }
  10838. \caption{The $C_3$ language, extending $C_2$ (Figure~\ref{fig:c2-concrete-syntax}) with functions.}
  10839. \label{fig:c3-concrete-syntax}
  10840. \end{figure}
  10841. \cleardoublepage
  10842. \addcontentsline{toc}{chapter}{Index}
  10843. \printindex
  10844. \cleardoublepage
  10845. \bibliographystyle{plainnat}
  10846. \bibliography{all}
  10847. \addcontentsline{toc}{chapter}{Bibliography}
  10848. \end{document}
  10849. %% LocalWords: Dybvig Waddell Abdulaziz Ghuloum Dipanwita Sussman
  10850. %% LocalWords: Sarkar lcl Matz aa representable Chez Ph Dan's nano
  10851. %% LocalWords: fk bh Siek plt uq Felleisen Bor Yuh ASTs AST Naur eq
  10852. %% LocalWords: BNF fixnum datatype arith prog backquote quasiquote
  10853. %% LocalWords: ast Reynold's reynolds interp cond fx evaluator jane
  10854. %% LocalWords: quasiquotes pe nullary unary rcl env lookup gcc rax
  10855. %% LocalWords: addq movq callq rsp rbp rbx rcx rdx rsi rdi subq nx
  10856. %% LocalWords: negq pushq popq retq globl Kernighan uniquify lll ve
  10857. %% LocalWords: allocator gensym env subdirectory scm rkt tmp lhs Tt
  10858. %% LocalWords: runtime Liveness liveness undirected Balakrishnan je
  10859. %% LocalWords: Rosen DSATUR SDO Gebremedhin Omari morekeywords cnd
  10860. %% LocalWords: fullflexible vertices Booleans Listof Pairof thn els
  10861. %% LocalWords: boolean type-check notq cmpq sete movzbq jmp al xorq
  10862. %% LocalWords: EFLAGS thns elss elselabel endlabel Tuples tuples os
  10863. %% LocalWords: tuple args lexically leaq Polymorphism msg bool nums
  10864. %% LocalWords: macosx unix Cormen vec callee xs maxStack numParams
  10865. %% LocalWords: arg bitwise XOR'd thenlabel immediates optimizations
  10866. %% LocalWords: deallocating Ungar Detlefs Tene kx FromSpace ToSpace
  10867. %% LocalWords: Appel Diwan Siebert ptr fromspace rootstack typedef
  10868. %% LocalWords: len prev rootlen heaplen setl lt Kohlbecker dk multi
  10869. % LocalWords: Bloomington Wollowski definitional whitespace deref JM
  10870. % LocalWords: subexpression subexpressions iteratively ANF Danvy rco
  10871. % LocalWords: goto stmt JS ly cmp ty le ge jle goto's EFLAG CFG pred
  10872. % LocalWords: acyclic worklist Aho qf tsort implementer's hj Shidal
  10873. % LocalWords: nonnegative Shahriyar endian salq sarq uint cheney ior
  10874. % LocalWords: tospace vecinit collectret alloc initret decrement jl
  10875. % LocalWords: dereferencing GC di vals ps mcons ds mcdr callee's th
  10876. % LocalWords: mainDef tailcall prepending mainstart num params rT qb
  10877. % LocalWords: mainconclusion Cardelli bodyT fvs clos fvts subtype uj
  10878. % LocalWords: polymorphism untyped elts tys tagof Vectorof tyeq orq
  10879. % LocalWords: andq untagged Shao inlining ebp jge setle setg setge
  10880. % LocalWords: struct symtab Friedman's MacOS Nystrom alist sam kate
  10881. % LocalWords: alists arity github unordered pqueue exprs ret param
  10882. % LocalWords: tyerr bytereg dh dl JmpIf HasType Osterlund Jacek TODO
  10883. % LocalWords: Gamari GlobalValue ProgramDefsExp prm ProgramDefs vn
  10884. % LocalWords: FunRef TailCall tailjmp IndirectCallq TailJmp Gilray
  10885. % LocalWords: dereference unbox Dataflow versa dataflow Kildall rhs
  10886. % LocalWords: Kleene enqueue dequeue AssignedFree FV cnvt SetBang tg
  10887. % LocalWords: ValueOf typechecker