1

引言

Ontology 的 NeoVM 虛擬機新增加了 DCALL、HAS_KEY、KEYS 以及 VALUES 等幾條新的指令。因此，基于 NeoVM 的引用性動態(tài)語言對象的設(shè)計理論上可行，這可使得當前語言的支持能更接近原生語義。對象模型設(shè)計的必要性Ontology NeoVM 對用戶暴露的對象語義有4種，分別是 bytearray、array、struct 和 map。當前 Python、Go、C#編譯器的實現(xiàn)都是直接復用這4種對象語義，這樣一來就產(chǎn)生了幾個問題：

• 首先，高級語言的基本對象往往不止這幾種對象語義，就會出現(xiàn)對象語義多對一的情況。

  不同對象的運算有不同的行為，導致的后果是必須要犧牲其中一種對象的語義。

• 其次， 高級語言對象對應的底層對象，語義不一定是完全對等的。

綜上，需要設(shè)計一個較通用的對象模型框架，以適應不同語言的語義對象，滿足多語言智能合約的支持。以 Python 為例，Python 是引用性的動態(tài)類型語言，在編譯時獲取的信息量較少。當前 Ontology 的 Neptune 編譯器已基本實現(xiàn) Python 的運算邏輯及控制邏輯。靜態(tài)類型的語言如 Go和C#等，在編譯時即可處理類型檢查、對象語義區(qū)分等問題。但對于 Python 這類動態(tài)類型的語言，如果沒有較完備的對象內(nèi)存模型，其表達能力是有限的，不能精確區(qū)分不同對象的語義。本文基于 Ontology NeoVM 提出一種引用性動態(tài)語言內(nèi)存模型的設(shè)計，作為升級重構(gòu) Neptune 以及 Go 編譯器和更精確實現(xiàn)其它語言編譯器的理論分析。

2

對象模型

