<br><br><div class="gmail_quote">On Wed, May 13, 2009 at 5:05 PM, Jecel Assumpcao Jr <span dir="ltr">&lt;<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Eliot,<br>
<br>
&gt; [JIT code uses call which pushes PC first]<br>
<br>
Ok, so this can&#39;t be helped.<br>
<div class="im"><br>
&gt; So while one could I don&#39;t see that its worth-while.  Even if one did<br>
&gt; keep the arguments and temporaries together one would still have the<br>
&gt; stack contents separate from the arguments and temporaries and<br>
&gt; temporary access bytecodes can still access those so arguably one<br>
&gt; would still have to check the index against the temp count.<br>
<br>
</div>Really? I wouldn&#39;t expect the compiler to ever generate such bytecodes<br>
and so wasn&#39;t too worried if the VM did the wrong thing in this<br>
situation.</blockquote><div><br></div><div>There&#39;s a tension between implementing what the current compiler produces and implementing what the instruction set defines.  For example should one assume arguments are never written to?  I lean on the side of implementing the instruction set.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">&gt; In the JIT the flag is a bit in the method reference&#39;s LSBs and is set for free<br>

&gt; on frame build.<br>
<br>
</div>That sounds like a neat trick. Are the stack formats for the interpreted<br>
stack vm and the jit a little diffeent?</blockquote><div><br></div><div>Yes.  In the JIT an interpreted frame needs an extra field to hold the saved bytecode instruction pointer when an interpreted frame calls a machine code frame because the return address is the &quot;return to interpreter trampoline&quot; pc.  There is no flag word in a machine code frame.  So machine code frames save one word w.r.t. the stack vm and interpreted frames gain a word.  But most frames are machine code ones so most of the time one is saving space.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thanks for the explanations. I haven&#39;t figured out how to do this in<br>
hardware in a reasonable way and so might have to go with a different design.</blockquote><div><br></div><div>I guess that in hardware you can create an instruction that will load a descriptor register as part of the return sequence in parallel with restoring the frame pointer and method so one would never indirect through the frame pointer to fetch the flags word; instead it would be part of the register state.  But that&#39;s an extremely uneducated guess :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<font color="#888888"><br>
-- Jecel<br>
<br>
</font></blockquote></div><br>