Portability Guidelines 可移植性准则
Emscripten can be used to compile almost any portable C++/C code to JavaScript.
Emscripten可用于将几乎所有可移植的C++/C代码编译为JavaScript。
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.
本节说明哪些类型的代码不可移植（或更难于移植），哪些代码可以编译但运行缓慢。开发人员可以使用此信息来评估移植和重写代码的工作量。
Current Web limitations 当前的网站限制
-
Multithreading depends on SharedArrayBuffer, which is still being standardized and implemented by browsers. Emscripten has working support for threads, which you can try in development browsers by setting the proper preference. 多线程依赖于SharedArrayBuffer，它仍在标准化中并且由浏览器厂商逐步实现。Emscripten对线程具有有效的支持，您可以通过设置适当的首选项在开发浏览器中尝试使用。
-
SIMD is also in the process of standardization and implementation.SIMD（Single Instruction Multiple Data,单指令多数据流）也在标准化和实施过程中。
Code that cannot be compiled 无法编译的代码
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.)
为了可以使用Emscripten进行编译，需要重写以下类型的代码。（虽然从理论上讲Emscripten或许可以通过仿真解决这些问题，但速度非常慢。）
-
Code relying on a big-endian architecture. Emscripten-compiled code currently requires a little-endian host to run on, which accounts for 99% of machines connected to the internet. This is because JavaScript typed arrays (used for views on memory) obey the host byte ordering and LLVM needs to know which endianness to target. 代码依赖高字节序架构。当前使用Emscripten编译代码需要运行一个低字节序的主机，该类型主机占连接到Internet的计算机的99％。这是因为JavaScript类型的数组（用于内存视图）遵循主机字节顺序，并且LLVM需要知道要定位的字节序。
-
Code that uses low-level features of the native environment, for example native stack manipulation in conjunction with
setjmp/longjmp(we support proper setjmp/longjmp, i.e., jumping down the stack, but not jumping up to an unwound stack, which is undefined behavior).使用原生环境低层级实现的代码，例如与setjmp/longjmp结合使用本机堆栈的操作longjmp（我们支持适当的setjmp/ longjmp，即向下跳转堆栈，但不能向上跳转至未包裹的堆栈，这是没有定义的行为）。 -
Code that scans registers or the stack. This won’t work because a variable in a register or on the stack may be held in a JavaScript local variable (which cannot be scanned).扫描寄存器或堆栈的代码。这将不起作用，因为寄存器中或堆栈上的变量可能保存在JavaScript局部变量中（无法扫描）。
Note: 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. Other solutions include the SpillPointers pass in Binaryen.注意：此类代码可用于保守的垃圾回收。当堆栈上没有其他代码时，例如从主事件循环的迭代中，您可以进行保守扫描。其他解决方案包括Binaryen中的SpillPointers传递。
- 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.针对特定体系结构的内联汇编代码（如包含x86代码的asm()代码）不可移植。该代码需要用可移植的C或C++替换。有时，代码库会同时具有可移植代码和可选的内联汇编作为优化，因此您可能会找到一个禁用内联汇编的选项。
Code that compiles but might run slowly 可以编译但运行缓慢的代码
Note: Understanding these issues can be helpful when optimising code.注意：在优化代码时，了解这些问题可能会有所帮助。
The following types of code will compile, but may not run as fast as expected:以下类型的代码将编译，但运行速度可能不及预期：
-
In asm.js (but not WebAssembly), 64-bit int variables. Mathematical operations (+, -, , /) are slow because they are emulated (bitwise operations are reasonably fast). JavaScript does not have a native 64-bit int type so this is unavoidable.在asm.js（而非WebAssembly）中，64位的int变量。数学运算（+，-，，/）比较慢，因为它们是被模拟的（按位运算相当快）。JavaScript没有原生64位int类型，因此这是不可避免的。
-
C++ Exceptions. In JavaScript such code generally makes the JavaScript engine turn off various optimizations. For that reason exceptions are turned off by default in -O1 and above. To re-enable them, run emcc with -s DISABLE_EXCEPTION_CATCHING=0 (see src/settings.js).C++异常。在JavaScript中，此类代码通常会使JavaScript引擎关闭各种优化。因此，默认情况下，异常是关闭的-O1。要重新启用它们，请运行emcc-s DISABLE_EXCEPTION_CATCHING=0（请参阅src/settings.js）
-
setjmp also prevents relooping around it, forcing us to emulate control flow using a less efficient approach.setjmp还会阻止围绕自身重新循环，从而迫使我们使用效率较低的方法来模拟控制流。
Other issues 其他问题
- 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 (32-bit ARM will raise SIGILL). For asm.js loads and stores are forced to aligned offsets; for WebAssembly unaligned loads and stores will work but may be slow depending on the underlying CPU. If you build your code with SAFE_HEAP=1 then you will get a clear runtime exception, see Debugging.依赖x86对齐行为的代码。x86允许不对齐的读取和写入（例如，您可以从非偶数地址读取16位值），但其他架构则不允许（32位ARM会引发SIGILL）。对于asm.js，加载和存储被强制对齐偏移量；对于WebAssembly，可以使用未对齐的加载和存储，但可能会很慢，具体取决于基础CPU。如果使用构建代码，SAFE_HEAP=1则将获得明确的运行时异常，请参见调试。