機器代碼是否需要運行時環境？ MoSync SDK

Question

任何人都可以解釋MoSync的The Runtime Architecture？

VM核心不是問題所在。我認爲它是一個運行在java虛擬機中的虛擬機，並逐行解釋代碼。

但是Recompiler Core是如何工作的？這是一種在運行本機代碼時編譯應用程序的前期編譯器嗎？但後來我不明白這張照片。或者是否有可能需要運行系統的其他模塊，即使它是機器代碼？

由於

Answer 1

我剛纔看到馬蒂亞斯已經答覆，而我忘記而我的答覆，但我只是張貼也無妨，因爲它進一步闡述一些看法:)

首先，你的C/C++被編譯到MoSync IL （中級語言），使用我們自定義的GCC後端。然後，對於某些平臺（包括Android，Symbian和Windows Mobile），這個IL被送入「管道工具」，這是一個彙編器/鏈接器/優化器，可以爲不同平臺做不同的事情。這裏有幾個變種：​​對於JavaME和我們即將發佈的Blackberry輸出，管道工具生成MoSync字節碼，這是一種二進制緊湊的基於寄存器的表示形式。該字節碼與包含虛擬機的MoSync運行時一起打包。當你的應用程序啓動時，它將字節碼讀入內存並開始解釋它。

對於Android，Symbian，Windows Mobile等，過程與此類似，但運行時核心並不是解釋代碼，而是貫穿整個代碼，並將其重新編譯爲設備上的ARM機器代碼。一旦完成，就開始執行剛創建的ARM代碼。

對於iOS設備，這個故事還是有點不同 - 不是將MoSync IL轉換爲MoSync字節碼，而是將代碼轉換爲C源代碼，並創建了xcode項目。做這件事有很多原因。一種是，對於iOS來說，動態生成ARM機器碼是不可能的，我們也不允許動態加載代碼，因爲虛擬機運行是毫無意義的。此外，在法律方面，我們希望確保應用程序的生產方式完全符合Apple的規則和準則。

MoSync的主要優勢之一就是靈活性;通過使用簡化的中間表示法，即任何輸入語言最終被轉換爲以及任何平臺的結果二進制總是從中派生而來，我們獲得輸入和輸出之間的單一接觸點。這使得我們可以添加新的輸入語言，而不依賴於支持哪些平臺，相反，可以獨立於輸入語言添加對新平臺的支持。

當人們問我們「MoSync是否允許Java程序在iPhone上運行？」或者「它能讓C++程序在Windows Phone 7上運行嗎？」答案總是「是」。

如果我們添加對Java的支持作爲輸入語言，它將自動在MoSync支持的每個平臺上工作。

當我們添加對Windows Phone 7的支持時，無論使用何種輸入語言MoSync都支持該平臺。

我知道，這是很難相信，但這是事實:)

Answer 2

得到補償核心看起來像一個典型的動態重新編譯程序/ JIT編譯器，根據需要，其重新編譯的代碼。顯然，MoSync根據運行的平臺（VM核心 - > Java ME，生成的核心 - > IPhone，重新編譯核心 - >其他）使用不同的核心，與運行時系統交互作爲適用於每個核心的應用程序，儘管應該對MoSync的用戶來說大多是透明的。

Answer 3

Recompiler Core是基本核心+ AOT編譯器，其中基本核心是MoSync系統調用的實現。應用程序第一次啓動時，AOT編譯器通過MoSync字節代碼並將其轉換爲本地代碼，例如臂。在轉換期間，所有MoSync的系統調用都直接映射到基本內核的函數。該應用程序最終通過跳轉到轉換後的代碼段的開頭來執行。

關於模塊。與相應的庫鏈接時，應用程序框架嵌入在字節碼中。系統調用和內部擴展是基本核心的一部分，它們又依賴於資源系統。

Answer 4

一個關於MoSync小知道的事實是，它不只是建有利於CPU的， 它也是好的轉換到其他例如，MoSync的其中一名工程師使用Javascript/HTML 5.0運行平臺。

取決於您使用的平臺會發生不同的事情，因此MoSync會根據最適合目標平臺的內容轉換爲中間語言。

也有4種不同口味的MoSync IL，它們全都相互兼容， ，但它們被建模爲有利於不同的處理器體系結構。

IL系統有128個寄存器，其中6個是全局的，其餘的是局部的函數。

BTW，MoSync字節碼與MoSync IL不同，IL在元數據方面非常豐富。

我很樂意討論更精細的細節或架構，只是發佈您的問題。