Hi Jecel,<div><br></div><div> you ask some pointed questions on the Stack & JIT Cog VMs that need good answers and I suspect are generally interesting so I'll answer to squeak-dev also.<br><br><div class="gmail_quote">
On Thu, May 14, 2009 at 4:36 AM, Jecel Assumpcao Jr <span dir="ltr"><<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
[snip] </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br></div><div class="im">Eliot wrote:<br>
> Yes. In the JIT an interpreted frame needs an extra field to hold<br>
> the saved bytecode instruction pointer when an interpreted frame<br>
> calls a machine code frame because the return address is the "return<br>
> to interpreter trampoline" pc. There is no flag word in a machine<br>
> code frame. So machine code frames save one word w.r.t. the<br>
> stack vm and interpreted frames gain a word. But most frames<br>
> 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'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.<br>
<br>
Will images be compatible between the JIT VM and the Stack VM? </blockquote><div><br></div><div>At least in the first version of the JIT yes. There are a couple of restrictions.</div><div><br></div><div>- the code that rebuilds the Character table in SystemDictionary>>recreateSpecialObjectsArray has to be replaced by code that simply copies the table. This is because the JIT caches the Character table's oop in the generated machine-code for the at: primitive</div>
<div><br></div><div>- the use (e.g. in Pharo) of the SmallInteger primitives 1 through 17 on LargePositiveInteger must be replaced by the relevant large integer primitives, which will be included in both the Stack and JIT Cog VMs.</div>
<div><br></div><div>But I do expect to evolve the object representation quite soon, and this will break image backward-compatibility altogether. But I will want to produce a Stack VM that is compatible with the new format, not just a JIT VM because platform spread is very important to maintain and it'll be a while before more ISAs than x86 will be supported.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Or do you<br>
expect the latter to not be used anymore once the JIT is available?</blockquote><div><br></div><div>I expect that an interpreted Stack VM will survive for a long time and be the standard VM on ISAs such as SPARC, Itanium, MIPS, while the JIT will be available probably in the following order IA32/x86, ARM32, x86-64, PowerPC.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I 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>No, the Stack VM is not compatible with older images. The Context VM with closure bytecode extensions (e.g. John's current 4.0 beta VM) is backward-compatible and is the bridge over which one can bring forward pre-closure images to the Stack VM and JIT VM which are Closure-only VMs.</div>
<div><br></div><div>One could make the Stack VM run older images but it would be difficult (and hence probably buggy) and I think unnecessary. One can always run older images on older VMs for as long as OSs support the older executables (and that other VM technology makes that easier these days). One can migrate an older image forward to the Stack VM using the bootstrap and the Context VM with Closure extensions. Packaging technologies such as Monticello make images much less important these days. One should expect to be able to export one's code in the form of a package and load it into a newer image, perhaps with a little massage. So keeping those dusty decks running on up-to-date VMs is IMO both wasted effort and a hindrance to obtaining maximum performance on newer VMs.</div>
<div><br></div><div>Best</div><div>Eliot</div></div></div>