如何理解clingrootsys原理剖析中的pme

如何理解clingrootsys原理剖析中的pme，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

動(dòng)態(tài)語(yǔ)言中的動(dòng)態(tài)類型語(yǔ)言

一般會(huì)誤以為動(dòng)態(tài)語(yǔ)言就是解釋語(yǔ)言。因?yàn)榻忉屜到y(tǒng)能動(dòng)態(tài)執(zhí)行代碼也往往意味著其被歸為動(dòng)態(tài)語(yǔ)言。但實(shí)際上動(dòng)態(tài)語(yǔ)言現(xiàn)在最常見(jiàn)的技術(shù)形式反而是一種稱為“動(dòng)態(tài)類型的動(dòng)態(tài)語(yǔ)言”，它往往依賴前端而不是后端。這造成的結(jié)果是：靜態(tài)語(yǔ)言系統(tǒng)和經(jīng)典的編譯->運(yùn)行系統(tǒng)也能產(chǎn)生“動(dòng)態(tài)語(yǔ)言”。 比如在編譯器實(shí)現(xiàn)中，實(shí)際上類型系統(tǒng)可以提出元類型，封裝有類型的基本信息，然后喂給后端的是元類型/對(duì)象產(chǎn)生的子類型/子對(duì)象樹(shù)的形式就可以 – 一個(gè)較原來(lái)復(fù)雜一點(diǎn)的數(shù)據(jù)結(jié)構(gòu)，然后其它過(guò)程保持不變喂給后端。運(yùn)行期的類型信息照樣在運(yùn)行期可保留甚至動(dòng)態(tài)演變。這難道不是動(dòng)態(tài)語(yǔ)言嗎？ （這種邏輯也可以工作在庫(kù)級(jí)和工具鏈級(jí)，即語(yǔ)言系統(tǒng)實(shí)現(xiàn)的外部，比如pme，它的實(shí)現(xiàn)只要binding就可以了—而binding實(shí)際上是另一種編譯器意義上的前端翻譯，就行了，而執(zhí)行時(shí)是現(xiàn)成的，比如qtmoc為qtcpp源碼模式生成的字典，這就是為什么binding也能生成一種動(dòng)態(tài)語(yǔ)言系統(tǒng)，后端執(zhí)行時(shí)可以是靜態(tài)的，但主要喂給它的是如PEM這樣的業(yè)已包含類型系統(tǒng)–元類型系統(tǒng)，會(huì)將類型系統(tǒng)保持到運(yùn)行期就可以了） 你可能會(huì)為編譯過(guò)程的這些種種感到迷惑，但實(shí)際上這里面所有的技術(shù)，跟傳統(tǒng)靜態(tài)編譯語(yǔ)言系統(tǒng) – 你學(xué)到的最簡(jiǎn)單的編譯原理實(shí)現(xiàn)，是一個(gè)外觀的。而編譯前端，解釋前端，binding，這三個(gè)詞都包含了轉(zhuǎn)譯。目標(biāo)碼可以是平臺(tái)碼也可以是中間碼，供運(yùn)行。所有這些，都不能改變所有用編譯原理實(shí)現(xiàn)的語(yǔ)言系統(tǒng)共享同樣的產(chǎn)品外觀（都有該有的部分，只是呈現(xiàn)出了不同的形式）。回到系列文章第一篇的文頭那些話，用這些通讀所有復(fù)雜語(yǔ)言系統(tǒng)的定性你才能不致迷糊。

Pme為靜態(tài)語(yǔ)言模擬了動(dòng)態(tài)語(yǔ)言特征

