Ok. Doing the whole handler as native code would add a whole lot more
complexity
(e.g., ensuring that interpreter are saved and restored properly). Instead,
I've
written a small builtin called PushArgsAndCall which does the pushing and
then
directly calls builtin::Call. This avoids the need for CallVarArgs. How's
this?
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).
I don't think we will want to do this - there is very little code in
builtin::EnterInterpreter which we can avoid doing even if we are already
in the
interpreter, so it probably isn't worth special casing
interpreter->interpreter
calls.
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.
I appreciate the feeling, although I wish it had been expressed when we
discussed the general approach on Friday... :).
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.
