diff options
Diffstat (limited to 'docs/paper.tex')
| -rw-r--r-- | docs/paper.tex | 51 |
1 files changed, 40 insertions, 11 deletions
diff --git a/docs/paper.tex b/docs/paper.tex index 453e1d66..82b99336 100644 --- a/docs/paper.tex +++ b/docs/paper.tex @@ -28,9 +28,9 @@ %\maketitle \begin{abstract} -We present Emscripten, an LLVM-to-JavaScript compiler. Emscripten compiles -LLVM (Low Level Virtual Machine) assembly code into standard JavaScript, which opens up two avenues for running code written -in languages other than JavaScript on the web: (1) Compile code directly into LLVM bitcode, and +We present Emscripten, a compiler from LLVM (Low Level Virtual Machine) assembly to JavaScript. This +opens up two avenues for running code written +in languages other than JavaScript on the web: (1) Compile code directly into LLVM assemby, and then compile that into JavaScript using Emscripten, or (2) Compile a language's entire runtime into LLVM and then JavaScript, as in the previous approach, and then use the compiled runtime to run code written in that language. For example, the @@ -107,8 +107,8 @@ not Python, so for example division of integers can yield unexpected results but in JavaScript and in Pyjamas a floating-point number can be generated). In this paper we present another project along those lines: \textbf{Emscripten}, -which compiles LLVM assembly code into JavaScript. LLVM (the Low Level Virtual -Machine\footnote{\url{http://llvm.org/}}) is a compiler project primarily focused on C, C++ and +which compiles LLVM (Low Level Virtual Machine\footnote{\url{http://llvm.org/}}) assembly into JavaScript. +LLVM is a compiler project primarily focused on C, C++ and Objective-C. It compiles those languages through a \emph{frontend} (the main ones of which are Clang and LLVM-GCC) into the LLVM intermediary representation (which can be machine-readable @@ -683,6 +683,40 @@ improve the speed as well, as are improvements to LLVM, the Closure Compiler, and JavaScript engines themselves; see further discussion in the Summary. +\subsection{Limitations} + +Emscripten's compilation approach, as has been described in this Section so far, +is to generate `natural' JavaScript, as close as possible to normal JavaScript +on the web, so that modern JavaScript engines perform well on it. In particular, +we try to generate `normal' JavaScript operations, like regular addition and +multiplication and so forth. This is a very +different approach than, say, emulating a CPU on a low level, or for the case +of LLVM, writing an LLVM bitcode interpreter in JavaScript. The latter approach +has the benefit of being able to run virtually any compiled code, at the cost +of speed, whereas Emscripten makes a tradeoff in the other direction. We will +now give a summary of some of the limitations of Emscripten's approach. + +\begin{itemize} +\item \textbf{64-bit Integers}: JavaScript numbers are all 64-bit doubles, with engines + typically implementing them as 32-bit integers where possible for speed. + A consequence of this is that it is impossible to directly implement + 64-bit integers in JavaScript, as integer values larger than 32 bits will become doubles, + with only 53 bits for the significand. Thus, when Emscripten uses normal + JavaScript addition and so forth for 64-bit integers, it runs the risk of + rounding effects. This could be solved by emulating 64-bit integers, + but it would be much slower than native code. +\item \textbf{Multithreading}: JavaScript has Web Workers, which are additional + threads (or processes) that communicate via message passing. There is no + shared state in this model, which means that it is not directly possible + to compile multithreaded code in C++ into JavaScript. A partial solution + could be to emulate threads, without Workers, by manually controlling + which blocks of code run (a variation on the switch in a loop construction + mentioned earlier) and manually switching between threads every so often. + However, in that case there would not be any utilization + of additional CPU cores, and furthermore performance would be slow due to not + using normal JavaScript loops. +\end{itemize} + \section{Emscripten's Architecture} \label{sec:emarch} @@ -997,12 +1031,7 @@ things, compile real-world C and C++ code and run that on the web. In addition, by compiling the runtimes of languages which are implemented in C and C++, we can run them on the web as well, for example Python and Lua. -Important future tasks for Emscripten are to broaden its -standard library and to support additional types of code, such as -multithreaded code (JavaScript Web Workers do not support shared state, -so this is not possible directly, but it can be emulated in various ways). - -But perhaps the largest future goal of Emscripten is to improve the performance of +Perhaps the largest future goal of Emscripten is to improve the performance of the generated code. As we have seen, speeds of around $1/10$th that of GCC are possible, which is already good enough for many purposes, but can be improved much more. The code Emscripten generates will become faster |