<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 16, 2014 at 8:53 AM, gettimothy <span dir="ltr"><<a href="mailto:gettimothy@zoho.com" target="_blank">gettimothy@zoho.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br><u></u><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><div>Hi Guys,<br></div><div>
<br></div><div>Here is my take on thinking about the Squeak Virtual Machines.</div><div><br></div><div>There are 3 iterations (plus the funky-stuff Eliot is adding to Cog, which I ignore here)</div><div><br></div><div>1. Standard Virtual Machine </div>
<div>2 Stack Interpreter (first iteration of Cog work)</div><div>3. Cog. (plus all stuff Eliot is doing on top of that).</div><div>4. Spur is coming up so we ignore for now.</div><div><br></div><div><br></div><div>I use the following terminology to refer to VM word size x Image Size</div>
<div><br></div><div>a. 32x32 = 32 bit vm word size and 32 bit image </div><div>b. 32x64 = 32 bit vm word size and 64 bit image (can hold more objects)</div><div>c. 64x32 = 64 bit vm word size and 32 bit image</div><div>
d. 64x64 = 64 bit vm word size and 64 bit image</div><div><br></div><div><br></div><div>Then, there is the distinction of the computer itself and its libraries.</div><div><br></div><div>X. 32 bit machine</div><div>Y. 64 bit machine</div>
<div>Z. 64 bit machine with 32 bit compatibility libraries.</div><div><br></div><div><br></div><div>Finally, there is the distinction of build tools: </div><div>VMMaker </div><div>VMaker-oscog (used by Pharo team only)</div>
<div>VMMaker.oscog</div><div>(Coming up is CMakeVMMaker)</div><div><br></div><div><br></div><div>Standard Virtual Machine supports 32x32,32x64,64x32 and 64x64 on 32 bit machine 64 bit machine and 64 bit machine with 32 bit compatibility libraries and uses VMMaker. I covered this in a series at my blog <a href="http://timmydosmalltalk.wordpress.org" target="_blank">timmydosmalltalk.wordpress.org</a></div>
<div>Stack Interpreter only support 32x32 on 32 bit machine and 64 bit machine with 32 bit compatibility libraries and uses VMMaker.oscog </div><div>Cog only support 32x32 on 32 bit machine and 64 bit machine with 32 bit compatibility libraries and uses VMMaker.oscog </div>
<div><br></div><div><br></div><div>With Spur, Eliot will have Cog running a 64x32 capability--i.e. native 64 bit vm with 32 bit image.</div></div></div></blockquote><div><br></div><div>No. That's not the point of Spur. The point of Spur is to provide a faster, more flexible GC, with a lot of shared code between the 32-bit and 64-bit memory managers. This results i a 32-bit image over a a 32-bit executable with a 32-bit FFI and a 64-bit image (with SmallFloat) over a 64-bit executable with a 64-bit FFI. I'm not interested in producing e.g. a 32-bit image over a 64-bit executable with a 64-bit FFI.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><div><br></div><div>My personal dev goal is to port Stack Intepreter to 64x32 followed by 64x64.</div>
</div></div></blockquote><div><br></div><div>I see no point in porting the STackInterpreter to 64x32. You should target directly 64x64 Spur.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><div><br></div><div>Hope that helps.</div></div></div></blockquote><div><br></div><div>I hope I've helped too :-)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div style="font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif"><div><span style="font-size:10pt">tty</span><br></div><div><br></div><div><br>---- On Fri, 16 May 2014 01:36:50 -0700 <b>Esteban Lorenzano<<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></b> wrote ---- <br>
</div><br><blockquote style="border-left:1px solid #0000ff;padding-left:6px;margin:0 0 0 5px"> <div style="word-wrap:break-word"><br><div><div>On 16 May 2014, at 10:27, <a href="mailto:phil@highoctane.be" target="_blank">phil@highoctane.be</a> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div><div><div dir="ltr">On Fri, May 16, 2014 at 10:20 AM, Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span> wrote:<br>
</div></div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br> On 15 May 2014, at 18:46, Hilaire Fernandes <<a href="mailto:hilaire.fernandes@gmail.com" target="_blank">hilaire.fernandes@gmail.com</a>> wrote:<br>
<br> > Great.<br> ><br> > As we are discussing about build, is it possible to compile CogVM on 64<br> > bits architecture as it is already the case for the interpreted SqueakVM<br> > (<a href="https://packages.debian.org/sid/squeak-vm" target="_blank">https://packages.debian.org/sid/squeak-vm</a>)?<br>
<br> I do not understand. To compile a regular vm in a 64bits platform is trivial. You just need to have the 32bits library installed.<br> But to have a 64bits vm that runs on 64bits… that’s another very different history:<br>
<br> - you need a 64bits image (so trace, export, etc.)<br></blockquote><div><br></div><div>ImageTracers are intriguing to me :-) Is this in some way relatable to Oz? What's that project doing now? It was very interesting/useful. Guille?</div>
<div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> - you need to be 64bits word size aware (not so complicated, but a lot of work).<br>
- you need 64bits plugins (a lot of them)<br> - you need 64bits JIT (or no JIT at all)<br> <br></blockquote><div><br></div><div>And...</div><div><br></div><div>* 64-bit aware hashing functions as the current ones are 32-bit centric. So, not so trivial I'd say. (what's the plan?)</div>
<div><br></div><div> * special care of the Float which will be directly in a 64 bit "oop" - I guess we'll face some fun here. Especially with the float plugin. </div></div></div></div></blockquote><div><br></div>
<div>yes, the plan is to introduce SmallFloat, etc.</div><div>So, in summary: a lot of work :)</div><br><blockquote type="cite"><div dir="ltr"><div><div><div><br></div><div>As a side note, I see that <a href="http://www.mpfr.org/" target="_blank">http://www.mpfr.org/</a> is supported by INRIA. WTF aren't we considering this ? LGPL and INRIA may help getting some special thing for Pharo.</div>
<div><br></div><div>Phil</div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Some time ago there was an experimental 64bits interpreter vm (not even stack). Who worked with a special traced image.<br>
What squeak guys are doing in the link you provide is still building a 32bits vm.<br> <br> Now. In the agenda for this year is to work on a 64bits spur version. If everything is fine and the stars align properly, it will be ready around christmas.<br>
<br> Esteban<br> <br> <br> ><br> > Hilaire<br> ><br> > Le 15/05/2014 18:24, Esteban Lorenzano a écrit :<br> >> so yes… I integrated the fix, created a pull request, waited until validation… and then I forget to merge :S<br>
>> it should be in process to build now.<br> <span><font color="#888888">><br> > --<br> > Dr. Geo <a href="http://drgeo.eu/" target="_blank">http://drgeo.eu/</a><br> ><br> ><br> <br> <br> </font></span></blockquote>
</div><br></div></div> </blockquote></div><br></div></blockquote><br></div></div><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>