Pme, poperty,method,event，是對(duì)反射機(jī)制的一種實(shí)現(xiàn)，加了反射機(jī)制實(shí)際上在靜態(tài)類型之上加了一門新的語(yǔ)言，和庫(kù)級(jí)運(yùn)行時(shí)，可在運(yùn)行時(shí)查詢到整個(gè)活動(dòng)對(duì)象樹(shù)，及每個(gè)類的場(chǎng)景圖，成員屬性。PME是組件的一種通用實(shí)現(xiàn)方式。 而且，這種兼具object io特性的pme機(jī)制，可為運(yùn)行時(shí)通過(guò)外在的編輯器改變objectlvl的程序邏輯提供了可能。借助PME組件的并持久化將成員屬性什么的持久到XML等載體。下一次需要時(shí)又可加載進(jìn)來(lái)（僅限代碼中的成員數(shù)據(jù)）。 而只有在cling/rootsys這種大環(huán)境中，pme與JIT合作，這種動(dòng)態(tài)性才得到最佳發(fā)揮，DLL加載終于通過(guò)JIT，變成了語(yǔ)言系統(tǒng)的功能。而不再停留在作為操作系統(tǒng)的一種機(jī)制，而pme模塊可以動(dòng)態(tài)加載，這在開(kāi)發(fā)上體現(xiàn)為，pme DLL體內(nèi)的邏輯是固定的?？筛淖兊某绦蜻壿嬍荄LL外的那部分。那個(gè)定制腳本部分和你的APP邏輯部分，可以是JIT CPP源碼（這里除了PME支持的代碼中的成員數(shù)據(jù)外，整個(gè)代碼都可持久，The interpreted and JITted C++ shares the same virtual memory space as the app itsel。）。有沒(méi)有感覺(jué)有腳本的樣子？直到這里，cling/rootsys開(kāi)始有了同時(shí)能模擬了腳本語(yǔ)言式的解釋效果和動(dòng)態(tài)加載效果，可謂嘆絕。

Cling/rootsys中的pme字典生成

如果說(shuō)cling call into raw dll靠的是符號(hào)，受JIT和操作系統(tǒng)DLL機(jī)制支持，而call into PME模塊靠字典信息非符號(hào)，動(dòng)態(tài)加載pme組件和發(fā)現(xiàn)組件里的OBJ樹(shù)需要PME支持，因此需要自實(shí)現(xiàn)。這是為何呢 這實(shí)際上最重要的還是因?yàn)閖it call into native libs只是使符合變得可見(jiàn)而已。而加載DLL中的資源，是普通的native langsys的功能，于是作為僅僅是執(zhí)行引擎向OS的傳手，llvm也可以而已。但其rootsys libs的pme是庫(kù)級(jí)的，cling代碼可以直接call into native libs，但不能call into rootsys libs，因?yàn)樗鼈兪怯衟me dicts as bindings的（不能直接通過(guò)加載的方式使其為cling可見(jiàn)必須通過(guò)對(duì)cling的封裝變成rootcling才可以）。因此，cling除了jit，和pme，還需要一個(gè)手動(dòng)或自動(dòng)添加字典binding信息使pme module和普通raw c dll(那種業(yè)已解析為簡(jiǎn)單符號(hào)可直接加載的模塊)變得一樣。的方式，比如一個(gè)手動(dòng)/自動(dòng)DICT生成器。生成到raw cpp code傳給LLVM后端。 帶著這些觀點(diǎn)，繼續(xù)來(lái)看看cling/rootsys中的對(duì)應(yīng)物，即其對(duì)pme模塊的支持-aclic。 ACliC只是將pme模塊形成加了pme字典的dll的工具。cling is faster building compiled code, but ACLiC can reuse it. Cling產(chǎn)生jit碼是高速編譯器產(chǎn)生的類解釋器效果，而aclic可以在庫(kù)級(jí)反射層面利用它。前面提過(guò)，將raw cpp改造成類似qtcpp的新語(yǔ)言系統(tǒng)，所有模塊必須經(jīng)過(guò)字典封裝，這個(gè)過(guò)程也稱binding。Rootsys即是這樣的一門新語(yǔ)言系統(tǒng)。 在實(shí)現(xiàn)上，aliac是以patch cling的方式加上去到rootcling的。因此.L ++的方式產(chǎn)生so文件，只用于為pme模塊產(chǎn)生dict 模塊并鏈接好。

附：對(duì)于qtcling，有mocng，是基于clang的qt moc.exe重實(shí)現(xiàn)，這也可以作為cling的patch組件，類似aliac的方式加到qtcling,使之具備發(fā)現(xiàn)源碼中有pme邏輯即自動(dòng)生成dict模塊的功能，to give it the ability to produce “automic dict generator for qt extending cpp syntaxs” 來(lái)完成對(duì)整個(gè)qt libs的從源碼級(jí)的重新編譯封裝，最終完成整個(gè)qtcling語(yǔ)言系統(tǒng)的構(gòu)建。

關(guān)于如何理解clingrootsys原理剖析中的pme問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。