Aros/開發人員/LLVM
LLVM 是一個編譯器框架。像 GCC 一樣，它為不同的解析器提供前端。(C 和 C++ 使用 Clang 前端，而 GCC 則有自己的前端，例如 G++ 用於 C++，G77 用於 Fortran。) 所有支援的語言都使用一個通用的最佳化階段。後端支援不同型別的處理器。(x86、AMD64、PPC 和 ARM 都受到 GCC 和 LLVM 的支援。) 為了使 Clang C/C++ 編譯器和其他基於 LLVM 的編譯器能夠與 AROS 68k 協同工作，我們需要為 68k 處理器建立一個 LLVM 後端。
此外，LLVM 框架相對於 GCC 框架有一些優勢：LLVM 具有 JIT 編譯模式，因此可用於建立 Java 虛擬機器，而 GCJ 不支援 JIT 編譯；LLVM 的 JIT 也用於 Mesa 著色器模擬，用於不支援著色器的顯示卡；LLVM 完全用 C++ 編寫，因此更容易修改；最後，LLVM 生成程式碼的速度比 GCC 快。缺點是 LLVM 的程式碼生成器效率略低於最新版本的 GCC，而 GCC 已經存在 68k 後端。
AROS 應該使用 LLVM 的原因是，GCC 的開發者常常不想“浪費”時間在 68k 後端上，因為他們可以把時間花在更現代的處理器上，所以他們會拒絕那些會使後端更好的補丁。LLVM 具有用於其內部機器語言表示的位元碼檔案格式，因此一旦解決位元組序和記憶體對齊問題，它就可以從內部表示執行程式碼。
如果你指的是錯誤訊息，那麼答案是肯定的。Clang 的錯誤輸出更具描述性，通常會將錯誤追溯到發生錯誤行的單個詞素。如果你指的是“除錯輸出”作為除錯應用程式，那麼 LLDB 偵錯程式目前僅適用於 Macintosh 和可能適用於 Linux。它仍處於開發的早期階段。在其他系統上，GDB 仍然是 LLVM 輸出的唯一偵錯程式。
作為額外的優勢，LLVM 被設計為一套庫，因此它將與 IDE 良好整合。例如，Clang 能夠與主機 IDE 共享詞法資訊，以便進行語法高亮顯示。
關於他們使用的最佳化技術，LLVM 團隊中的一些人被禁止檢視 GPL 3 程式碼。這使得嘗試更新 LLVM 以匹配 GCC 功能變得很困難。
至於使其在 68k GCC 上工作，它可能已經完成了這種最佳化。GCC 4.5.x 完成的任何最佳化通常都在 GIMPLE 中間表示上完成，所以唯一的問題是後端在最終程式碼生成階段沒有生成經過微調的程式碼。
LLVM 將成為 AROS 編譯器工具箱的一個很好的補充。我的夢想是擁有一個系統，在這個系統中，程式可以例如從執行在 x86 桌上型電腦上遷移到執行在基於 ARM 的智慧手機上，再遷移到執行在 PPC A1/Pegasos 上。
LLVM 的 TableGen 實用程式，因此修改 x86 後端可能很困難。特別是由於他們對 AMD64 後端使用了一些與 x86 後端相同的模式。
我建議在 x86 中這樣做的方法是使用 lib-call 自定義呼叫約定，該約定要求將相應的 lib-base 傳遞給 %EBX 中的函式，然後使用用於傳遞引數的任何其他暫存器使用固定偏移量索引到基索引中的跳轉表。這樣，暫存器分配器將自動處理 %EBX 的暫存器溢位，以便如果暫存器分配器可以分配一個暫存器來做到這一點，則可以將 %EBX 的先前值傳遞給另一個暫存器。
剩餘的 呼叫約定 受支援。潛在問題包括
- LLVM 中間表示支援多個返回值，這與 C 不同，C 需要對堆疊進行特殊關注
- 中斷將無法依賴 %EBX 保留用於系統使用，因為一組計算密集型的公式可能會導致暫存器分配器將 %EBX 溢位到堆疊，
並稍後檢索它
- 如果我們不允許 %EBX 溢位到堆疊，那麼我們將在 x86 後端做一些額外的工作以從暫存器選擇中保留 %EBX。
它目前在內部使用 3 種呼叫約定，並允許使用幾種系統特定的呼叫約定。
由於 %ebx 是一個堆疊指標，因此在離開函式或呼叫庫中的外部函式時，您始終必須進行恢復。在分支中，這是透過在 gcc 中新增 -ffixed-ebx 選項來為偽交叉編譯器完成的。
除了這些呼叫約定之外，還允許使用系統特定的約定。為此，我們需要一個庫呼叫約定，以便在使用之前及時載入庫的基指標。對純重入基地址相對呼叫約定也是如此。
目前 %ebx 只是一個額外的堆疊指標，它與 i386 上的正常堆疊指標方向相反。它通常用於儲存基指標。我實現了一個額外的堆疊指標，以便不必為每次函式呼叫新增基指標，也不必在呼叫庫函式的存根程式碼中處理正常的堆疊。這樣，您可以在庫中函式的存根程式碼上將該堆疊中的基指標壓入，而無需函式的原始碼以特殊的 AROS_LH 宏開頭。我將此用於調整後的 arosc.library，以便它不再需要 ETask。
另外，我需要知道這將如何影響 AROS 的 x86_64 版本。AMD64 ( ;) ) ABI 還需要討論，但是是否有理由不遵循 i386 並以相同的方式使用 %ebx ？我對 AMD64 彙編不太熟悉。
看起來 有人 在捷克斯洛伐克開始了 M68K LLVM 移植工作。看看您是否可以將他們的 LLVM 程式碼更改提供給我？我希望支援 LLVM M68K，這將使我的工作變得容易很多。 學生 Vlamir 和 教授.
我一直在想，將基於 MMU 的 32 位沙箱模式合併到 AMD64 AROS 中有多難。這似乎是 PNaCl 在其用於行動式應用程式的 Chromium 瀏覽器外掛中實現其 32 位基於 LLVM 的沙箱的方式。唯一的其他選擇是必須為每個應用程式生成 2 個位元碼，一個用於 32 位機器，另一個用於 64 位機器。我開始在 Sourceforge.net 上使用的 LLVM 包裝器目前僅適用於 32 位應用程式，而且我只測試過它從一個 x86 作業系統到另一個 x86 作業系統的轉換。