Does Cog Interpreter state and cycle differ from the standard VM ?

Does Cog Interpreter state and cycle differ from the standard VM ?

Details are not needed, just a heads up so that when I do get to Cog work, I make it a point to study them.

From the Blue Book, here is the definition of Interpreter State and Cycle:

       Interpreter State:
     1. The CompiledMethod whose bytecodes ar being executed.
     2. The location of the next bytecode to be executed in that CompiledMethod: i.e its /instruction pointer/
     3. The receiver and arguments of the message that invoked the CompiledMethod.
     4. Any temporary variables needed by the CompiledMethod.
     5. a stack.

       Interpreter Cycle:
     1. fetch the bytecode from the CompiledMethod indicated by the instruction pointer.
     2. Increment the instruction pointer.
     3. Perform the function specified by the bytecode.


thx.

t

Hi Tim(othy?).

Thank you Eliot.

'Spaghetti Stack' I love it...

I want to get the standard VM under my belt first--walk before run and all that.

t, tim, or timothy is fine. 't' is easier to type and will not conflict with Tim Rowledge


Cordially,

t


---- On Tue, 26 Nov 2013 13:26:33 -0800 Eliot Miranda<[hidden email]> wrote ----

Hi Tim(othy?).

On Tue, Nov 26, 2013 at 1:22 PM, gettimothy <[hidden email]> wrote:

 

Does Cog Interpreter state and cycle differ from the standard VM ?

Yes.  Quite a lot.  The best overview is http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/.  Rationale for closures is in the posts named "Closure Overview" & "Closure Bytecodes".  HTH.

 

Details are not needed, just a heads up so that when I do get to Cog work, I make it a point to study them.

From the Blue Book, here is the definition of Interpreter State and Cycle:

       Interpreter State:
     1. The CompiledMethod whose bytecodes ar being executed.
     2. The location of the next bytecode to be executed in that CompiledMethod: i.e its /instruction pointer/
     3. The receiver and arguments of the message that invoked the CompiledMethod.
     4. Any temporary variables needed by the CompiledMethod.
     5. a stack.

       Interpreter Cycle:
     1. fetch the bytecode from the CompiledMethod indicated by the instruction pointer.
     2. Increment the instruction pointer.
     3. Perform the function specified by the bytecode.


thx.

t

--
best,

Eliot

Of course, a nickname is something personal, but I suggest tty, if you have affinity with bare os and low level stuff, it's a good match ;)

That's very good, thanks.

I will give it a try.

Cordially,

tty

Of course, a nickname is something personal, but I suggest tty, if you have affinity with bare os and low level stuff, it's a good match ;)

2013/11/26 gettimothy <[hidden email]>

 

Thank you Eliot.

'Spaghetti Stack' I love it...

I want to get the standard VM under my belt first--walk before run and all that.

t, tim, or timothy is fine. 't' is easier to type and will not conflict with Tim Rowledge


Cordially,

t


---- On Tue, 26 Nov 2013 13:26:33 -0800 Eliot Miranda<[hidden email]> wrote ----

Hi Tim(othy?).

On Tue, Nov 26, 2013 at 1:22 PM, gettimothy <[hidden email]> wrote:

 

Does Cog Interpreter state and cycle differ from the standard VM ?

Yes.  Quite a lot.  The best overview is http://www.mirandabanda.org/cogblog/2009/01/14/under-cover-contexts-and-the-big-frame-up/.  Rationale for closures is in the posts named "Closure Overview" & "Closure Bytecodes".  HTH.

 

Details are not needed, just a heads up so that when I do get to Cog work, I make it a point to study them.

From the Blue Book, here is the definition of Interpreter State and Cycle:

       Interpreter State:
     1. The CompiledMethod whose bytecodes ar being executed.
     2. The location of the next bytecode to be executed in that CompiledMethod: i.e its /instruction pointer/
     3. The receiver and arguments of the message that invoked the CompiledMethod.
     4. Any temporary variables needed by the CompiledMethod.
     5. a stack.

       Interpreter Cycle:
     1. fetch the bytecode from the CompiledMethod indicated by the instruction pointer.
     2. Increment the instruction pointer.
     3. Perform the function specified by the bytecode.


thx.

t

--
best,

Eliot