New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial data and endiannes #786
Comments
WebAssembly is little-endian. It appears AstSemantics.md doesn't mention this; I've now filed #787 to correct this. It is mentioned here and here and tested for here. The idea of having LEB128-encoded data in the data section is interesting. There are a variety of ways this could be done, either with a new kind of data initializer, or with layer 1 compression. Layer 2 compression may help with large data segments in general as well. |
I see, thank you. Isn't is a too strong requirement? There's no any CPU I know that uses big-endian, but if for some reason one appears and become widely used, WebAssembly would execute on this CPU with some overhead. |
There are significant advantages of not having to deal with multiple endiannesses across the ecosystem, and the probability of a CPU architecture that doesn't at least have efficient support for little-endian accesses becoming popular in the foreseeable future is believed to be very low. |
On Sat, Sep 3, 2016 at 4:07 PM, Alexey Andreev notifications@github.com
We've implemented big-endian support in V8 via explicit endianness-swapping
|
This is already doable in WebAssembly exactly the same way it's done in C and C++: before main() is called the _start function can call .init_array functions. I don't think there's anything to do here. Agreed with @sunfishcode / @titzer on endianness. |
I believe this is resolved. |
Specification says nothing about which byte order
i32.load
uses. Real-world programs contain data section to provide virtual tables, static data, etc. These things usually require different value types. However, WebAssembly is limited to sequences of bytes in itsdata
section. With bytes one can't emulate int32, since they don't know anything about endiannes.It would be nice if WebAssebmly had something similar to structures and structure initializers similar to LLVM. It not only solves problem with endiannes of static data, but also gives opportunity to decrease binary data, since integers in data section which will likely consume less bytes in LEB128 representation, whereas they always consume 4 bytes when encoded in data section.
Current workarounds are:
start
functionThe text was updated successfully, but these errors were encountered: