# NCKU 1142_編譯系統 COMPILER CONSTRUCTION 作業規劃以及說明

<br>

## 「文言」Wenyan Lang x LLVM

### 何以用文言？

<img src=https://hackmd.io/_uploads/rJe5SHdjZg.png height=400/>

開玩笑的，主要是現在lexer跟parser已經不是重點，況且考試也都有讓大家練習到，AI也早就很擅長寫這些。
現在業界更需要的是對於自訂硬體的編譯器，以及針對 AI 矩陣運算的底層加速。
雖然這堂課不包含自訂硬體的部分，但我想要大家透過實作『文言轉 LLVM IR』來探索這套生態系。

### 痛點與異質運算趨勢

業界目前的痛點，在於極度缺乏能夠處理中介碼（IR）、執行編譯器最佳化（Optimization Pass）的人才，而過去的傳統編譯器主要針對 CPU 設計，無法有效處理高度平行化的張量運算（Tensor Operations）。
而現代業界急需能將高階語義（像是矩陣運算）精準、高效地轉換並映射到自訂硬體架構上的編譯技術，以徹底榨出硬體的極限算力。
所以我相信，理解如何生成並優化 IR，是進入異質運算與現代 AI 編譯器領域的必備基礎。

### 從 RISC-V 到 MLIR/LLVM 生態系

<img src=https://memeprod.sgp1.digitaloceanspaces.com/user-wtf/1691297781095.jpg height=350/>

還記得大二下計算機組織學到的 RISC-V 嗎? 還有大三上的 PIC18 嗎?
原本想要使用riscv延續計算機組織，但我記得開發環境建置比較麻煩，且應用面向相對單一，所以決定使用LLVM IR。
LLVM 的架構允許我們對接不同的後端，包含利用其機制將特定的數學運算編譯並交由 GPU 執行。
理解如何生成並優化 IR，是進入異質運算與 AI 編譯器領域的基礎。

這次作業採用現代 AI 編譯器（OpenAI Triton）的底層核心技術：MLIR 與 LLVM 生態系。
透過這套架構，我們能夠直接對接不同的硬體後端，將特定的數學運算編譯並交由伺服器端的 GPU 執行，這是目前最能貼近業界 AI 底層基礎設施的實作方式。

<div style="width: 250px; text-align: center; ">
<img style="width: 100%;" src=https://llvm.org/img/DragonMedium.png/>
<br>
<span style="text-decoration: line-through;">所以說青眼白龍是很強的。</span>
</div>

### 從語法解析到 GPU 硬體加速

在學習階段的初期，我們先不涉及複雜的硬體後端。經過前兩次作業，有了基本的編譯器前端概念後，這學期的最終目標是實作一個能將『文言』（Wenyan Lang）的延伸矩陣語言『方程術』，使用 Bison yacc / flex 工具實做編譯器，編譯並在 GPU 上執行，達到加速的效果。

<br>

## 三次作業的規劃

### 第一次作業

使用 Flex 工具，針對『文言』語言的原始程式碼進行詞法分析（Lexical Analysis）。透過設定 Regular Expression 將字串轉換為有效的標記（Tokens），建立編譯器的第一道基礎處理單元。

簡單的示意圖:

### 第二次作業

針對『文言』進行語法分析（Syntax Analysis）與基礎中介碼生成（IR Generation）。
在作業一的基礎上，加入 Bison (Yacc) 工具建構抽象語法樹（AST）。針對標準的控制邏輯與算術運算，生成對應的 LLVM IR，並透過 LLVM Toolchain 編譯成可在 CPU 上執行的執行檔。

簡單的示意圖:

### 第三次作業

擴充語法樹以支援『方程術』的矩陣運算，並開始接觸異質運算的後端編譯管線。
不用擔心會不會太困難，我會適度提供包裝好的 IR 生成函式給大家。只需要設計並走訪 AST，在遇到矩陣操作的節點時呼叫對應的函式，就能在記憶體中正確生成高階的 MLIR 中介碼（例如 `linalg` 方言的矩陣操作）。

這些生成的 MLIR 將會自動被降級（Lowering），並經由 LLVM 的 NVPTX 後端編譯為 GPU 機器碼。最後，大家可以在自己的 GPU 或是我們提供的伺服器上執行編譯出的程式，量化比較相同矩陣運算在 CPU 與 GPU 上的執行時間差異，具體驗證編譯器對接底層硬體所帶來的加速效益。

