選擇中間語言

我目前正在使用編程語言。我花了一些時間用高級語言編寫解析器和解釋器（最顯着的是haXe）。選擇中間語言

我有一些結果，我認爲其實很不錯，但現在我想讓它們變快。

我的想法是將輸入語言翻譯成C.
我的C知識僅限於您在大學學習的內容。除了一些練習之外，我從來沒有寫過實際的C程序。但我確信我可以讓它工作。

當然，我可以嘗試編寫LLVM的前端或生成MSIL或JVM字節碼。但我覺得現在學得太多了，實際上我並沒有看到太大的收穫。
另外C是完全人類可讀的，所以如果我搞砸了，理解原因就容易多了。畢竟，C是高層次的。我真的可以從輸入語言中翻譯出概念，而不需要太多的介意。我應該在合理的時間內完成並運行一些東西，然後按照我認爲合適的方式進行優化。

所以：使用C有什麼缺點嗎？你能推薦一個替代品嗎？
感謝您的見解:)

編輯：一些澄清

爲什麼我想就是一路走下來，那我寫與OOP支持的語言的原因我想實際實現我手動調度的方法，因爲我有一些非常具體的想法。
一個主要的使用領域是編寫HTTP服務，但我可以將圖像添加到GUI庫（wxWidgets也許）或任何其他。

來源

2011-06-14 back2dos

這是什麼問題？ – unwind 2011-06-14 16:27:53

@unwind：剛剛編輯。 – back2dos 2011-06-14 16:28:23

我能想到的大多數編譯器在本地轉到C之前需要一箇中間步驟，所以，我認爲C是一個很好的選擇，尤其是因爲這會自動爲您提供大量的可移植性。如果你的語言是面向對象的，你可能有更好的時間轉換爲C++或Objective-C;同樣，如果它是功能性的，你可能有更好的時間轉換成Haskell。 – 2011-06-14 17:05:18

C對於一個小型或實驗性編譯器的目標語言來說實際上是一個相當不錯的選擇 - 它在許多平臺上廣泛使用，因此您的編譯器會在許多環境中立即使用。主要的缺點是處理在C中不被很好支持的東西，或者在C規範中沒有很好的定義。例如，如果你想做動態代碼生成（JIT編譯），C是有問題的。像堆棧展開和反射這樣的事情在C中是很棘手的（儘管setjmp/longjmp和仔細使用爲其生成佈局描述的結構可以做很多事情）。諸如字號，大小或小端佈局以及算術精度等因素在C編譯器中各不相同，因此您必須意識到這一點，但如果您想要支持多個目標機器，則需要處理這些問題。

其他語言也可以使用 - C的主要優點是它的普遍性。

來源

2011-06-14 17:54:56

無論語言如何，Big/Little Endian都會成爲問題。當然，水平太高的語言甚至不能在字節級別執行任何操作，所以不會遇到任何endian問題，因爲他們甚至不支持它們。 – Lundin 2011-06-14 18:04:24

對於你想要做的事情，C是一個很好的選擇。

不過，看看LLVM的中間語言（IR）。它非常易讀，我認爲它比C更容易生成和解析。LLVM帶有相當多的工具集合來處理它。您可以爲各種平臺生成本機代碼（與C一樣，但對輸出的控制稍微多一點）或虛擬機。 JIT編譯的可能性也是一個優點。

請參閱The Architecture of Open Source Applications, Chapter 11介紹LLVM方法和一些IR的片段。

你的目標環境是什麼？這可能會幫助我們給你更好的答案。

來源

2011-06-14 18:04:59

+1：LLVM IR是專門爲此設計的。 – rubenvb 2011-06-15 17:45:00

@rubenvb：是的。這就是爲什麼即使最終不會使用它也值得一看。您可能無法直接使用它（例如，LLVM是C++，因此在某些環境中可能很難使用它）。或者它可能會激勵你做一些與你的初始計劃完全相反的事情：使用某些現有（和流行）語言的LLVM前端，併爲你的應用程序提供你自己定製的後端或虛擬機。 – 2011-06-17 07:40:11

你可能會考慮C--，擬以代碼生成一個更好的目標不是C.

來源

2011-06-14 21:49:13

謝謝，這聽起來很有趣;） – back2dos 2011-06-14 21:59:32

下的類C語言是個不錯的選擇，恕我直言。與許多語言不同，C通常被認爲是「優雅」的，因爲只有32個關鍵字和非常基本的構造（序列，選擇，迭代），並且具有非常簡單和一致的令牌和運算符集合。因爲語法在C中是非常一致的（括號和大括號，塊和語句，表達式的使用），所以你並沒有進入無限制的語言擴展世界。 C是一種成熟的語言，很好地適應了時間，現在一天是一個「已知量」（很多其他語言甚至是「成熟」的語言都很難說）。

來源

2011-06-15 17:32:47 charley

選擇中間語言

回答

相關問題