[Vm-dev] Re: [Pharo-dev] 32 bits and 64 bits VM

[Eliot Miranda]

Hi Esteban,


On Fri, May 16, 2014 at 7:52 AM, Esteban Lorenzano <estebanlm at gmail.com>wrote:

>
> I wonder how.
> 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).
>

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,


> 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).
>

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.

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.

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.

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.
>

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.



> … or I’m having wrong assumptions, and it is easily feasible, but I do not
> think so.
>
> Esteban
>
> On 16 May 2014, at 16:31, Chris Cunningham <cunningham.cb at gmail.com>
> wrote:
>
> Right.  Running an image natively in 64 bits doesn't mean you have to have
> a 64 bit image as well.
>
> 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/
> (not my work at all - just sharing).
>
> -cbc
>
>
> On Fri, May 16, 2014 at 6:33 AM, Hilaire Fernandes <
> hilaire.fernandes at gmail.com> wrote:
>
>> the SqueakVM https://packages.debian.org/sid/amd64/squeak-vm/download
>> is linked against 64bits libraries, at least as far as I am correct this
>> is what say:
>>
>> ldd squeakvm
>>
>> Next I tested I can run DrGeo (1.4 pharo based, 32 bits image) with this
>> VM on a 64 bits host (uname -a).
>>
>> Pharo 2 does not work as this vm is too old.
>>
>> Where am I wrong?
>>
>> Hilaire
>>
>> Le 16/05/2014 10:20, Esteban Lorenzano a écrit :
>> > I do not understand. To compile a regular vm in a 64bits platform is
>> trivial. You just need to have the 32bits library installed.
>> > But to have a 64bits vm that runs on 64bits… that’s another very
>> different history:
>>
>> --
>> Dr. Geo http://drgeo.eu
>>
>>
>>
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140516/9a6bbd06/attachment-0001.htm