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)
8. cogVM32 (what we all know and love)
9 cogVM64 (not implemented yet)
10. cogVM64x64 (a gleam in some enterprising coders eye)
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.
Anyway that is my thinking to date.
---- On Tue, 01 Apr 2014 21:24:30 -0700 <[hidden email]> wrote ----
VM-beginners mailing list
> 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.
The interpreter VM that you built has full support for Eliot's block
VM-beginners mailing list
|Free forum by Nabble - Resume Templates||Edit this page|