<br>

## 「文言」Wenyan Lang - 緣起

大家可能會好奇，為什麼會有這麼有趣的程式語言？其實「文言」Wenyan Lang 是由當時卡內基梅隆大學（CMU）的一位大四學生黃令東在 2019 年開發的。

它跟市面上那些只是把 `if` 換成「如果」、`while` 換成「當」的中文程式語言不一樣。文言文程式語言有自己獨立的語法設計，寫出來的程式碼讀起來幾乎就像是一篇真正的古文。為了符合古人的書寫習慣，它主要只使用中文字和引號，甚至不需要換行。

有趣的是，作者當初是因為剛修完程式語言核心課程，萌生了讓中國典籍在程式碼中重生的想法。然後為了「逃避期末考複習」，他利用閒暇時間只花了短短四天就實作出了核心功能。
他原本的編譯器主要是用 JavaScript 寫的，可以將原始碼轉譯成 JS、Python 或 Ruby 等高階語言。

不過在我們這門課中，我們要更硬核一點，不只是把它轉譯成其他語言，而是要挑戰搭配前面提到的技術，將它的語法解析並直接編譯成底層的 LLVM IR。

### 開源社群的狂歡 - 文言文生態系

大家不要以為這只是一個搞笑的玩具，它剛出來的時候其實在開源社群引起了一陣不小的旋風，很多工程師不僅把它當成一個真正的程式語言在玩，還為它建立了一套完整的生態系。

