<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'>Hi Phil.<br><br>The only native64 vm&nbsp; I have running is the old (no block closures) standard interpreter. It powers either a 32 bit image or a 64 bit image.<br><br>For an overview of my understanding of the subject, read the rest of this comment.<br><br><br><br><br>This is my state of understanding--expect mistakes.<br><br>First some base assumptions.<br><br>1. I have a tri-boot 64 bit machine that boots to either&nbsp; a) dos 7, b) Slackware Linux 64 with 32 bit compat libs or c) Slackware Linux 64 (no 32 bit libs)<br>2. I currently must run Squeak on b) Slackware Linux 64 with 32 bit compat libs<br>3. So, my reference point is only on the linux side since that is where I work. my goal is a native 64 bit application on c).<br><br>There are (at least) 3 flavors of the VM building tools.<br><br>1. The Standard Interpreter that Daniel T. Lewis maintains<br>2. Cog (This tool includes infrastructure to build Cog, StackInterpreter, Newspeak and Spur (don't know this yet) etc.it is the cutting edge environment )<br>3. Cog ala Pharo<br><br>I am only working with 1 and 2. I may get to 3 for completeness sake when I get fluent at this stuff.<br><br><br>1. The Standard Interpreter uses VMMaker as its code generator and CMAKE as its configure/build tool.<br>2. Cog&nbsp; uses VMMaker.oscog as its simulation base, code generator and seems to be transitioning to a GNU Make environment. <br>&nbsp;&nbsp; 2.a . An SVN repository exists with generated code for cog, stackinterpreter, newspeak....this does not seem to be kept in sync with 2 but I am not sure. I forget why I came to that conclusion.<br>3. The Pharo team uses VMMaker-oscog (note the 'dash' vs the 'dot' in 2) <br><br><br>When referring to VM/ObectMemory pairs, I use the following terminology<br><br>1. standardVM32 (32 bit runtime vm [requires compat libs on my platform] powering a 32 bit image)<br>2. standardVM32x64&nbsp; (32 bit runtime vm [requires compat libs on my platform] powering a 64 bit image)<br>3. standardVM64x32&nbsp;&nbsp; (64 bit native runtime vm powering a 32 bit image)<br>4. standardVM64x64&nbsp; (64 bit native runtime vm powering a 64 bit image)<br>5. stackVM32&nbsp; <br>6. stackVM64&nbsp; <br>7&nbsp; stackVM64x64 <br>8. cogVM32&nbsp; (what we all know and love)<br>9&nbsp; cogVM64&nbsp; (not implemented yet)<br>10. cogVM64x64 (a gleam in some enterprising coders eye)<br>11. cogSpur....???<br>..<br>99. cogQ (cog running on quantum bits platform j.k. (:<br><br><br>I have successfully build from first principles <br>1. standardVM64x32 , <br>2. standardVM64x64 , <br>3. stackVM32 (both SVN source and generated code using VMMaker.oscog), <br>4. cogVM32 (from SVN source only. I have had issues generating source from VMMaker.oscog)<br><br><b>Now, 1 and 2 are not my doing</b>. <b>This is all because CMake somehow detects my platform and generates a pure 64 bit VM without me having to do a thing.</b><br>2 has two "idioms" for obtaining a 64 bit image--download from Jenkins one or roll your own using a tool Daniel devised named SystemTracer.<br><br>My next goal is StackVM64, however, I am taking a detour to learn plugins before I tackle that. I also have to overcome the generate Cog Sources hurdle for this plugin work.<br><br>When I do get to working on a StackVM64, I am curious as to a couple of things. <br><br>1. Why does the CMAKE build a native 64 bit application and the GNU Make not?<br>2. Is a first step to emulate in the GNU Make what Cmake does?<br>3. Is the above a "real" 64 bit app in that it makes use of the full register size? or is it something else.<br>4. ...?<br><br>Anyway that is my thinking to date.<br><br>cheers.<br><br>tty<br><br><br><div id="1"><br>---- On Tue, 01 Apr 2014 21:24:30 -0700 <b> &lt;phil@highoctane.be&gt;</b> wrote ---- <br></div><br><blockquote style="border-left: 1px solid #0000FF; padding-left: 6px; margin:0 0 0 5px"> <p dir="ltr">How would that work?<br> Would this be a 32 bit Object memory and engine compiled in 64bit mode?<br> How is the code amended to make that possible?<br> Is there a source tree somewhere?</p> <p dir="ltr">There are "int"s all over the place, so, how do we handle this? </p> <p dir="ltr">For the Slang part it appears doable. For the support code, especially Windows, it looks harder.</p> <p dir="ltr">TIA<br> Phil</p> <div>Le 2 avr. 2014 01:07, "Clément Bera" &lt;<a href="mailto:bera.clement@gmail.com" target="_blank">bera.clement@gmail.com</a>&gt; a écrit :<br type="attribution"><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir="ltr">Hey,<div><br></div><div>For 64 bits Spur is a big step forward. For Christmas you should have at least the stack VM in 64bits. The JIT may take a bit longer to port. Esteban and Eliot will work on that starting from May.&nbsp;</div> <div><br></div><div>There's also the solution to compile the VM in 64bits with a 32bits runtime (I think FFI does not work, but the VM works in 64bits environment, as gettimothy posted on vm-dev).&nbsp;</div></div><div> <br><br><div>2014-03-29 13:18 GMT-07:00 Pharo4Stef <span dir="ltr">&lt;<a href="mailto:pharo4Stef@free.fr" target="_blank">pharo4Stef@free.fr</a>&gt;</span>:<br><blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><div><br> On 29 Mar 2014, at 21:16, Roelof Wobben &lt;<a href="mailto:r.wobben@home.nl" target="_blank">r.wobben@home.nl</a>&gt; wrote:<br> <br> &gt; Pharo4Stef schreef op 29-3-2014 21:07:<br> &gt;&gt;<br> &gt;&gt;<br> &gt;&gt;&gt; Pity.<br> &gt;&gt;<br> &gt;&gt; You know there is no magic powder. We are already really grateful that eliot is pushing the vm work.<br> &gt;&gt; Esteban will help on the 64 bits and clement probably too or spur and new bytecodes plus language side optimisations. If we could pay 3 full time engineers in the future… but this is not the case.<br> &gt;&gt;<br> &gt;<br> &gt; I know that and it's not that i think the developer do a bad job.<br> &gt; It's more a expresiion of my feeling.<br> <br> </div></div>Ok then I share the same feeling :)<br> <br> &gt;<br> &gt; Roelof<br> &gt;<br> <br> <br> </blockquote></div><br></div> </blockquote></div> </blockquote><br></div></body></html>