[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