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

Eliot Miranda eliot.miranda at gmail.com
Fri May 16 23:47:17 UTC 2014


On Fri, May 16, 2014 at 8:53 AM, gettimothy <gettimothy at zoho.com> wrote:

>
> Hi Guys,
>
> Here is my take on thinking about the Squeak Virtual Machines.
>
> There are 3 iterations (plus the funky-stuff Eliot is adding to Cog, which
> I ignore here)
>
> 1. Standard Virtual Machine
> 2  Stack Interpreter  (first iteration of Cog work)
> 3. Cog. (plus all stuff Eliot is doing on top of that).
> 4. Spur is coming up so we ignore for now.
>
>
> I use the following terminology to refer to VM word size x Image Size
>
> a. 32x32 =  32 bit vm word size and 32 bit image
> b. 32x64  = 32 bit vm word size and 64 bit image (can hold more objects)
> c. 64x32  = 64 bit vm word size and 32 bit image
> d. 64x64  = 64 bit vm word size and 64 bit image
>
>
> Then,  there is the distinction of the computer itself and its libraries.
>
> X. 32 bit machine
> Y. 64 bit machine
> Z. 64 bit machine with 32 bit compatibility libraries.
>
>
> Finally, there is the distinction of build tools:
> VMMaker
> VMaker-oscog  (used by Pharo team only)
> VMMaker.oscog
> (Coming up is CMakeVMMaker)
>
>
> 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
> timmydosmalltalk.wordpress.org
> Stack Interpreter only support 32x32 on 32 bit machine and  64 bit machine
> with 32 bit compatibility libraries and uses VMMaker.oscog
> Cog                   only support 32x32 on 32 bit machine and  64 bit
> machine with 32 bit compatibility libraries and uses VMMaker.oscog
>
>
> With Spur, Eliot will have Cog running a 64x32 capability--i.e. native 64
> bit vm with 32 bit image.
>

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.


> My personal dev goal is to port Stack Intepreter to 64x32 followed by
> 64x64.
>

I see no point in porting the STackInterpreter to 64x32.  You should target
directly 64x64 Spur.


>
> Hope that helps.
>

I hope I've helped too :-)


> tty
>
>
> ---- On Fri, 16 May 2014 01:36:50 -0700 *Esteban
> Lorenzano<estebanlm at gmail.com <estebanlm at gmail.com>>* wrote ----
>
>
> On 16 May 2014, at 10:27, phil at highoctane.be wrote:
>
> On Fri, May 16, 2014 at 10:20 AM, Esteban Lorenzano <estebanlm at gmail.com>wrote:
>
>
> On 15 May 2014, at 18:46, Hilaire Fernandes <hilaire.fernandes at gmail.com>
> wrote:
>
> > Great.
> >
> > As we are discussing about build, is it possible to compile CogVM on 64
> > bits architecture as it is already the case for the interpreted SqueakVM
> > (https://packages.debian.org/sid/squeak-vm)?
>
> 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:
>
> - you need a 64bits image (so trace, export, etc.)
>
>
> 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?
>
>
> - you need to be 64bits word size aware (not so complicated, but a lot of
> work).
> - you need 64bits plugins (a lot of them)
> - you need 64bits JIT (or no JIT at all)
>
>
> And...
>
> * 64-bit aware hashing functions as the current ones are 32-bit centric.
> So, not so trivial I'd say. (what's the plan?)
>
> * 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.
>
>
> yes, the plan is to introduce SmallFloat, etc.
> So, in summary: a lot of work :)
>
>
> As a side note, I see that http://www.mpfr.org/ is supported by INRIA.
> WTF aren't we considering this ? LGPL and INRIA may help getting some
> special thing for Pharo.
>
> Phil
>
>
> Some time ago there was an experimental 64bits interpreter vm (not even
> stack). Who worked with a special traced image.
> What squeak guys are doing in the link you provide is still building a
> 32bits vm.
>
> 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.
>
> Esteban
>
>
> >
> > Hilaire
> >
> > Le 15/05/2014 18:24, Esteban Lorenzano a écrit :
> >> so yes… I integrated the fix, created a pull request, waited until
> validation… and then I forget to merge :S
> >> it should be in process to build now.
> >
> > --
> > Dr. Geo http://drgeo.eu/
> >
> >
>
>
>
>
>
>
>


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


More information about the Vm-dev mailing list