[Webkit-unassigned] [Bug 147293] Implement WebAssembly module parser

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=147293

Saam Barati <saambarati1 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |saambarati1 at gmail.com

--- Comment #30 from Saam Barati <saambarati1 at gmail.com> ---
(In reply to comment #29)
> (In reply to comment #28)
> > Comment on attachment 257894 [details]
> > Patch
> > 
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=257894&action=review
> > 
> > > Source/JavaScriptCore/wasm/WASMReader.cpp:38
> > > +    result = m_cursor[0] | m_cursor[1] << 8 | m_cursor[2] << 16 | m_cursor[3] << 24;
> > 
> > Out of curiosity, why does byte order not matter here but matter below?
> 
> Because the shift operator takes care of that. Say, m_cursor[0] = A,
> m_cursor[1] = B, m_cursor[2] = C, and m_cursor[3] = D.
> 
> On a little-endian machine,
> A       = A 0 0 0
> B << 8  = 0 B 0 0
> C << 16 = 0 0 C 0
> D << 24 = 0 0 0 D
> result  = A B C D
> 
> On a big-endian machine,
> A       = 0 0 0 A
> B << 8  = 0 0 B 0
> C << 16 = 0 C 0 0
> D << 24 = D 0 0 0
> result  = D C B A
> 
> which is as it should be.
Makes sense. This is a cool illustration.
It's a little worrisome that this is wrong though
if it's decided that WASM binary format is big endian.
I'm not sure there is an alternative, though. 

> 
> > Also, does WASM follow network byte order?
> 
> The binary format hasn't been standardized yet. We are using the file format
> of an experimental WebAssembly polyfill
> <https://github.com/WebAssembly/polyfill-prototype-1>, which uses the little
> endian format.
Do we think it is likely that WASM binary format will stay
little endian? Would a lot of parsing code have to change if it's
big endian? It seems like it wouldn't be a lot but I haven't read
all the WASM code you've been working on.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150731/e884c0fd/attachment.html>