This section explains what types of code are non-portable (or more difficult to port), and what code can be compiled but will run slowly. Developers can use this information for evaluating the effort to port and re-write code.
The following types of code would need to be re-written in order to work with Emscripten. (While in theory it might be possible for Emscripten to work around these issues using emulation, it would be very slow.)
Code that relies on x86 alignment behavior. x86 allows unaligned reads and writes (so for example you can read a 16-bit value from a non-even address), but other architectures do not (ARM will raise
SAFE_HEAP=1 then you will get a clear runtime exception, see Debugging.
Code that uses low-level features of the native environment, for example native stack manipulation in conjunction with
longjmp (we support proper
longjmp, i.e., jumping down the stack, but not jumping up to an unwound stack, which is undefined behavior).
Code of this type might be used for conservative garbage collection. You can do conservative scanning when there is no other code on the stack, e.g. from an iteration of the main event loop.
Code with architecture-specific inline assembly (like an
asm() containing x86 code) is not portable. That code would need to be replaced with portable C or C++. Sometimes a codebase will have both portable code and optional inline assembly as an optimization, so you might find an option to disable the inline assembly.
Understanding these issues can be helpful when optimising code.
The following types of code will compile, but may not run as fast as expected:
inttype so this is unavoidable.
-O1and above. To re-enable them, run emcc with
-s DISABLE_EXCEPTION_CATCHING=0(see src/settings.js).
setjmpalso prevents relooping around it, forcing us to emulate control flow using a less efficient approach.