On 2015/09/07 09:16:46, rmcilroy wrote:
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).

So we talked about this for quite some time today, and the problem we see
with this is that there's no real use of CallVarArgs outside the interpreter.
So we have to support this in TurboFan (which might become more serious
as TurboFan matures) even tho this could be implemented with a few lines
of hand-written native code (basically the PushMultiple plus a Call to the
builtin).

And especially, since you might want to avoid leaving and reentering the
interpreter on calls between bytecode functions, you'll probably need to
do some frame magic in the Call bytecode handler anyway (which TF cannot
support in general). So my feeling here that this is trying to crack a walnut with a sledgehammer. But I that is just my feeling; I don't want to block the
interpreter, which means this is not a N-O-T L-G-T-M from me.

https://codereview.chromium.org/1323463005/

--
--
v8-dev mailing list
v8-dev@googlegroups.com
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 v8-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to