规范没有说明i32.load使用哪种字节顺序。 现实世界的程序包含数据部分，用于提供虚拟表、静态数据等。这些东西通常需要不同的值类型。 但是，WebAssembly 仅限于其data部分中的字节序列。 使用字节无法模拟 int32，因为他们对字节序一无所知。
如果 WebAssebmly 有类似于 LLVM 的结构和结构初始值设定项，那就太好了。 它不仅解决了静态数据的字节序问题，而且还提供了减少二进制数据的机会，因为数据部分中的整数在 LEB128 表示中可能消耗更少的字节，而在数据部分编码时它们总是消耗 4 个字节。
目前的解决方法是：
- 不要使用数据部分，而是使用大型初始化函数
- 发明自己的格式，将解码器包含到 WebAssembly 二进制文件中，从
start函数运行它
konsoletyper
所有6条评论
WebAssembly 是小端的。 似乎 AstSemantics.md 没有提到这一点； 我现在已经提交https://github.com/WebAssembly/design/pull/787来纠正这个问题。
在数据部分包含 LEB128 编码数据的想法很有趣。 有多种方法可以做到这一点，或者使用一种新的数据初始化器，或者使用第 1 层压缩。 一般而言，第 2 层压缩也可能有助于处理大数据段。
sunfishcode
于 2016-09-03
明白了，谢谢是不是要求太强了？ 我知道没有任何 CPU 使用 big-endian，但如果由于某种原因出现并被广泛使用，WebAssembly 将在此 CPU 上执行，但会产生一些开销。
konsoletyper
于 2016-09-03
不必处理整个生态系统中的多个字节序具有显着的优势，并且在可预见的未来，至少没有有效支持小字节序访问的 CPU 架构变得流行的可能性非常低。
sunfishcode
于 2016-09-05
2016 年 9 月 3 日星期六下午 4:07，Alexey Andreev通知@ github.com
写道：
明白了，谢谢是不是要求太强了？ 没有任何 CPU 我
知道使用 big-endian，但如果由于某种原因出现并变成
广泛使用，WebAssembly 会在这个 CPU 上执行，但会有一些开销。MIPS 和 SPARC CPU 是 big-endian，虽然 SPARC 有 little-endian
加载/存储已经有一段时间了，而 MIPS 有小端变体。
我们已经通过显式的字节序交换在 V8 中实现了大字节序支持
代码，但还没有仔细测量开销。
—
您收到此消息是因为您订阅了此线程。
直接回复本邮件，在GitHub上查看
https://github.com/WebAssembly/design/issues/786#issuecomment -244548450，
或静音线程
https://github.com/notifications/unsubscribe-auth/ALnq1EEkfh88rAXYByuL9uNcjbsjVnFbks5qmX8agaJpZM4J0Snh
.
titzer
于 2016-09-05
如果 WebAssebmly 有类似于 LLVM 的结构和结构初始值设定项，那就太好了。
这已经可以在 WebAssembly 中以完全相同的方式在 C 和 C++ 中完成：在调用 main() 之前 _start 函数可以调用 .init_array 函数。 我不认为这里有什么可做的。
同意@sunfishcode / @titzer关于字节序。
jfbastien
于 2016-09-06
我相信这已经解决了。
jfbastien
于 2016-12-16
相关问题
mfateev
·
5评论
badumt55
·
8评论
Thaina
·
8评论
dpw
·
3评论
frehberg
·
6评论
最有用的评论
不必处理整个生态系统中的多个字节序具有显着的优势，并且在可预见的未来，至少没有有效支持小字节序访问的 CPU 架构变得流行的可能性非常低。