再次失敗.

這次只做到第五步就進(jìn)行不了咯,

1,這個(gè)編譯器不是生成機(jī)器碼, 而是匯編, 我在win上msys2里, 此編譯器實(shí)現(xiàn)了AT&T語法和Intel語法, AT&T語法生成的匯編無法用匯編器編譯,as nasm都試過了不行, 換成Intel語法版本的,用nasm可以編譯了, 但是運(yùn)行的時(shí)候出現(xiàn)段錯(cuò)誤. 這就超出我的知識(shí)范圍了, 我無法處理.

2,在C|C++里, 若是要使用Unicode,需要改動(dòng)很多東西, 比如類型,處理相應(yīng)類型的標(biāo)準(zhǔn)庫(kù)函數(shù), 光是這里面的幾十種搭配, 你要是沒經(jīng)驗(yàn)不懂, 基本完全做不了事.

這次我盡力了, C系列C語族果然是天坑.

不過這個(gè)編譯器的前面部分, 僅僅只運(yùn)行解釋器倒是沒什么問題, 一旦走到跟機(jī)器綁定的匯編, 加上老舊的匯編器, 基本百分百一腳一個(gè)坑, 想要實(shí)現(xiàn)從機(jī)器碼到匯編這一步的分解方案, 基本這幾十年都會(huì)很難咯, 一是沒人關(guān)注,二是有興趣的基本上又不懂, 完全就是知識(shí)隔絕區(qū), 底層實(shí)現(xiàn)中文漢字編程, 沒有一個(gè)人能解決!

路轉(zhuǎn)峰回地說, 用C寫解釋器倒是沒什么問題, 甚至全中文漢字編寫, 加上Unicode utf8的支持也沒問題. 或許這就是降維打擊吧, 解釋器的性能永遠(yuǎn)無法超過編譯器. JIT那也是涉及到了匯編的, 一旦涉及匯編, 又回到了上面說的問題.

當(dāng)然也可以在解釋器解析完了后那里直接內(nèi)嵌機(jī)器碼, 不知道有沒有人這樣做過. 可能太難了吧.

冷孤獨(dú)2020/用C漢字編程 - Gitee.com