@@ -499,9 +499,24 @@ \subsubsection{Emulating Code Semantics}
499499exact same behavior, in particular, we must handle overflows properly, which would not be the case if we just implement
500500this as $ \% 1 + \% 2 $ in JavaScript. For example, with inputs of $ 255 $ and $ 1 $ , the
501501correct output is 0, but simple addition in JavaScript will give us 256. We
502- can emulate the proper behavior by adding additional code, one way
503- (not necessarily the most optimal) would be to check for overflows after
504- each addition, and correct them as necessary. This however significantly degrades performance.
502+ can of course emulate the proper behavior by adding additional code.
503+ This however significantly degrades performance,
504+ because modern JavaScript engines can often translate something like $ z = x + y$ into
505+ native code containing a single instruction (or very close to that), but if instead we had
506+ something like $ z = (x + y)\& 255 $ (in order to correct overflows), the JavaScript engine
507+ would need to generate additional code to perform the AND operation.\footnote {
508+ In theory, the JavaScript engine could determine that we are implicitly working
509+ on 8-bit values here, and generate machine code that no longer needs the AND operation.
510+ However, most or all modern JavaScript engines have just two internal numeric types, doubles and
511+ 32-bit integers. This is so because they are tuned for `normal' JavaScript code
512+ on the web, which in most cases is served well by just those two types.
513+
514+ In addition, even if JavaScript engines did analyze code containing $ \& 255 $ , etc.,
515+ in order to deduce that a variable can be implemented
516+ as an 8-bit integer, there is a cost to including all the necessary $ \& 255 $ text
517+ in the script, because code size is a significant factor on the web. Adding even
518+ a few characters for every single mathematic operation, in a large JavaScript file,
519+ could add up to a significant increase in download size.}
505520
506521Emscripten's approach to this problem is to allow the generation of both accurate code,
507522that is identical in behavior to LLVM assembly, and inaccurate code which is
0 commit comments