diff options
| author | Alon Zakai <alonzakai@gmail.com> | 2011-07-09 18:32:42 -0700 |
|---|---|---|
| committer | Alon Zakai <alonzakai@gmail.com> | 2011-07-09 18:32:42 -0700 |
| commit | 3a935225b9d71148529b6564bfeac20ea49ccb7d (patch) | |
| tree | 9da91ef2a29e59e7bab1e7ac123d9ce3b907005e /docs | |
| parent | aae957a512d2760fe17df85e02d688b69e3ea564 (diff) | |
paper 1.1
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/paper.pdf | bin | 204696 -> 220464 bytes | |||
| -rw-r--r-- | docs/paper.tex | 21 |
2 files changed, 18 insertions, 3 deletions
diff --git a/docs/paper.pdf b/docs/paper.pdf Binary files differindex 9cc9f207..755eaddc 100644 --- a/docs/paper.pdf +++ b/docs/paper.pdf diff --git a/docs/paper.tex b/docs/paper.tex index 4aba3e5f..5687788f 100644 --- a/docs/paper.tex +++ b/docs/paper.tex @@ -499,9 +499,24 @@ more challenging. For example, if we want to convert exact same behavior, in particular, we must handle overflows properly, which would not be the case if we just implement this as $\%1 + \%2$ in JavaScript. For example, with inputs of $255$ and $1$, the correct output is 0, but simple addition in JavaScript will give us 256. We -can emulate the proper behavior by adding additional code, one way -(not necessarily the most optimal) would be to check for overflows after -each addition, and correct them as necessary. This however significantly degrades performance. +can of course emulate the proper behavior by adding additional code. +This however significantly degrades performance, +because modern JavaScript engines can often translate something like $z = x + y$ into +native code containing a single instruction (or very close to that), but if instead we had +something like $z = (x + y)\&255$ (in order to correct overflows), the JavaScript engine +would need to generate additional code to perform the AND operation.\footnote{ +In theory, the JavaScript engine could determine that we are implicitly working +on 8-bit values here, and generate machine code that no longer needs the AND operation. +However, most or all modern JavaScript engines have just two internal numeric types, doubles and +32-bit integers. This is so because they are tuned for `normal' JavaScript code +on the web, which in most cases is served well by just those two types. + +In addition, even if JavaScript engines did analyze code containing $\&255$, etc., +in order to deduce that a variable can be implemented +as an 8-bit integer, there is a cost to including all the necessary $\&255$ text +in the script, because code size is a significant factor on the web. Adding even +a few characters for every single mathematic operation, in a large JavaScript file, +could add up to a significant increase in download size.} Emscripten's approach to this problem is to allow the generation of both accurate code, that is identical in behavior to LLVM assembly, and inaccurate code which is |