SysRPL Runstream and Return Stack - Hewlett Packard

This is a discussion on SysRPL Runstream and Return Stack - Hewlett Packard ; Hi group. Here I'm again to ask your help for an "as-full-as-I-can" understanding of the logics of SysRPL... Talking about runstream and return stack, Kalinowski/Dominik's book says, on page 121: "Since the objects are executed in order, it becomes necessary ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: SysRPL Runstream and Return Stack

  1. SysRPL Runstream and Return Stack

    Hi group.
    Here I'm again to ask your help for an "as-full-as-I-can"
    understanding of the logics of SysRPL...
    Talking about runstream and return stack, Kalinowski/Dominik's book
    says,
    on page 121:

    "Since the objects are executed in order, it becomes necessary to have
    some kind of variable that will always point to the next object to be
    executed.
    This is called the interpreter pointer, and is stored in a CPU
    register. After
    each object is executed, this pointer is advanced to point to the next
    object."

    If I understand correctly, it means that if we have the following
    runstream:





    then something like this happens (IP = Interpreter Pointer, CR = CPU
    register):

    ---> executed
    IP points to obj_2 (i.e. obj_2's address is put into the
    CR)
    ---> executed
    IP points to obj_3 (i.e. obj_3's address is put into the
    CR)
    ---> executed

    Right?
    The CPU register used in this case is always the same, i.e. is step
    after step overwritten? (it would not be a true stack, in that case,
    but a single mem location...)

    Now, when at least one of the objects in the runstream is a composite,
    they say:

    "When a secondary (or any other composite) is executed, the address of
    the object
    after this composite in the calling program is pushed into this stack.
    The composite is then executed, by means of the interpreter pointer
    pointing
    to each of its objects.
    When it finishes, an address is popped from the return stack, and
    execution returns
    there. This was the address of the next object in the previous
    program, so
    execution resumes properly. This stack is called the return stack"

    If in the runstream there's the obj_2 composite, it might look as:








    and when execution starts (IP = Interpreter Pointer, CR = CPU
    register, RS = Return Stack):

    ---> executed
    IP points to obj_2 (i.e. obj_2's address is put into the
    CR)

    ---> executed
    IP points to obj_3 (i.e. obj_3's address - next object to
    be executed in the runstream - is put on the *RS*)

    ---> executed
    IP points to obj_2.2 (i.e. obj_2.2's address is put
    into the CR)

    ---> executed
    IP points to obj_2.3 (i.e. obj_2.3's address is put
    into the CR)

    ---> executed
    obj_3's address is popped from the RS

    ---> executed

    Is that right or I messed up things more than they deserve to?

    My fundamental doubt is that it seems to me that the CPU Register (CR)
    and the Return Stack are two different *things*: the former is (?) a
    single mem location, overwritten every time the IP is updated; the
    latter is (?) a proper stack, where runstream pushes or pops
    addresses.
    In other words, if there are no composites in the runstream, there
    would never need of a Return Stack....
    May you please help to get rid of some of the (too many) question
    marks in my (wordy) post?
    Many thanks in advance.
    Best regards.
    Giancarlo


  2. Re: SysRPL Runstream and Return Stack

    On 29 Mar, 09:18, "Giancarlo"
    wrote:
    > Hi group.
    > Here I'm again to ask your help for an "as-full-as-I-can"
    > understanding of the logics of SysRPL...
    > Talking about runstream and return stack, Kalinowski/Dominik's book
    > says,
    > on page 121:
    >
    > "Since the objects are executed in order, it becomes necessary to have
    > some kind of variable that will always point to the next object to be
    > executed.
    > This is called the interpreter pointer, and is stored in a CPU
    > register. After
    > each object is executed, this pointer is advanced to point to the next
    > object."
    >
    > If I understand correctly, it means that if we have the following
    > runstream:
    >
    >
    >
    >
    >
    > then something like this happens (IP = Interpreter Pointer, CR = CPU
    > register):
    >
    > ---> executed
    > IP points to obj_2 (i.e. obj_2's address is put into the
    > CR)
    > ---> executed
    > IP points to obj_3 (i.e. obj_3's address is put into the
    > CR)
    > ---> executed
    >
    > Right?
    > The CPU register used in this case is always the same, i.e. is step
    > after step overwritten? (it would not be a true stack, in that case,
    > but a single mem location...)
    >
    > Now, when at least one of the objects in the runstream is a composite,
    > they say:
    >
    > "When a secondary (or any other composite) is executed, the address of
    > the object
    > after this composite in the calling program is pushed into this stack.
    > The composite is then executed, by means of the interpreter pointer
    > pointing
    > to each of its objects.
    > When it finishes, an address is popped from the return stack, and
    > execution returns
    > there. This was the address of the next object in the previous
    > program, so
    > execution resumes properly. This stack is called the return stack"
    >
    > If in the runstream there's the obj_2 composite, it might look as:
    >
    >
    >
    >
    >
    >
    >
    >
    > and when execution starts (IP = Interpreter Pointer, CR = CPU
    > register, RS = Return Stack):
    >
    > ---> executed
    > IP points to obj_2 (i.e. obj_2's address is put into the
    > CR)
    >
    > ---> executed
    > IP points to obj_3 (i.e. obj_3's address - next object to
    > be executed in the runstream - is put on the *RS*)
    >
    > ---> executed
    > IP points to obj_2.2 (i.e. obj_2.2's address is put
    > into the CR)
    >
    > ---> executed
    > IP points to obj_2.3 (i.e. obj_2.3's address is put
    > into the CR)
    >
    > ---> executed
    > obj_3's address is popped from the RS
    >
    > ---> executed
    >
    > Is that right or I messed up things more than they deserve to?
    >
    > My fundamental doubt is that it seems to me that the CPU Register (CR)
    > and the Return Stack are two different *things*: the former is (?) a
    > single mem location, overwritten every time the IP is updated; the
    > latter is (?) a proper stack, where runstream pushes or pops
    > addresses.
    > In other words, if there are no composites in the runstream, there
    > would never need of a Return Stack....
    > May you please help to get rid of some of the (too many) question
    > marks in my (wordy) post?
    > Many thanks in advance.
    > Best regards.
    > Giancarlo


    All,
    sorry for posting *before* doing a search on comp.sys.group - what an
    unforgivable error
    The search provided *only* several tens of interesting and hopefully
    helpful messages I'm going to read.
    Please feel free to ignore my query.
    Best regards.
    Giancarlo


  3. Re: SysRPL Runstream and Return Stack

    Hi Giancarlo,

    please also take a look into the original RPLMAN.DOC ,
    particulary section [2.2 Mathematical Control]
    up to and including section [2.4.1 EVAL]

    This is pages 2 to 8 .

    The following sections are of interest, too.

    It's all explained there;-)

    HTH

    Raymond


    "Giancarlo" schrieb im Newsbeitrag
    news:1175152724.729478.132800@n76g2000hsh.googlegr oups.com...
    > Hi group.
    > Here I'm again to ask your help for an "as-full-as-I-can"
    > understanding of the logics of SysRPL...
    > Talking about runstream and return stack, Kalinowski/Dominik's book
    > says,
    > on page 121:
    >
    > "Since the objects are executed in order, it becomes necessary to have
    > some kind of variable that will always point to the next object to be
    > executed.
    > This is called the interpreter pointer, and is stored in a CPU
    > register. After
    > each object is executed, this pointer is advanced to point to the next
    > object."
    >
    > If I understand correctly, it means that if we have the following
    > runstream:
    >
    >
    >
    >
    >
    > then something like this happens (IP = Interpreter Pointer, CR = CPU
    > register):
    >
    > ---> executed
    > IP points to obj_2 (i.e. obj_2's address is put into the
    > CR)
    > ---> executed
    > IP points to obj_3 (i.e. obj_3's address is put into the
    > CR)
    > ---> executed
    >
    > Right?
    > The CPU register used in this case is always the same, i.e. is step
    > after step overwritten? (it would not be a true stack, in that case,
    > but a single mem location...)
    >
    > Now, when at least one of the objects in the runstream is a composite,
    > they say:
    >
    > "When a secondary (or any other composite) is executed, the address of
    > the object
    > after this composite in the calling program is pushed into this stack.
    > The composite is then executed, by means of the interpreter pointer
    > pointing
    > to each of its objects.
    > When it finishes, an address is popped from the return stack, and
    > execution returns
    > there. This was the address of the next object in the previous
    > program, so
    > execution resumes properly. This stack is called the return stack"
    >
    > If in the runstream there's the obj_2 composite, it might look as:
    >
    >
    >
    >
    >
    >
    >
    >
    > and when execution starts (IP = Interpreter Pointer, CR = CPU
    > register, RS = Return Stack):
    >
    > ---> executed
    > IP points to obj_2 (i.e. obj_2's address is put into the
    > CR)
    >
    > ---> executed
    > IP points to obj_3 (i.e. obj_3's address - next object to
    > be executed in the runstream - is put on the *RS*)
    >
    > ---> executed
    > IP points to obj_2.2 (i.e. obj_2.2's address is put
    > into the CR)
    >
    > ---> executed
    > IP points to obj_2.3 (i.e. obj_2.3's address is put
    > into the CR)
    >
    > ---> executed
    > obj_3's address is popped from the RS
    >
    > ---> executed
    >
    > Is that right or I messed up things more than they deserve to?
    >
    > My fundamental doubt is that it seems to me that the CPU Register (CR)
    > and the Return Stack are two different *things*: the former is (?) a
    > single mem location, overwritten every time the IP is updated; the
    > latter is (?) a proper stack, where runstream pushes or pops
    > addresses.
    > In other words, if there are no composites in the runstream, there
    > would never need of a Return Stack....
    > May you please help to get rid of some of the (too many) question
    > marks in my (wordy) post?
    > Many thanks in advance.
    > Best regards.
    > Giancarlo
    >




  4. Re: SysRPL Runstream and Return Stack

    On 29 Mar, 13:16, "Raymond Del Tondo" wrote:
    > Hi Giancarlo,
    >
    > please also take a look into the original RPLMAN.DOC ,
    > particulary section [2.2 Mathematical Control]
    > up to and including section [2.4.1 EVAL]
    >
    > This is pages 2 to 8 .
    >
    > The following sections are of interest, too.
    >
    > It's all explained there;-)
    >
    > HTH
    >
    > Raymond
    >
    > "Giancarlo" schrieb im Newsbeitragnews:1175152724.729478.132800@n76g2000h sh.googlegroups.com...
    >
    >
    >
    > > Hi group.
    > > Here I'm again to ask your help for an "as-full-as-I-can"
    > > understanding of the logics of SysRPL...
    > > Talking about runstream and return stack, Kalinowski/Dominik's book
    > > says,
    > > on page 121:

    >
    > > "Since the objects are executed in order, it becomes necessary to have
    > > some kind of variable that will always point to the next object to be
    > > executed.
    > > This is called the interpreter pointer, and is stored in a CPU
    > > register. After
    > > each object is executed, this pointer is advanced to point to the next
    > > object."

    >
    > > If I understand correctly, it means that if we have the following
    > > runstream:

    >
    > >
    > >
    > >

    >
    > > then something like this happens (IP = Interpreter Pointer, CR = CPU
    > > register):

    >
    > > ---> executed
    > > IP points to obj_2 (i.e. obj_2's address is put into the
    > > CR)
    > > ---> executed
    > > IP points to obj_3 (i.e. obj_3's address is put into the
    > > CR)
    > > ---> executed

    >
    > > Right?
    > > The CPU register used in this case is always the same, i.e. is step
    > > after step overwritten? (it would not be a true stack, in that case,
    > > but a single mem location...)

    >
    > > Now, when at least one of the objects in the runstream is a composite,
    > > they say:

    >
    > > "When a secondary (or any other composite) is executed, the address of
    > > the object
    > > after this composite in the calling program is pushed into this stack.
    > > The composite is then executed, by means of the interpreter pointer
    > > pointing
    > > to each of its objects.
    > > When it finishes, an address is popped from the return stack, and
    > > execution returns
    > > there. This was the address of the next object in the previous
    > > program, so
    > > execution resumes properly. This stack is called the return stack"

    >
    > > If in the runstream there's the obj_2 composite, it might look as:

    >
    > >
    > >
    > >
    > >
    > >
    > >

    >
    > > and when execution starts (IP = Interpreter Pointer, CR = CPU
    > > register, RS = Return Stack):

    >
    > > ---> executed
    > > IP points to obj_2 (i.e. obj_2's address is put into the
    > > CR)

    >
    > > ---> executed
    > > IP points to obj_3 (i.e. obj_3's address - next object to
    > > be executed in the runstream - is put on the *RS*)

    >
    > > ---> executed
    > > IP points to obj_2.2 (i.e. obj_2.2's address is put
    > > into the CR)

    >
    > > ---> executed
    > > IP points to obj_2.3 (i.e. obj_2.3's address is put
    > > into the CR)

    >
    > > ---> executed
    > > obj_3's address is popped from the RS

    >
    > > ---> executed

    >
    > > Is that right or I messed up things more than they deserve to?

    >
    > > My fundamental doubt is that it seems to me that the CPU Register (CR)
    > > and the Return Stack are two different *things*: the former is (?) a
    > > single mem location, overwritten every time the IP is updated; the
    > > latter is (?) a proper stack, where runstream pushes or pops
    > > addresses.
    > > In other words, if there are no composites in the runstream, there
    > > would never need of a Return Stack....
    > > May you please help to get rid of some of the (too many) question
    > > marks in my (wordy) post?
    > > Many thanks in advance.
    > > Best regards.
    > > Giancarlo- Nascondi testo tra virgolette -

    >
    > - Mostra testo tra virgolette -


    Hi Raymond,
    thanks for your feedback anyway ;-)

    I found a short and magnificent post by Mika Heiskanen, which
    explained a code snippet and its related data and return stacks:

    ====START QUOTE FROM MH'S POST====

    Data stack: Return stack:
    ::
    { %1 %2 } 1: { %1 %2 } 1:
    >R 1: 1: "%1 %2 }"

    :: 1: 1: "SWAP ;" 2: "%1
    %2 }"
    RSWAP 1: 1: "%1 %2 }" 2:
    "SWAP ;"
    'R 1: %1 1: "%2 }" 2:
    "SWAP ;"
    'R 1: %1 2: %2 1: "}" 2:
    "SWAP ;"
    ; 1: %1 2: %2 1: "SWAP ;"
    SWAP 1: %2 2: %1 1:
    ;

    "%1 %2 }" etc should be interpreted to mean that the return stack
    level
    contains the address of that point in the composite object.
    ====END QUOTE FROM MH'S POST====

    I can almost "see the light" except for one single thing
    (hope my English is not too much poor now...):
    When the first " 'R " command is encountered, it says:
    "Now push onto the data stack the object pointed to by the
    *topmost* pointer in the return stack".
    I guessed the return stack, at that stage, was arranged
    like the following:

    2: "SWAP ;"
    1: "%1 %2 }"

    and thought the *topmost* level was no. 2 (thinking to the
    stack lift you get when entering a data on the data stack)
    Instead *topmost* seems to be interpreted as *the first one (in time)*
    that was pushed onto the stack....

    All in all: the data stack is LIFO and the return stack is FIFO?

    Please clarify this one and I'll see the light (maybe...) :-)
    Thanks in advance.
    Best regards.
    Giancarlo


  5. Re: SysRPL Runstream and Return Stack

    Hi Giancarlo,

    most (if not all) stacks in the HP-48 are LIFO.

    The 'topmost' item is the latest one you put onto the pile,
    and the first you take off the pile.

    The return stacks work in a similar way, of course.
    This makes sense, because you normally want to return
    to the caller of a subroutine.

    There are exceptions, and that's what RDROP, RSKIP
    and their relatives are for.


    There's a pointer location called =DSKTOP ,
    which means 'Data Stack TOP' ;-)
    This pointer points to 'level 1' of the data stack,
    or in other words,
    to (a pointer to) the most recently entered object.

    Best Regards

    Raymond


    "Giancarlo" schrieb im Newsbeitrag
    news:1175176923.646996.79820@n76g2000hsh.googlegro ups.com...
    > On 29 Mar, 13:16, "Raymond Del Tondo" wrote:
    > [..]
    >
    > I can almost "see the light" except for one single thing
    > (hope my English is not too much poor now...):
    > When the first " 'R " command is encountered, it says:
    > "Now push onto the data stack the object pointed to by the
    > *topmost* pointer in the return stack".
    > I guessed the return stack, at that stage, was arranged
    > like the following:
    >
    > 2: "SWAP ;"
    > 1: "%1 %2 }"
    >
    > and thought the *topmost* level was no. 2 (thinking to the
    > stack lift you get when entering a data on the data stack)
    > Instead *topmost* seems to be interpreted as *the first one (in time)*
    > that was pushed onto the stack....
    >
    > All in all: the data stack is LIFO and the return stack is FIFO?
    >
    > Please clarify this one and I'll see the light (maybe...) :-)
    > Thanks in advance.
    > Best regards.
    > Giancarlo
    >




  6. Re: SysRPL Runstream and Return Stack

    On Thu, 29 Mar 2007 02:18:44 -0500, Giancarlo wrote:

    > if there are no composites in the runstream,
    > there would never be need of a Return Stack....


    There are *always* composites in the runstream;
    the topmost level in the entire system is called
    StartupProc, which in turn calls a "System Outer Loop"
    that waits for each keystroke and then acts on it,
    which in turn calls various other system functions
    (each itself a composite), eventually calling
    some program of yours, which is also a composite
    (every "program object" [type 8] is a composite, in fact),
    which in turn contains words calling built-in commands,
    which themselves are composites, etc. etc. etc.

    Just the usual "wheels within wheels,"
    which everyone is always reinventing
    http://www.voteamericavote.com/regis...els_wheel.html

+ Reply to Thread