舉例來說，社群幫它開發了專屬的套件管理器「[文淵閣](https://github.com/wenyan-lang/wenyan/wiki/Packages-Manager)」（wyg），概念就像是 Node.js 的 npm 或是 Python 的 pip，讓開發者可以互相分享寫好的文言文模組（例如已經有人寫好了資料結構、標準輸出入的套件）。
還有給網頁用的 [Webpack](https://github.com/wenyan-lang/loader)、[Rollup.js](https://github.com/wenyan-lang/rollup-plugin) 插件，可以直接幫你把文言文編譯成真的可以在網頁上執行的Javascript
還有人開發了支援 VS Code 的擴充套件，提供 Syntax highlight、Snippets提示，甚至可以直接在編輯器裡編譯執行。

更誇張的是，各路神人還用文言文實作了各種經典的演算法（像是[快速排序](https://ide.wy-lang.org/?file=quicksort)、[曼德博集合](https://ide.wy-lang.org/?file=mandelbrot)等），也有人嘗試把它移植到 JVM 上。

這也是為什麼我會選擇它作為這次編譯器作業的主題，它不僅有相對嚴謹的語法定義（Language Specification），背後還有實際運作的生態系跟線上 IDE 可以讓大家交叉驗證。這會讓大家在實作編譯器前端的語法解析時，有明確的標準跟工具可以參考，而不是只在刻一個空洞的玩具。

### 「文言」Wenyan Lang - 工具

外籍生可以寫英文版的作業，如果想要挑戰中文，他有一個簡單的 [中英文對照表](https://github.com/alainsaas/wenyan/blob/master/wenyan-lang%20beginner%20cheatsheet.pdf) ，剩下的就只能問AI了。

覺得語法太難看的話的可以直接到 [Wenyan Online Compiler](https://ide.wy-lang.org/) 開檔案做測試，非常好用。
也有 [Wenyanizer](https://zxch3n.github.io/wenyanizer/) 工具可以把 Javascript 轉成 「文言」。

如果想要閱讀詳細規格可以看 [《文言陰符》Wenyan Book](https://book.wy-lang.org/) ，或是 Lisp grammar 的版本 [Wenyan Language Specification](https://wy-lang.org/spec) 。

### 編輯器設定以及中文字體

如果你使用 VSCode、Vim 或是 Sublime Text，可以使用 [Text Editors Support](https://github.com/wenyan-lang/wenyan/wiki/Text-Editors-Support) 來獲得 Syntax highlight、Snippets 等擴充功能。

[Vscode 插件傳送門](https://marketplace.visualstudio.com/items?itemName=antfu.wenyan-lang)

測資字體沒有對齊的話可以安裝這個中英文1:2的等寬字體 [Maple Mono](https://github.com/subframe7536/maple-font/releases) ，下載 MapleMono-CN.zip 安裝 MapleMono-CN-Regular。

#### Clion
Settings > Editor > Font > Typography Settings > Fallback font 設定為 Maple Mono CN

如果出現這個驚嘆號，要點進去把 Use ... font 的勾勾取消才會生效。

#### Vscode
Settings(UI) 搜尋 Font Family，新增 'Maple Mono CN'
或是 Settings(JSON) 新增 `"editor.fontFamily": "'Maple Mono CN', monospace"`

<br>

## 如何正確的使用AI

> 我不排斥大家使用AI來寫作業，但在使用AI前需要先搞懂語言模型，不要無腦使用AI，會被牽著鼻子走。
> 所以為了在這個時代背景下維持作業的難度，所以我決定讓大家來實做一個文言文編譯器，順便訓練大家使用AI的能力。

### 首先第一個問題，提示詞能不能用中文寫?

答案是可以，但2025年的研究指出，使用中文寫提示詞會讓模型準確率下降10%以上，有文章指出會下降更多而且速度會變慢。

- [Why We Recommend English for AI Coding: The 30% Performance Advantage No One’s Talking About](https://tao-hpu.medium.com/why-we-recommend-english-for-ai-coding-the-30-performance-advantage-no-ones-talking-about-1c4cba55c146)
- [ML²B: Multi-Lingual ML Benchmark For AutoML](https://arxiv.org/html/2509.22768v1)
- [mHumanEval - A Multilingual Benchmark to Evaluate Large Language
Models for Code Generation](https://aclanthology.org/2025.naacl-long.570.pdf)

#### mHumanEval Evaluation Results
*Class 5 languages, Pass@1 Performance Rates*

| Language (Code) | Claude 3.5 | GPT-4o | GPT-3.5 | DeepSeek-Coder | WizardCoder | Aya |
| :--- | :---: | :---: | :---: | :---: | :---: | :---: |
| **Arabic** (`arb_Arab`) | 0.831 | 0.846 | 0.719 | 0.859 | 0.650 | 0.590 |
| **German** (`deu_Latn`) | 0.846 | 0.833 | 0.730 | 0.863 | 0.670 | 0.620 |
| **English** (`eng_Latn`) | 0.938 | 0.910 | 0.770 | 0.902 | 0.800 | 0.650 |
| **French** (`fra_Latn`) | 0.835 | 0.850 | 0.693 | 0.849 | 0.650 | 0.608 |
| **Japanese** (`jpn_Jpan`) | 0.896 | 0.868 | 0.757 | 0.849 | 0.670 | 0.609 |
| **Spanish** (`spa_Latn`) | 0.880 | 0.852 | 0.759 | 0.854 | 0.610 | 0.609 |
| **Chinese** (`zho_Hans`) | 0.838 | 0.810 | 0.720 | 0.933 | 0.590 | 0.570 |

> Comparing LLMs’ performance (% in Pass@1) on mHumanEval - Class 5 languages. The languages are given as Flores-200 codes.

<br>

但實驗結果中有趣的是 DeepSeek 在中文方面的分數比英文還要高，中文提示詞準確率比GPT-4o高了10%，而且超越了GPT-4o的英文準確率。
這就是為什麼 DeepSeek 一出來，我們覺得很強的其中一個原因。

> 

然而代價就是缺少了稀有語言的支援，結果顯示在寫 C++ 的時候使用 Class 3 以下語言的提示詞，會造成準確率大幅下降，甚至無法使用的情況。

造成這個現象的其中一個原因是因為模型的訓練資料有接近一半都是英文的，而且相同的詞彙但不同語言embedded之後的向量，通常不會重合。

有其他語言學的研究發現每個文化對於同個物品會有一些歷史意義上差別，或是不同的使用習慣，造成不同語言對於相同事物的關聯性不同。
就算是使用維基百科資料訓練的embedding模型，同的物品也會在不同語言中出現巨大的差異([Comparing the semantic structures of lexicon of Mandarin and English](https://www.researchgate.net/publication/387880366_Comparing_the_semantic_structures_of_lexicon_of_Mandarin_and_English))
> 

大家可能會以為把人類的語言轉換為向量之後，就會像Google翻譯一樣，翻譯成一種模型看得懂的一種語言，但其實不然。

### 結論

這個大概是2025年中旬的研究了，不確定現在大模型的中文能力是否有提升，我目前還有其他人測試下來似乎沒什麼差別，大家參考看看就好。
就是說如果發現大模型寫文言文有點吃力的話，可能中文的Lexer就先手寫，轉換成英文的token之後再餵給模型看看，基本上模型寫Lisp grammar已經很強了。