Re: The Trunk: System-fbs.627.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: System-fbs.627.mcz

Frank Shearar-3
On 26 November 2013 14:46,  <[hidden email]> wrote:

> Frank Shearar uploaded a new version of System to project The Trunk:
> http://source.squeak.org/trunk/System-fbs.627.mcz
>
> ==================== Summary ====================
>
> Name: System-fbs.627
> Author: fbs
> Time: 26 November 2013, 2:45:58.971 pm
> UUID: d1f0489e-96cf-c148-9b84-b361a1c5fb41
> Ancestors: System-fbs.626
>
> Really, I need to drink more coffee. _This_ reverts the API deprecation.
>
> =============== Diff against System-fbs.626 ===============
>
> Item was added:
> + ----- Method: Utilities class>>setSystemVersionFromConfig: (in category 'fetching updates') -----
> + setSystemVersionFromConfig: aConfig
> +       self deprecated: 'Use MCConfiguration >> #setSystemVersion'.
> +       aConfig setSystemVersion.!

Grrr. Finally. _This_ fixes the update stream. I'll be over here in
the dunce corner, with my pointy hat and paper bag.

frank

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: System-fbs.627.mcz

timrowledge

On 26-11-2013, at 6:50 AM, Frank Shearar <[hidden email]> wrote:
>
> Grrr. Finally. _This_ fixes the update stream. I'll be over here in
> the dunce corner, with my pointy hat and paper bag.

Like I said, the faster you get the stupid out of the way the sooner you look smart. Of course, it’s a bit less effective when your stupids gets emailed to a gazillion people...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Planetary axial tilt: the actual 'reason for the season'.


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: System-fbs.627.mcz

Nicolas Cellier
Thanks Franks, you finally got the (right) message ;)


2013/11/26 tim Rowledge <[hidden email]>

On 26-11-2013, at 6:50 AM, Frank Shearar <[hidden email]> wrote:
>
> Grrr. Finally. _This_ fixes the update stream. I'll be over here in
> the dunce corner, with my pointy hat and paper bag.

Like I said, the faster you get the stupid out of the way the sooner you look smart. Of course, it’s a bit less effective when your stupids gets emailed to a gazillion people...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Planetary axial tilt: the actual 'reason for the season'.





tty
Reply | Threaded
Open this post in threaded view
|

Stack VM = Squeak VM?

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

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









Reply | Threaded
Open this post in threaded view
|

Re: Stack VM = Squeak VM?

Levente Uzonyi-2
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.


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

Reply | Threaded
Open this post in threaded view
|

Re: Stack VM = Squeak VM?

Eliot Miranda-2



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


tty
Reply | Threaded
Open this post in threaded view
|

Re: Stack VM = Squeak VM?

tty
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, 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




Reply | Threaded
Open this post in threaded view
|

Re: Stack VM = Squeak VM?

Eliot Miranda-2
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