[Webkit-unassigned] [Bug 148373] Create WebAssembly functions

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Aug 26 20:02:15 PDT 2015


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

--- Comment #7 from Sukolsak Sakshuwong <sukolsak at gmail.com> ---
Thanks for the review.

(In reply to comment #2)
> Comment on attachment 259748 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=259748&action=review
> 
> > Source/JavaScriptCore/bytecode/UnlinkedFunctionExecutable.cpp:68
> > +        Vector<UnlinkedInstruction, 0, UnsafeVectorOverflow> instructions;
> > +        instructions.append(op_enter);
> > +        result->setInstructions(std::make_unique<UnlinkedInstructionStream>(instructions));
> 
> This seems wrong. What does op_enter mean in the web assembly context? What
> does it mean to have bytecode at all, when we don't have web assembly
> bytecodes?

It is a hacky way to circumvent assertions that assert that instructions.size() > 0. Those assertions shouldn't have been called in the first place. I have removed it.

(In reply to comment #3)
> Comment on attachment 259748 [details]
> Patch
> 
> I think WASMExecutable should be a subclass of ExecutableBase, just like
> NativeExecutable. JSFunction already knows, a little bit, how to multiplex
> between JavaScript code and foreign code at the executable level, so this
> should be a natural fit.

Done. I create WebAssemblyExecutable as a subclass of ExecutableBase.

(In reply to comment #4)
> Also, there's no need for an unlinked WASM executable. We use unlinked for
> caching the result of parsing, but WASM is already in that short-hand
> format, and not in a text format.

Done.

-- 
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/20150827/0ec9c39a/attachment-0001.html>


More information about the webkit-unassigned mailing list