<br><br><div class="gmail_quote">On Thu, May 14, 2009 at 4:36 AM, 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>
Thanks Eliot and Igor for your comments!<br>
<br>
Eliot is right that what Igor wrote is a good way to do a JIT but the<br>
problem is that my hardware is essentially an interpreter and must deal<br>
at runtime with expressions that the JIT would optimize away.<br>
<br>
My design is described in:<br>
<br>
<a href="http://www.squeakphone.com:8203/seaside/pier/siliconsqueak/details" target="_blank">http://www.squeakphone.com:8203/seaside/pier/siliconsqueak/details</a><br>
<br>
What is missing from that description is what the control registers (x0<br>
to x31) do, and that depends on the stack organization. Certainly it is<br>
possible to have three registers as Eliot suggested. A separate control<br>
stack is not only used on Forth processors but was also popular in Lisp<br>
Machine designs.<br>
<br>
Registers t0 to t29 are really implemented through a small amount of<br>
hardware as a range of words in the stack cache. Having to split this<br>
set differently for each method would make the hardware larger and<br>
slower. With a separate control stack the mapping is really simple.<br>
<br>
About the JIT having to use call which pushes the PC, that is not true<br>
on RISC processors. But I suppose the focus for Cog is making Squeak<br>
fast on the x86.</blockquote><div><br></div><div>Right, but also for sanity the run-time support code needs to be ISA-agnostic.  So the frame organization will be unchanged between different ISAs and that means even on RISCs the return pc will be pushed; perhaps not in frameless leaf methods. but definitely in normal frames and hence it might as well be pushed in the same place, and incremented by the size of the call instruction, instead of having the return instruction add the offset at return time.</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; There&#39;s a tension between implementing what the current compiler<br>
&gt; produces and implementing what the instruction set defines.  For<br>
&gt; example should one assume arguments are never written to?  I lean<br>
&gt; on the side of implementing the instruction set.<br>
<br>
</div>That is specially a good idea if the same VM ends up being used for<br>
other languages like Newspeak. Certainly the Java VM runs many languages<br>
that the original designers never expected.</blockquote><div><br></div><div>Good point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
&gt; Yes.  In the JIT an interpreted frame needs an extra field to hold<br>
&gt; the saved bytecode instruction pointer when an interpreted frame<br>
&gt; calls a machine code frame because the return address is the &quot;return<br>
&gt; to interpreter trampoline&quot; pc.  There is no flag word in a machine<br>
&gt; code frame.  So machine code frames save one word w.r.t. the<br>
&gt; stack vm and interpreted frames gain a word.  But most frames<br>
&gt; are machine code ones so most of the time one is saving space.<br>
<br>
</div>Ok, so the JIT VM will still have an interpreter. Self originally didn&#39;t<br>
have one but most of the effort that David Ungar put into the project<br>
when it was restarted was making it more interpreter friendly. The<br>
bytecodes became very similar to the ones in Little Smalltalk, for<br>
example.</blockquote><div><br></div><div>Have you got an URL for that bytecode set?  If not, can you mail me some code or documentation that describes it?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Will images be compatible between the JIT VM and the Stack VM? Or do you<br>
expect the latter to not be used anymore once the JIT is available? I<br>
had originally understood that the Stack VM would be compatible with<br>
older images (since you divorce all frames on save and remarry them on<br>
reload) but I had missed the detail of the different bytecodes for<br>
variable instance access in the case of Context objects.</blockquote><div><br></div><div>Most of this I&#39;ve answered in a different message.  Yes, accessing Context inst vars needs special treatment.  One can add the test to all relevant inst var accesses (only inst vars 0 through 2 are affected on read and 0 through 5 on write) but that would be very slow.  Hence the recompile to use the long-form bytecodes is necessary.  This whole treatment of Context inst var access is complex but IMO it is better to hide it in the VM using the primitive and long-form IV bytecode interface than exposing the internals to the image because that makes the bootstrap process easier and makes evolving the VM easier too.</div>
<div><br></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; I guess that in hardware you can create an instruction that will<br>

&gt; load a descriptor register as part of the return sequence in parallel<br>
&gt; with restoring the frame pointer and method so one would never<br>
&gt; indirect through the frame pointer to fetch the flags word; instead<br>
&gt; it would be part of the register state.  But that&#39;s an extremely<br>
&gt; uneducated guess :)<br>
<br>
</div>Well, I am trying to avoid having a flags word even though in hardware<br>
it is so easy to have any size fields that you might want. I can check<br>
if context == nil very efficiently. For methods, t0 is the same value as<br>
the &quot;self&quot; register (x4, for example) while for blocks it is different.<br>
And with three pointers (fp, sp and control pointer) I shouldn&#39;t need to<br>
keep track of the number of arguments.<br>
<div class="im"><br>
&gt; Jecel can also design the machine to avoid taking interrupts on<br>
&gt; the operand stack and provide a separate interrupt stack.<br>
<br>
</div>Hmmm... it has been a while since I designed hardware with interrupts,<br>
but have normally used Alto style coroutines instead.</blockquote><div><br></div><div>Of course; a much better architecture!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
The stack cache is<br>
divided up into 32 word blocks and can hold parts of stacks from several<br>
threads at once. Checking for overflow/underflow only needs to happen<br>
when the stack pointer moves from one block to a different one (and even<br>
then, only in certain cases which aren&#39;t too common). An interesting<br>
feature of this scheme is that only 5 bit adders are needed (which are<br>
much faster than 16 or 32 bit adders, for example. Wide adders could<br>
reduce the clock speed or make the operation take an extra clock).<br>
Another detail is that having operand or control frames split among two<br>
stack pages is no problem at all.</blockquote><div><br></div><div>Cool :)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">address of tN in the stack cache:<br>

<br>
  raddr := fp[4:0] + N.<br>
  scaddr := (raddr[5] ? tHigh : tLow) , raddr[4:0].<br>
<br>
When fp[5] changes value, then tLow := tHigh and tHigh := head of free<br>
block list (if fp was going up). If there are no free blocks, then some<br>
have to be flushed to their stack pages in main memory. When going down,<br>
tLow is loaded from a linked list, which might have to be extended by<br>
loading blocks from stack pages. With a 4KB stack cache, for example,<br>
there are 32 blocks with 32 words each and so block 0 can dedicate a<br>
word for each of the other 31 blocks. The bottom 7 bits of that word<br>
(only 5 actually needed, but it is nice to have a little room to grow)<br>
can form the &quot;previous&quot; linked list (tHigh and tLow would also be 5 bits<br>
wide) while the remaining bits can hold the block&#39;s address in main<br>
memory.<br>
<br>
This might seem far more complicated than a split arg/temp frame and it<br>
certainly would be if implemented in software. In hardware, it is mostly<br>
wires, a multiplexer and a small adder.</blockquote><div><br></div><div>A different world.  Cool!</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>