Re: [Vm-dev] Re: [Pharo-users] 64 bit version

Hi Phil.

The only native64 vm  I have running is the old (no block closures) standard interpreter. It powers either a 32 bit image or a 64 bit image.

For an overview of my understanding of the subject, read the rest of this comment.




This is my state of understanding--expect mistakes.

First some base assumptions.

1. I have a tri-boot 64 bit machine that boots to either  a) dos 7, b) Slackware Linux 64 with 32 bit compat libs or c) Slackware Linux 64 (no 32 bit libs)
2. I currently must run Squeak on b) Slackware Linux 64 with 32 bit compat libs
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).

There are (at least) 3 flavors of the VM building tools.

1. The Standard Interpreter that Daniel T. Lewis maintains
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 )
3. Cog ala Pharo

I am only working with 1 and 2. I may get to 3 for completeness sake when I get fluent at this stuff.


1. The Standard Interpreter uses VMMaker as its code generator and CMAKE as its configure/build tool.
2. Cog  uses VMMaker.oscog as its simulation base, code generator and seems to be transitioning to a GNU Make environment.
   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.
3. The Pharo team uses VMMaker-oscog (note the 'dash' vs the 'dot' in 2)


When referring to VM/ObectMemory pairs, I use the following terminology

1. standardVM32 (32 bit runtime vm [requires compat libs on my platform] powering a 32 bit image)
2. standardVM32x64  (32 bit runtime vm [requires compat libs on my platform] powering a 64 bit image)
3. standardVM64x32   (64 bit native runtime vm powering a 32 bit image)
4. standardVM64x64  (64 bit native runtime vm powering a 64 bit image)
5. stackVM32 
6. stackVM64 
7  stackVM64x64
8. cogVM32  (what we all know and love)
9  cogVM64  (not implemented yet)
10. cogVM64x64 (a gleam in some enterprising coders eye)
11. cogSpur....???
..
99. cogQ (cog running on quantum bits platform j.k. (:


I have successfully build from first principles
1. standardVM64x32 ,
2. standardVM64x64 ,
3. stackVM32 (both SVN source and generated code using VMMaker.oscog),
4. cogVM32 (from SVN source only. I have had issues generating source from VMMaker.oscog)

Now, 1 and 2 are not my doing. This is all because CMake somehow detects my platform and generates a pure 64 bit VM without me having to do a thing.
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.

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.

When I do get to working on a StackVM64, I am curious as to a couple of things.

1. Why does the CMAKE build a native 64 bit application and the GNU Make not?
2. Is a first step to emulate in the GNU Make what Cmake does?
3. Is the above a "real" 64 bit app in that it makes use of the full register size? or is it something else.
4. ...?

Anyway that is my thinking to date.

cheers.

tty

How would that work?
Would this be a 32 bit Object memory and engine compiled in 64bit mode?
How is the code amended to make that possible?
Is there a source tree somewhere?

There are "int"s all over the place, so, how do we handle this?

For the Slang part it appears doable. For the support code, especially Windows, it looks harder.

TIA
Phil

Le 2 avr. 2014 01:07, "Clément Bera" <[hidden email]> a écrit :

Hey,

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. 

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

2014-03-29 13:18 GMT-07:00 Pharo4Stef <[hidden email]>:

On 29 Mar 2014, at 21:16, Roelof Wobben <[hidden email]> wrote:

> Pharo4Stef schreef op 29-3-2014 21:07:
>>
>>
>>> Pity.
>>
>> You know there is no magic powder. We are already really grateful that eliot is pushing the vm work.
>> 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.
>>
>
> I know that and it's not that i think the developer do a bad job.
> It's more a expresiion of my feeling.

Ok then I share the same feeling :)

>
> Roelof
>