On Fri, Jan 31, 2014 at 5:56 AM, Charles Oliver Nutter
<[email protected]>wrote:
> Ok, so I got frame push/pop working and wanted to move on to binding.
> I was under the impression that push/pop binding was basically for
> pushing/popping a DynamicScope, but it seems like it's more than that.
>
> For the following code: def foo; a = 1; eval 'p a'; end
>
> We get these linearized instructions:
>
> Linearized instructions for JIT:
>
> 0 push_frame
> 1 push_binding(INSTANCE_METHOD foo[-e:0])
> 2 check_arity(0, 0, -1)
> 3 %t_%block_1 = recv_closure
>
This is only used to receive "&blk" arg which is a Proc and hence an
IRubyObject.
I was baffled for a bit as well how the Interpreter works on this and
realized what was going on when I looked at how this instr. is interpreted.
I think the name of the instruction is confusing. Maybe we should change it
to receive_proc or something else to indicate this?
However, I forget the reasoning why I always add it to the arg-receive
protocol. I'll have to dig into IRBuilder or look into it later.
Subbu.
> 4 thread_poll
> 5 line_num(0)
> 6 %t_a_2 = Fixnum:1
> 7 store_lvar(%t_a_2, foo, a(0:1))
> 8 store_lvar(%t_%block_1, foo, %block(0:0))
> 9 %v_0 = call_1o(FUNCTIONAL, 'eval', %self, ["p a"]){1O}
> 10 pop_binding
> 11 pop_frame
> 12 return(%v_0)
> 13 %v_3 = recv_jruby_exc
> 14 pop_binding
> 15 pop_frame
> 16 throw(%v_3)
>
> Note that there's a store_lvar for the temporary "a" variable into the
> heap "a" variable, but there's also a store for the temporary "%block"
> variable. If I represent binding as DynamicScope, this isn't
> supportable; the scope entries only support IRubyObject.
>
> In the current runtime, the binding's block lives on the frame, not on
> the scope.
>
> I think this is a problem with the explicit heap load/store
> instructions. The block will already have been saved to the frame in
> pushFrame, and eval will great a binding on demand using frame +
> scope. So if push/pop binding just manipulate scope and block is not
> part of the explicit stores, I think this will work.
>
> Looking into it now, but I welcome comments.
>
> - Charlie
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
