We should really have this discussion outside this CL. 1. For non tagged template literals, we should do the desugaring in the parser. That way we need no code gen for it.
2. Is complicated because the CallSite object has to be the same every time the template literal is executed. http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-gettemplatecallsite The spec is under specified here. On Tue, Oct 28, 2014 at 9:26 PM, <[email protected]> wrote: > On 2014/10/28 14:25:14, Dmitry Lomov (chromium) wrote: > >> Before this CL can land, I think we need a clear design for >> implementation of >> this feature. >> > > In particular: >> 1. What the code generation would look like, on a high level? >> 2. How will we cache template call sites? >> > > It is my guess that after we figure out 1 and 2, we will realize that we >> do >> > not > >> actually need new AST nodes for template strings and we will be able to >> > desugar > >> at parse time into Javascript and some runtime calls, but I might be >> mistaken. >> > > So, there are two codegen paths that matter here, I think: > > 1) No tag: > 1. Assert that cookedStrings.length === expressions.length + 1 > 2. If 0 expressions: plug the cooked string (TV) -> like string literal, > break. > 3. setup scratch variable which contains a JSArray > 4. Push cookedStrings(0) to scratch variable > 5. For each index 0..N expression: > a. VisitForAccumulatorValue(expression i) > b. Push accumulator value to scratch variable > d. Push cookedStrings(++i) to scratch variable > 6. __ Push(scratchVariable) > 7. __ CallBuiltin(STRING_CONCAT, CALL_FUNCTION) > 8. Plug result of STRING_CONCAT > > The STRING_CONCAT builtin will receive a JSArray of cooked strings > interleaved > with expression values, and return the result of > `String.prototype.concat.apply('', interleavedElements)` > > --- This works nicely, but I can't figure out how to set up a scratch > variable > with no binding, so that it doesn't leak into the programme. > > 2) With tag: > More complicated: Assert that cookedStrings.length == rawStrings.length, > assert that cookedStrings.length == expressions.length + 1 > Setup 3 scratch variables, all JSArrays > Push each cookedString into first scratch variable > Push each rawString into second scratchVariable > For each expression, VisitForAccumulatorValue() and push result into > third > scratch variable > __ Push(tagFn) > __ Push(scratchCookedStrings) > __ Push(scratchRawStrings) > __ Push(scratchExpressionValues) > __ CallBuiltin(CALL_TAGGED_TEMPLATE, CALL_FUNCTION) > Plug result of that builtin call > > The builtin will A) call GetTemplateCallSite() with the first 2 scratch > variables, and B) apply tagFn with [callSite, ...scratchExpressionValues]. > The callsite will be attached to the ASTNode so that it need not be > re-created > again. (steps 1 and 12 in GetTemplateCallSite()) > > --- > > So the challenge (for me) is figuring out how to setup each scratch > variable in > a way that doesn't leak into the programme or clobber any > current accumulator value. I haven't figured out how to set up scratch > variables > of a specific type, but they really need to be arrays, I think. > > So, someone who knows the codegen side more than me could help figure out > a way > to make those algorithms a reality, or else help figure out a more > efficient > algorithm, if one exists. > > https://codereview.chromium.org/663683006/ > -- erik -- -- 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.
