On Mar 12, 2012, at 3:39 AM, Andy Wingo wrote: > Hi Oliver, > > On Fri, 2012-03-09 at 10:29 -0800, Oliver Hunt wrote: >>> On Thu, 2012-02-09 at 17:49 +0100, Andy Wingo wrote: >>>> The block [of registers] reserved >>>> for block scopes will have as many registers as the maximum of (number >>>> of block scope-bound variables + block scope depth). >> >> I don't understand why two passes are necessary. > > Consider you're in scope A. You see some block-scoped variables. Then > you see a nested scope B. You go in to visit it, and once you're done > visiting it you can know how many block-scoped variables there were in > B. However after visiting it there can be more variables in A. That's > why a simple high-water-mark algorithm is inappropriate.
I still don't follow -- block scoped variables are unaffected by traditional vars, and vice-versa, so counting should be sufficient. > > Either you do more work when leaving statements to track the > block-scoped variables, or you do a separate pass -- seems to me, > anyway. It's always preferable to do it while generating the AST -- having an additional AST walk is a lot of expense > >> Why do you want to know the number of block scoped variables ahead of >> codegen time? > > When you compile a function, currently you know how many registers there > will be for the variables, because they are all hoisted and known at > parse-time. Consequently, you know where (at what index) you can start > allocating temporaries. You'd like to know the same thing for > block-scoped variables so that you can allocate them next to the > function-scoped variables. A block scoped variable can only be introduced at the statement level, so there won't be any live temporaries. > >> As for code size, i wouldn't be too worried unless it's a huge size >> increase: the parser+lexer are both so heavily templated that some (large) >> functions are generated like 8 times, some maybe more... > > OK. > > I know this has dragged on a long time, but maybe this is the week for > things to come together on my side. Thanks for your patience. > > Andy > _______________________________________________ > squirrelfish-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev _______________________________________________ squirrelfish-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev
