[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squirrelfish-dev
Subject:    Re: [squirrelfish] block scope work
From:       Oliver Hunt <oliver () apple ! com>
Date:       2012-03-12 19:36:08
Message-ID: A6D7845A-B972-450F-97D7-ABAB72B0E826 () apple ! com
[Download RAW message or body]


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
> squirrelfish-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev

_______________________________________________
squirrelfish-dev mailing list
squirrelfish-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/squirrelfish-dev


[prev in list] [next in list] [prev in thread] [next in thread]