<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:saambarati1@gmail.com" title="Saam Barati <saambarati1@gmail.com>"> <span class="fn">Saam Barati</span></a>
</span> changed
<a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - Implement WebAssembly module parser"
href="https://bugs.webkit.org/show_bug.cgi?id=147293">bug 147293</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">CC</td>
<td>
</td>
<td>saambarati1@gmail.com
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - Implement WebAssembly module parser"
href="https://bugs.webkit.org/show_bug.cgi?id=147293#c30">Comment # 30</a>
on <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED - Implement WebAssembly module parser"
href="https://bugs.webkit.org/show_bug.cgi?id=147293">bug 147293</a>
from <span class="vcard"><a class="email" href="mailto:saambarati1@gmail.com" title="Saam Barati <saambarati1@gmail.com>"> <span class="fn">Saam Barati</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=147293#c29">comment #29</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=147293#c28">comment #28</a>)
> > Comment on <span class=""><a href="attachment.cgi?id=257894&action=diff" name="attach_257894" title="Patch">attachment 257894</a> <a href="attachment.cgi?id=257894&action=edit" title="Patch">[details]</a></span>
> > Patch
> >
> > View in context:
> > <a href="https://bugs.webkit.org/attachment.cgi?id=257894&action=review">https://bugs.webkit.org/attachment.cgi?id=257894&action=review</a>
> >
> > > 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.</span >
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.
<span class="quote">>
> > 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
> <<a href="https://github.com/WebAssembly/polyfill-prototype-1">https://github.com/WebAssembly/polyfill-prototype-1</a>>, which uses the little
> endian format.</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>