Re: [squeak-dev] Stack VM = Squeak VM?

Oops, I posted to squeak-dev instead of vm-dev. I have added a CC so we can continue there if you wish.

Ahhhh, I see what's going on now, its an incremental approach..makes sense now.

Smalltalk-80 VM (Blue Book) -> Squeak VM (OE-Tour.pdf)->Stack VM (http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/)->Cog (JIT, Stack To Register Mapping, ..http://www.mirandabanda.org/cogblog/about-cog/)
->Spur (changing the garbage collector and the object representation) ->Lazy Become (http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-read-barrier/)


From your post here: http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/ I gather you used the StackVM with Alien and Bochs as your base to build the JIT for Cog .


So then, in an earlier response to my inquiry on the ~$1,000,000 bounty for cmakeifying the process thread, you wrote

...then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.

Which makes sense. Basically, I would be doing a 64 bit version of follow the leader on your existing 32 bit work where it should all come together at Spur.

Does that sound about right?

tty

On Wed, Nov 27, 2013 at 8:05 AM, Levente Uzonyi <[hidden email]> wrote:

On Wed, 27 Nov 2013, gettimothy wrote:

I am confused as to what the term 'Stack VM' refers to.

"The StackInterpreter is an intermediate step after closures and before the JIT to ensure steady progress and on-time delivery of a substantially faster VM. The essential point, of course, is that a stack organization suits the use of native call and return instructions whose use, along with in-line cacheing techniques, substantially improve send and return performance." - http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/

I would say it's a CogVM without a JIT.

Exactly.  Another way of saying it is that the StackVM is an interpreter that doesn't use contexts.  Instead it uses stack frames, much like a conventional language implementation.  And remember "doesn't use contexts" doesn't mean "doesn't have contexts"; instead context objects are created when the program asks for them instead of on every send.  The StackVM's performance is about 1.5x the Context Interpreter VM.  The Cog VM is about 5x the Context Interpreter VM.

Levente

> Here is the outline I have. > > Smalltalk VM = Blue

Book > Squeak VM   = Tim Rowledge's OE-Tour.pdf

Stack VM      =  ??
Cog              = Squeak VM redesigned  per http://www.mirandabanda.org/cogblog/about-cog/

thx,

tty

--
best,

Eliot

Cool.

One more thing to clarify: does running the simulator require having Bochs installed? (From what I can see, yes, but its not clear from your instructions here: http://www.mirandabanda.org/cogblog/build-image/  )

Finally, here is my game-plan.

1. I am going to finish my overview of the Blue Book Object Memory etc and NOT go into a study of the details in the last chapters of part 4--I will refer back to it when needed to understand a specific situation.
2. Get Bochs running on a 32 bit capable slackware linux 
   (My bochs install on my 32 bit capable Slackware dies because of a bug in binutils-22. Slackware has a new 14.1 release out with the updated binutils, so hopefully I can get squeak/bochs running together on linux. it installs fine on my pure 64 bit boot. chicken,egg...)
3  Verify that me not having installed Bochs is why I could install your Cog dev environment but not be able to launch the simulations.
4. I will then study the Stack VM and try to replicate what you did with Stack VM in 64 bits on Spur using the steps you posted a few weeks ago:

Read the latest two articles on my blog (A Spur gear for Cog & Lazy Become).

Make a VMMaker image (see e.g. Cog Blog :: Building a Cog Development Image).

Then read SpurMemoryManager, /especially/ its class comment.

Then read its subclasses Spur32BitMemoryManager (functional) & Spur64BitMemoryManager (completely untested).

Then read SpurBootstrap32.

Try and create a 32-bit Spur image and run it.

Then try and implement SpurBootstrap64.

Try and create a 64-bit Spur image and run it.

 

Sound like a plan?

thx.

tty

Hi tty,

On Wed, Nov 27, 2013 at 9:19 AM, gettimothy <[hidden email]> wrote:

Oops, I posted to squeak-dev instead of vm-dev. I have added a CC so we can continue there if you wish.

Ahhhh, I see what's going on now, its an incremental approach..makes sense now.

Yes.  Qwaq got something faster sooner.  The phone folks got a faster VM that doesn't require a JIT (see StackVM on Android, iPhone etc).  I got a simpler simulator for Spur.  Lots of advantages.

Smalltalk-80 VM (Blue Book) -> Squeak VM (OE-Tour.pdf)->Stack VM (http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/)->Cog (JIT, Stack To Register Mapping, ..http://www.mirandabanda.org/cogblog/about-cog/)
->Spur (changing the garbage collector and the object representation) ->Lazy Become (http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-and-a-partial-read-barrier/)


From your post here: http://www.mirandabanda.org/cogblog/2008/12/12/simulate-out-of-the-bochs/ I gather you used the StackVM with Alien and Bochs as your base to build the JIT for Cog .

That's right.

 

So then, in an earlier response to my inquiry on the ~$1,000,000 bounty for cmakeifying the process thread, you wrote

...then you could instead have a go at getting the Stack VM working in 64-bits, and that would involve getting the 64-bit VM simulator working in VMMaker.

Which makes sense. Basically, I would be doing a 64 bit version of follow the leader on your existing 32 bit work where it should all come together at Spur.

Does that sound about right?

Exactly right.  With the StackVM simulator you can get a 64-bit Spur memory manager working.  Then you can get an x86-64 code generator going with the Cog VM simulator.

tty

---- On Wed, 27 Nov 2013 08:47:03 -0800 Eliot Miranda <[hidden email]> wrote ----

On Wed, Nov 27, 2013 at 8:05 AM, Levente Uzonyi <[hidden email]> wrote:

On Wed, 27 Nov 2013, gettimothy wrote:

I am confused as to what the term 'Stack VM' refers to.

"The StackInterpreter is an intermediate step after closures and before the JIT to ensure steady progress and on-time delivery of a substantially faster VM. The essential point, of course, is that a stack organization suits the use of native call and return instructions whose use, along with in-line cacheing techniques, substantially improve send and return performance." - http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/

I would say it's a CogVM without a JIT.

Exactly.  Another way of saying it is that the StackVM is an interpreter that doesn't use contexts.  Instead it uses stack frames, much like a conventional language implementation.  And remember "doesn't use contexts" doesn't mean "doesn't have contexts"; instead context objects are created when the program asks for them instead of on every send.  The StackVM's performance is about 1.5x the Context Interpreter VM.  The Cog VM is about 5x the Context Interpreter VM.

Levente

> Here is the outline I have. > > Smalltalk VM = Blue

Book > Squeak VM   = Tim Rowledge's OE-Tour.pdf

Stack VM      =  ??
Cog              = Squeak VM redesigned  per http://www.mirandabanda.org/cogblog/about-cog/

thx,

tty

--
best,

Eliot

--
best,

Eliot

Hi tty