Adding Big Endian support#12780
Adding Big Endian support#12780miladfarca wants to merge 5 commits intoemscripten-core:mainfrom miladfarca:be-support
Conversation
|
Thank you for submitting a pull request! If this is your first PR, make sure to add yourself to AUTHORS. |
src/preamble.js
Outdated
| return new DataView(target.buffer)[getter](byteCount * (key), true); | ||
| }, | ||
| set: function (target, key, value) { | ||
| new DataView(target.buffer)[setter](byteCount * (key), value, true); |
There was a problem hiding this comment.
Hmm, isn't it super-inefficient to allocate a new dataview on every single memory load and store operation?
|
Emscripten strongly follows "you don't pay for what you don't use" idiom on code size, because all added code increases network download size. In the history a lot of people have been turned off by Emscripten by considering it to be "bloated" when they build a small hello world and find there to be lots of code generated by default that they do not need. Big Endian support will definitely be one of those features. Because of that, we should not unconditionally add to the code size for all users to have to pay, but instead, this should be optional. I would recommend a (maybe could also have -s BIG_ENDIAN=2 mode, which would allow retaining the LE check even for release builds, if someone wants to carry that to production. ASSERTIONS would then imply -s BIG_ENDIAN=2 by default) Btw, if I was to add support for BE, I would not probably bother with DataView, that seems like a suboptimal solution and a large performance impact. Instead, I would recommend either to 1) add a JS macro to do heap accesses, or 2) to do an acorn-based heap access rewrite. Solution 1) would be best for performance, but may be hard to maintain. Solution 2) will be more automatic, but can be a bit brittle. We have the same challenge with multithreaded heap accesses. |
|
+1 for the acorn approach, I think that would make the most sense. See #12387 (comment) |
|
Thanks for reviewing. In terms of low level memory access in JS and Endianness we can use Performance of DataViews has been improved significantly since V8 6.9 to match (or even outperform) TypedArrays. Instead of relying on C++ runtime, V8 is using Torque/TurboFan and emits machine specific instructions: Non float types could have their bytes reversed using bit shifting, however, what would be an efficient |
|
Interesting about the performance of DataView, that's good to know, and sounds good to use. Reversing a float could use a singleton object on the side, to copy to in reverse order and then read from, perhaps. |
|
Closing this as #13413 has fixed the issues. |
3 participants
This PR modifies the getter/setters of the global HEAP objects. It adds a Proxy to the
multi bytearrays as an intercepter and forces Little Endian ordering when reading/writing to the buffer by usingData Views. We force little endian as WASM itself is LE enforced on all architectures.