<div dir="ltr">Hi Esteban,<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 16, 2014 at 7:52 AM, Esteban Lorenzano <span dir="ltr"><<a href="mailto:estebanlm@gmail.com" target="_blank">estebanlm@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" 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><div style="word-wrap:break-word">I wonder how. <div>
AFAIK different length of word will warranty that you cannot use most of the plugins (in the case you actually can compile the vm without made any change). </div></div></blockquote><div><br></div><div>That's right. The plugins must at least be recompiled for 64-bits. The 64-bit VM will not be able to load 32-bit plugins, nor vice verce. And being able to do so seems of little benefit to me. The VMs will be different. If we want a single executable then we'll need e.g. Contents/resources64 & Contents/Resources32. But it seems easier to me to produce Cog32.app & Cog64.app,</div>
<div> </div><blockquote class="gmail_quote" 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"><div style="word-wrap:break-word"><div>I know Dave made the interpreter vm compilable in 64bits, with a flag or something. But that not talks about the plugins (FFI, in particular, I do not think will work). </div>
</div></blockquote><div><br></div><div>Most plugins should work. The interface between the VM, InterpreterProxy/sqVirtualMachine.[ch] deals mostly with oops and words. e.g. converting form a Float object to a double value is done by sqInt (*floatObjectOf)(double aFloat) & double (*floatValueOf)(sqInt oop). This can insulate plugins from the introduction of SmallFloat.</div>
<div><br></div><div>What does change is the FFI. The x86-64/IA64 calling convention is entirely different from the x86/IA32 calling convention. So this needs to be rewritten.</div><div><br></div><div>Presumably there are plugins like compression, decompression, bitmap display etc, which can benefit from being rewritten to use 64-bits if available. And presumably some will /have/ to be rewritten to be correct. but on the whole plugins that are simply interfaces to libraries should "just work". But in any case, they will need to be tested and probably their source code carefully read. But for example when I did the 64-bit version of VisualWorks very very few primitives changed.</div>
<div><br></div><blockquote class="gmail_quote" 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"><div style="word-wrap:break-word"><div>For compiling the stack/cog there are other problems, I think. I may be wrong, but even the StackVM will have some problems because registers change in 64bits. </div>
</div></blockquote><div><br></div><div>There are certainly 64-bit issues. For example, byte reversal code on image load is different in 64-bits. But it can be abstracted. e.g. something called byteSwapMachineWordAt: can insulate an image loader from the details. But the StackVM contains no registers, only variables that hold oops or machine words. So the core execution engine shouldn't be affected by 32/64.</div>
<div> </div><div> </div><blockquote class="gmail_quote" 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"><div style="word-wrap:break-word">
<div>… or I’m having wrong assumptions, and it is easily feasible, but I do not think so. </div><div><br></div><div>Esteban</div><div><br><div><div>On 16 May 2014, at 16:31, Chris Cunningham <<a href="mailto:cunningham.cb@gmail.com" target="_blank">cunningham.cb@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr">Right. Running an image natively in 64 bits doesn't mean you have to have a 64 bit image as well.<div><a href="http://timmydosmalltalk.wordpress.com/2014/03/13/howto-build-a-64-native-standardvm-running-32-bit-image-on-slackware-linux-14-1-with-32-bit-compat-libs/" target="_blank">http://timmydosmalltalk.wordpress.com/2014/03/13/howto-build-a-64-native-standardvm-running-32-bit-image-on-slackware-linux-14-1-with-32-bit-compat-libs/</a><br>
</div><div>(not my work at all - just sharing).</div><div><br></div><div>-cbc</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, May 16, 2014 at 6:33 AM, Hilaire Fernandes <span dir="ltr"><<a href="mailto:hilaire.fernandes@gmail.com" target="_blank">hilaire.fernandes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" 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">the SqueakVM <a href="https://packages.debian.org/sid/amd64/squeak-vm/download" target="_blank">https://packages.debian.org/sid/amd64/squeak-vm/download</a><br>
is linked against 64bits libraries, at least as far as I am correct this<br>
is what say:<br>
<br>
ldd squeakvm<br>
<br>
Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this<br>
VM on a 64 bits host (uname -a).<br>
<br>
Pharo 2 does not work as this vm is too old.<br>
<br>
Where am I wrong?<br>
<br>
Hilaire<br>
<br>
Le 16/05/2014 10:20, Esteban Lorenzano a écrit :<br>
<div>> 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>
</div><div><div>--<br>
Dr. Geo <a href="http://drgeo.eu/" target="_blank">http://drgeo.eu</a><br>
<br>
<br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div></div><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>