理論上，底層指令的語義模型需要足夠簡單抽象，才能滿足不同類型語言語義的實現(xiàn)。而且很難有一套指令架構(gòu)，能滿足所有語言語義的運行要求。所以絕大多數(shù)高級語言都是重新定義特定的語義模型，構(gòu)建在特定虛擬機之上運行。而相對底層的語言如 Rust，C 和 C++等則直接編譯后運行在 CPU 上。內(nèi)存對象模型最佳的方式是不直接使用 Ontology NeoVM 的內(nèi)置語義對象，而是重新根據(jù)語言特性設(shè)計其對象模型，更精準的語義對開發(fā)者更友好。但是重寫設(shè)計對象語義的代價在于，相同的邏輯實現(xiàn)，會產(chǎn)生數(shù)倍于當前實現(xiàn)編譯生成的字節(jié)碼，且編譯器的實現(xiàn)會更復雜。當前按照 Python 一切皆對象的語義設(shè)計，所有對象使用 map 或者 array 實現(xiàn)。為簡化表達，這里假設(shè)使用 map 實現(xiàn)對象。map 的第一個 key 為內(nèi)置的__type__或用編碼表示，編譯器會檢查屬性 key 字段不屬于系統(tǒng)預留字段。在 Python 中，基本對象類型為：Number、string、List、Tuple、Set、Dict；基本運算符為[](subscript), +/-/*/%///以及 le 等。而這些運算符號是相應對象的成員屬性。在運行時，可通過 type 字段，對運算符做不同的語義區(qū)分。同樣的， 函數(shù)也是對象。各對象可用如下結(jié)構(gòu)表示：{"__type__":"function",?"offset":xxx}{"__type__":"int", "__value__":value}{"__type__":"string", "__value__":value}{"__type__":"list", "__value__":lsitvalue}{"__type__":"map",?"__value__":mapvalue}在具體的實現(xiàn)中， 由于字符串會占用較大的字節(jié)碼空間或影響性能，對于全局結(jié)構(gòu)，可以靜態(tài)映射為整數(shù)表示。

3

符號表及重定位

為實現(xiàn)動態(tài)類型， 符號表需要保存在運行時環(huán)境，即全局運行時對象環(huán)境。對于加減乘除等運算，使用對象類型結(jié)合運算符名的修飾方式可確定函數(shù)對象；而對于對象的其他成員函數(shù)，使用對象名結(jié)合成員函數(shù)名修飾方式。而重定位的時機是編譯完成時，所有的函數(shù)偏移已確定。在系統(tǒng)構(gòu)建好全局對象后，立即跳轉(zhuǎn)到重定位函數(shù)去處理需要重定位的符號信息。當需要訪問對象時，可以正確獲取對象的偏移，如函數(shù)調(diào)用為偽代碼：function args # 可支持動態(tài)參數(shù)的參數(shù)棧結(jié)構(gòu)global object # 獲取全局運行時對象push function object index # 將函數(shù)對象編碼壓棧pickitem # 獲取函數(shù)對象。pick function object offset # 獲取函數(shù)偏移DCALL?#?跳轉(zhuǎn)

4

全局對象的靜態(tài)映射

由于直接使用符號索引，會導致字節(jié)碼增大，且 ARRAY 字節(jié)碼的處理性能相對 map 更高，所以編譯時盡量減少符號的壓棧，而使用靜態(tài)符號表的方式，將全局或局部變量，映射為 index，減少字節(jié)碼的生成，提高性能。同時，在編譯時檢查出更多的語法錯誤，如未定義，重復定義等。全局對象可保存在 array 結(jié)構(gòu)中：[funcobj, classobj, intobj, stringobj....]

5

成員對象訪問及對象繼承處理

如上所述，全局對象保存在全局運行時環(huán)境中，而局部對象保存在函數(shù)的局部運行時環(huán)境中，某個對象的成員變量在訪問之前，該對象已從運行時環(huán)境中取出。所以，在當訪問成員變量時，根據(jù)索引成員變量的 key 即可獲取。由于是動態(tài)類型，無法在編譯時根據(jù)信息映射為 index 整數(shù)，只能直接使用變量名。偽碼如下：push class objectpush member object # 編譯器根據(jù)成員對象名，生成指令dup # 復制一份作為臨時變量has_Key object # 判斷是否存在jmpifnot label0 # 如果不存在跳轉(zhuǎn)到label0 get inherit object # 獲取繼承對象，如果不存在繼承繼承，則運行時報錯swaplebal0:Pickitem????????????#?如果是函數(shù)訪問，則需要生成DCALL指令

6

運算符實現(xiàn)及重載

由于對象模型的變換，所有的運算符邏輯不能直接使用 NeoVM 的指令邏輯，需要用對應對象的邏輯實現(xiàn)。每個運算符的語義和特定的對象綁定。編譯時通過ast獲取運算符。對于不同的對象，編譯時生成不同的對象運算符函數(shù)；運行時根據(jù)對象類型的不同跳轉(zhuǎn)到相應的對象處理函數(shù)。比如 string 對象的加法和int對象加法，是兩個不同的函數(shù)實現(xiàn)。所以根據(jù)以上方法，任何對象，都可以重載 add 函數(shù)，實現(xiàn)對象的新的加法語義定義。其他運算類似。對于系統(tǒng)內(nèi)建類型，如 Int、string、list、map。都需要在編譯時生成內(nèi)建的運算符處理函數(shù)。

7

控制邏輯

控制邏輯與對象語義關(guān)系不大，但是控制指令在判斷時需要將對象轉(zhuǎn)換成 Ontology NeoVM 的 Boolean 或 big.int。

8

NeoVM Service 處理

NeoVM service 返回的數(shù)據(jù)都是 Ontology NeoVM 語義上的， 所以需要根據(jù)返回類型的不同，構(gòu)造為當前設(shè)計的對象類型。對 Syscall 的翻譯，不能直接使用 Syscall + servicename 的方式。后面還需要加上對應的對象類型構(gòu)造。而對于 syscall 傳入?yún)?shù)是，也需要復原成 Ontology NeoVM 底層語義的對象。

9

結(jié)論

由于語言語義的多樣性，僅僅直接復用 Ontology NeoVM 原生語義，是不能很好的實現(xiàn)支持語言原生語義的。對象模型的設(shè)計，可以使得智能合約支持的語言語義更加精確，擴展能力更強，通過優(yōu)化不斷地接近原生語義，對現(xiàn)有的內(nèi)建對象 int、 string、list、map 支持更豐富精確的原生語義，對開發(fā)者更友好。但是，這同時會產(chǎn)生數(shù)倍于當前編譯器生成的字節(jié)碼，而且編譯器的實現(xiàn)更加復雜。

上期回顧

下列選項表述正確的是？?

A. Ontology Wasm 只支持使用 Rust 語言開發(fā)?

B. Ontology-wasm-cdt-rust 已經(jīng)封裝了鏈上數(shù)據(jù)增刪改查的操作方法

C. 在使用 Rust 進行 Ontology Wasm 合約開發(fā)時，開發(fā)者需要自己實現(xiàn)與本體區(qū)塊鏈交互的接口?

D. ontio_std 庫不提供鏈上數(shù)據(jù)的模擬

恭喜@康有為【深耕區(qū)塊鏈】@強子 @星鉆1??率先答對，請私信后臺收件地址

本期互動

下列哪個說法不正確？

A. Ontology NeoVM 對用戶暴露的對象語義有4種，分別是 bytearray、array、struct 和 map

B. 當前 Ontology 的 Neptune 編譯器已基本實現(xiàn) Python 的運算邏輯及控制邏輯

C. 內(nèi)存對象模型最佳的方式是不直接使用 Ontology NeoVM 的內(nèi)置語義對象，而是重新根據(jù)語言特性設(shè)計其對象模型

D. 對象模型的設(shè)計不會使得相關(guān)編譯器的實現(xiàn)更加復雜

請將答案私信后臺，前三位搶答對的小伙伴可以收到本體記事本一個噢~

---

步驟1：關(guān)注「本體研究院」官方賬號；

點擊文章最上方藍色字

或在微信搜索框內(nèi)查找“本體研究院”

或 ontologyresearch

點擊關(guān)注

步驟2：將答案填寫至對話框并發(fā)送

總結(jié)

以上是生活随笔為你收集整理的c++对象回收string类型成员时coredump_本体技术视点 | 虚拟机中引用性动态语言对象模型思考...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。