On 2015/09/07 05:14:30, Benedikt Meurer wrote:
Just two very early comments, and one question:
You mentioned that it should be possible to write certain bytecode
handlers as
native builtins. How about doing that for the call opcode? Because that
seems
like a lot of machinery in TurboFan to support this very special opcode.
[Answering question first, I'll fix the other issues once this is decided]
A lot of the machinery comes from the fact that I made this a separate
CallVarArgs ircode as we dicussed offline on Friday to keep things
seperatable.
I could reduce this machinery a lot by just relying on the kHasVarArgs in
CallDescriptor and augmenting the Call instruction to support this. Would
this
ease your concerns?
What I mentioned originally was being able to write certain (complex)
bytecode
handlers in JS instead of raw-assembly - this wouldn't apply in this case.
It
might be possible to do in native builtins, but I think making a completely
new
bytecode handler code generation path just for this (fairly fundamental)
bytecode would add even more machinery (although admittedly not in TF).
https://codereview.chromium.org/1323463005/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
