In today's meeting, Marc suggested that we should put pointers to objects that are needed by the runtime inside the context object. It seemed like a rational thing to do.
There is one thing I'm not clear about, however: how will the context register be switched when non-tachyon code calls tachyon code and vice versa? How can this be implemented efficiently? Does the caller always have to check if the callee belongs to the same context? Where is the new context register value read?
Marc, you argued that using a context register is faster than directly embedding pointers in the machine code. I'm wondering if it wouldn't be a better performance choice to do the latter, however, if it could eliminate the need to always maintain a context register live and handle context register switches.
- Maxime
On 10-09-02 03:23 PM, chevalma@iro.umontreal.ca wrote:
Marc, do you have any time to fix the parser issues we discussed before leaving? There are a few things I'd like to fix in the IR conversion that I'd can't really do until those fixes are applied.
Things to fix:
- Identifier/variable objects not the same (not ===) for function
parameters vs locals that are parameters
- Scope of var declarations inside catch not matching JS semantics
- Function declarations inside catch resolve their variable to the outer
containing function, not the catch scope (but function expressions behave as you would expect)
- arguments variable should not appear free, should be a local
Feature requests:
- function/program prologue annotations extraction, functions should have
a field that is a list of all prologue annotation strings
- when eval appears free in a function or a sub-function, make all
variables "escaping" all the way to the function containing the eval, to signal that they could all be captured by a closure corresponding to eval code
- Maxime
Tachyon-list mailing list Tachyon-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/tachyon-list