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?).
On Tue, Nov 26, 2013 at 1:22 PM, gettimothy gettimothy@zoho.com 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-.... 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 thatCompiledMethod: 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 theinstruction pointer. 2. Increment the instruction pointer. 3. Perform the function specified by the bytecode.
thx.
t
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<eliot.miranda@gmail.com> wrote ----
Hi Tim(othy?).
On Tue, Nov 26, 2013 at 1:22 PM, gettimothy <gettimothy@zoho.com> 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-.... 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
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 gettimothy@zoho.com
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<eliot.miranda@gmail.com eliot.miranda@gmail.com>* wrote ----
Hi Tim(othy?).
On Tue, Nov 26, 2013 at 1:22 PM, gettimothy gettimothy@zoho.com 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-.... 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 thatCompiledMethod: 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 theinstruction pointer. 2. Increment the instruction pointer. 3. Perform the function specified by the bytecode.
thx.
t
-- best, Eliot
That's very good, thanks.
I will give it a try.
Cordially,
tty
---- On Tue, 26 Nov 2013 14:30:53 -0800 Nicolas Cellier<nicolas.cellier.aka.nice@gmail.com> wrote ----
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 <gettimothy@zoho.com>
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<eliot.miranda@gmail.com> wrote ----
Hi Tim(othy?).
On Tue, Nov 26, 2013 at 1:22 PM, gettimothy <gettimothy@zoho.com> 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-.... 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
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
gettimothy -
Nicolas Cellier