Nosy related question - Hewlett Packard

This is a discussion on Nosy related question - Hewlett Packard ; Hello, when using Nosy I often see various object types that I am not sure how to decipher. For example say I put {-} in the stack and execute Nosy I get the CK2&Dispatch followed by a number of possible ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Nosy related question

  1. Nosy related question

    Hello, when using Nosy I often see various object types that I am not
    sure how to decipher. For example say I put {-} in the stack and
    execute Nosy I get the CK2&Dispatch followed by a number of possible
    arguments with their own specific function. Starting at the top is
    2REAL, which simply means two reals and %- is the function. Now,
    where my confusion begins is right below it. Reading 'Programming in
    System RPL' I qoute: "Each type definition is a bint like this:
    #nnnnn. Each n is an hexadecimal number representing the object in one
    position of the stack, according to the table below." Could someone
    point me in a direction of how to get familiar with the other formats
    that don't seem to fit the #nnnnn format? I also notice that under
    the built in BINTS, BINT17 is aka 2REAL. What is #FFFF_, or BINT18
    for example. Any help would be appreciated.

    Jacob

  2. Re: Nosy related question

    On Mon, 27 Oct 2008 21:51:20 -0500, Jacob Wall wrote:

    > Hello, when using Nosy I often see various object types that I am not
    > sure how to decipher. For example say I put {-} in the stack and
    > execute Nosy I get the CK2&Dispatch followed by a number of possible
    > arguments with their own specific function. Starting at the top is
    > 2REAL, which simply means two reals and %- is the function. Now,
    > where my confusion begins is right below it. Reading 'Programming in
    > System RPL' I qoute: "Each type definition is a bint like this:
    > #nnnnn. Each n is an hexadecimal number representing the object in one
    > position of the stack, according to the table below." Could someone
    > point me in a direction of how to get familiar with the other formats
    > that don't seem to fit the #nnnnn format? I also notice that under
    > the built in BINTS, BINT17 is aka 2REAL. What is #FFFF, or BINT18
    > for example. Any help would be appreciated.


    2REAL and BINT17 are symbols, each having the same hex value 00011,
    representing "dispatch value" 1 on stack level 2 and on stack level 1
    (zeros represent either no argument or don't care what type).

    The following table symbolically summarizes the dispatch codes,
    in slightly abbreviated (or cryptic format:

    Object Dispatch Type Codes

    1 % 7 LAM D TAG 4F C%% AF LDT
    2 C% 8 ::; E UNIT 5F L[] BF ACP
    3 $ 9 ALG 0F ROMP 6F CHR CF FON
    4 [] A SYC 1F # 7F COD DF MFO
    5 {} B HXS 2F RRP 8F LIB EF EX4
    6 ID C GRO 3F %% 9F BKP FF INT

    Dispatch code hex "1" is represented above by the SysRPL symbol %,
    used in the syntax of real-number objects,
    so 00011 represents "real on level2, real on level1," thus "2REAL"

    The fact that there are more than 15 object types pretty much
    makes it impossible to represent all types within one
    4-bit hex digit, so what's been done is that hex digit "F"
    has to be combined with a preceding hex digit, to form
    a 2-digit "type" code 0F thru FF for some objects on a single stack level.

    "FFFF" thus represents two type codes, "FF" and "FF"
    which means two "Exact Integer" type objects
    (new to HP49/50 series, did not exist in first HP48 series).

    BINT18 is hex 00012 (real on level 2, complex on level 1).

    Functions which require objects having 2-digit dispatch codes
    generally do not require three of those objects as arguments,
    so a 20-bit "bint" manages to suffice to express all stack argument sets
    (even if it didn't, other individual tests could be made later,
    instead of up front).

    "SYC" represents "Symbolic class" (any of several types),
    as further explained below.

    Except for the existence of new object types in the HP49/50 series,
    original plain text document RPLMAN.DOC, starting on page 63,
    very lucidly explains "Dispatching on Argument Type,"
    including the two-digit codes:

    http://www.hpcalc.org/search.php?query=rplman.doc
    http://www.hpcalc.org/details.php?id=1743
    http://www.hpcalc.org/hp48/docs/programming/rplman.zip

    "Old posts never die, Google just files them away"
    http://groups.google.com/group/comp....04f5719f9c7db3
    http://holyjoe.net/hp/types.png [table by Joe Horn]

    A brief excerpt from RPLMAN.DOC (page 63) follows
    [with slight adjustments]

    -------------------------

    A binary integer typei is nominally encoded as follows:

    #nnnnn
    |||||
    ||||+-- Level 1 argument type
    |||+--- Level 2 argument type
    ||+---- Level 3 argument type
    |+----- Level 4 argument type
    +------ Level 5 argument type

    Each "n" is a hexadecimal digit representing an object type,
    as shown in the table below. Thus #00011 represents two
    real numbers; #000A0 indicates a symbolic class object
    (symb, id, or lam) in level 2 and any type of object in
    level 1. There are also two-digit object type numbers,
    ending in F; use of any of these consequently reduces the
    total number of arguments that can be encoded in a single
    typei integer. For example, #13F4F represents a real number
    in level 3, an extended real in level 2, and an extended
    complex in level 1.

    The following table shows the hex digit values for each
    argument type. The column "# name" shows the object pointer
    name for the corresponding binary integer that may be used
    for a single argument function. The "Binary Integers"
    chapter contains a list of built-in binary integers that may
    be used for various common two-argument combinations.

    Value Argument # name User TYPE
    ----- ---------------- ------ ---------
    0 Any Object any
    1 Real Number real 0
    2 Complex Number cmp 1
    3 Character String str 2
    4 Array arry 3,4
    5 List list 5
    6 Global Name idnt 6
    7 Local Name lam 7
    8 Secondary seco 8
    9 Symbolic symb 9
    A Symbolic Class sym 6,7,9
    B Hex String hxs 10
    C Graphics Object grob 11
    D Tagged Object TAGGED 12
    E Unit Object unitob 13
    0F ROM Pointer 14
    1F Binary Integer 20
    2F Directory 15
    3F Extended Real 21
    4F Extended Complex 22
    5F Linked Array 23
    6F Character 24
    7F Code Object 25
    8F Library 16
    9F Backup 17
    AF Library Data 26
    BF External object1 27 [ACPTR]
    CF External object2 30 [Font in 49/50]
    DF External object3 27 [Minifont in 49/50]
    EF External object4 -- [?? in 49/50]
    FF 28 [Integer in 49/50]

    [End]

  3. Re: Nosy related question

    On Oct 28, 12:16*am, "John H Meyers" wrote:
    > * * * * * *6 * * Global Name * * * * idnt * ** * 6
    > * * * * * *7 * * Local Name * * * * *lam * * * * *7

    [etc]

    Very nice summary of the dispatch functions, John. Too bad we can't
    teleport you back as an editor to when RPLMAN was being written. :-)

    But is there an "either/or" function for level 1? I wrote a program
    that was supposed to work with either a global (type 6) or a secondary
    (type 8). The code I used was:

    CK1NOLASTWD
    DUPTYPEIDNT? (is it a global name?)
    SWAP (tuck result out of the way)
    DUPTYPECOL? (is it a pgm/seco?)
    BINT3
    ROLL (results on levels 1,2)
    OR (OR them)
    ITE (run pgm or error msg)


    If either of the two objects is on level 1, the OR results in a TRUE
    for the ITE command. I couldn't find any more concise way of doing
    this.

    Bill


  4. Re: Nosy related question

    > * ITE * * * * * * * * * * (run pgm or error msg)
    > *
    >
    > If either of the two objects is on level 1, the OR results in a TRUE
    > for the ITE command. *I couldn't find any more concise way of doing
    > this.


    Was it the same bit of code for both that would execute, or different
    bits? If the same, a check and dispatch would be the way to go.

    TW


  5. Re: Nosy related question

    On Tue, 28 Oct 2008 13:46:02 -0500, Bill Markwick wrote:

    > is there an "either/or" function for [any level]


    > [E.g.] either a global (type 6) or a secondary (type 8).


    Aside from built-in "SYC" ("Symbolic class"),
    which is itself a built-in "OR" function,
    and by dispatch code 4 (any kind of array),
    which even includes user types 3 (real array),
    4 (complex array), and new type 29 (symbolic array),
    the answer as given by typical ROM code is:

    (xSTO)
    ::
    CK2&Dispatch
    # 9FD
    FPTR 2 11
    # 8FD
    FPTR 2 11
    BINT13
    FPTR 2 11
    (...)
    # 9F1
    FPTR 2 11
    # 8F1
    FPTR 2 11
    ;

    ( :-)

  6. Re: Nosy related question

    On Oct 28, 5:08*pm, TW wrote:
    > >

    > Was it the same bit of code for both that would execute, or different
    > bits? *If the same, a check and dispatch would be the way to go.
    >
    > TW


    Hi, Tim. It was the same code for both possibilities, but Level 1
    would be one or the other input type depending on the user. How would
    you tell Dispatch to look for one of two types on Level 1? I couldn't
    find a way to do that other than checking for both and doing an OR.

    Bill



  7. Re: Nosy related question

    > Hi, Tim. *It was the same code for both possibilities, but Level 1
    > would be one or the other input type depending on the user. *How would
    > you tell Dispatch to look for one of two types on Level 1? *I couldn't
    > find a way to do that other than checking for both and doing an OR.


    I don't think that is possible as each dispatched bit of code goes to
    a single object. If you have subroutines though like in a library, it
    would work fine like this:

    ::
    CK&DISPATCH0
    idnt
    SUBROUT1
    seco
    SUBROUT1
    ;

    Don't know how much more efficient that is though spacewise.

    TW

  8. Re: Nosy related question

    On Oct 27, 9:16*pm, "John H Meyers" wrote:
    > On Mon, 27 Oct 2008 21:51:20 -0500, Jacob Wall wrote:
    > > Hello, when using Nosy I often see various object types that I am not
    > > sure how to decipher. *For example say I put {-} in the stack and
    > > execute Nosy I get the CK2&Dispatch followed by a number of possible
    > > arguments with their own specific function. *Starting at the top is
    > > 2REAL, which simply means two reals and %- is the function. *Now,
    > > where my confusion begins is right below it. *Reading 'Programming in
    > > System RPL' I qoute: "Each type definition is a bint like this:
    > > #nnnnn. Each n is an hexadecimal number representing the object in one
    > > position of the stack, according to the table below." *Could someone
    > > point me in a direction of how to get familiar with the other formats
    > > that don't seem to fit the #nnnnn format? *I also notice that under
    > > the built in BINTS, BINT17 is aka 2REAL. *What is #FFFF, or BINT18
    > > for example. *Any help would be appreciated.

    >
    > 2REAL and BINT17 are symbols, each having the same hex value 00011,
    > representing "dispatch value" 1 on stack level 2 and on stack level 1
    > (zeros represent either no argument or don't care what type).
    >
    > The following table symbolically summarizes the dispatch codes,
    > in slightly abbreviated (or cryptic format:
    >
    > * Object Dispatch Type Codes
    >
    > 1 % * *7 LAM * *D TAG * *4F C%% * AF LDT
    > 2 C% * 8 ::; * *E UNIT * 5F L[] * BF ACP
    > 3 $ * *9 ALG * 0F ROMP * 6F CHR * CF FON
    > 4 [] * A SYC * 1F # * * *7F COD * DF MFO
    > 5 {} * B HXS * 2F RRP * *8F LIB * EF EX4
    > 6 ID * C GRO * 3F %% * * 9F BKP * FF INT
    >
    > Dispatch code hex "1" is represented above by the SysRPL symbol %,
    > used in the syntax of real-number objects,
    > so 00011 represents "real on level2, real on level1," thus "2REAL"
    >
    > The fact that there are more than 15 object types pretty much
    > makes it impossible to represent all types within one
    > 4-bit hex digit, so what's been done is that hex digit "F"
    > has to be combined with a preceding hex digit, to form
    > a 2-digit "type" code 0F thru FF for some objects on a single stack level..
    >
    > "FFFF" thus represents two type codes, "FF" and "FF"
    > which means two "Exact Integer" type objects
    > (new to HP49/50 series, did not exist in first HP48 series).
    >
    > BINT18 is hex 00012 (real on level 2, complex on level 1).
    >
    > Functions which require objects having 2-digit dispatch codes
    > generally do not require three of those objects as arguments,
    > so a 20-bit "bint" manages to suffice to express all stack argument sets
    > (even if it didn't, other individual tests could be made later,
    > instead of up front).
    >
    > "SYC" represents "Symbolic class" (any of several types),
    > as further explained below.
    >
    > Except for the existence of new object types in the HP49/50 series,
    > original plain text document RPLMAN.DOC, starting on page 63,
    > very lucidly explains "Dispatching on Argument Type,"
    > including the two-digit codes:
    >
    > http://www.hpcalc.org/search.php?que...ing/rplman.zip
    >
    > "Old posts never die, Google just files them away"http://groups.google.com/group/comp.sys.hp48/msg/9604f5719f9c7db3http://holyjoe.net/hp/types.png[table by Joe Horn]
    >
    > A brief excerpt from RPLMAN.DOC (page 63) follows
    > [with slight adjustments]
    >
    > -------------------------
    >
    > A binary integer typei is nominally encoded as follows:
    >
    > * * * * *#nnnnn
    > * * * * * |||||
    > * * * * * ||||+-- Level 1 argument type
    > * * * * * |||+--- Level 2 argument type
    > * * * * * ||+---- Level 3 argument type
    > * * * * * |+----- Level 4 argument type
    > * * * * * +------ Level 5 argument type
    >
    > Each "n" is a hexadecimal digit representing an object type,
    > as shown in the table below. *Thus #00011 represents two
    > real numbers; #000A0 indicates a symbolic class object
    > (symb, id, or lam) in level 2 and any type of object in
    > level 1. *There are also two-digit object type numbers,
    > ending in F; use of any of these consequently reduces the
    > total number of arguments that can be encoded in a single
    > typei integer. *For example, #13F4F represents a real number
    > in level 3, an extended real in level 2, and an extended
    > complex in level 1.
    >
    > The following table shows the hex digit values for each
    > argument type. *The column "# name" shows the object pointer
    > name for the corresponding binary integer that may be used
    > for a single argument function. *The "Binary Integers"
    > chapter contains a list of built-in binary integers that may
    > be used for various common two-argument combinations.
    >
    > * * * * *Value * Argument * * * * * # name * UserTYPE
    > * * * * *----- * ---------------- * ------ * ---------
    > * * * * * *0 * * Any Object * * * * *any
    > * * * * * *1 * * Real Number * * * * real * ** * 0
    > * * * * * *2 * * Complex Number * * *cmp * * * * *1
    > * * * * * *3 * * Character String * *str * * * * *2
    > * * * * * *4 * * Array * * * * * * * arry * * * 3,4
    > * * * * * *5 * * List * * * * * * * *list* * * * 5
    > * * * * * *6 * * Global Name * * * * idnt * ** * 6
    > * * * * * *7 * * Local Name * * * * *lam * * * * *7
    > * * * * * *8 * * Secondary * * * * * seco * * * * 8
    > * * * * * *9 * * Symbolic * * * * * *symb ** * * 9
    > * * * * * *A * * Symbolic Class * * *sym * * *6,7,9
    > * * * * * *B * * Hex String * * * * *hxs * * * * 10
    > * * * * * *C * * Graphics Object * * grob * * **11
    > * * * * * *D * * Tagged Object * * * TAGGED * **12
    > * * * * * *E * * Unit Object * * * * unitob * * *13
    > * * * * * 0F * * ROM Pointer * * * * * * * * * * 14
    > * * * * * 1F * * Binary Integer * * * * * * ** *20
    > * * * * * 2F * * Directory * * * * * * * * * * * 15
    > * * * * * 3F * * Extended Real * * * * * * * * * 21
    > * * * * * 4F * * Extended Complex * * * * * * * *22
    > * * * * * 5F * * Linked Array * * * * * * * * * *23
    > * * * * * 6F * * Character * * * * * * * * * * * 24
    > * * * * * 7F * * Code Object * * * * * * * * * * 25
    > * * * * * 8F * * Library * * * * * * * * * * * * 16
    > * * * * * 9F * * Backup * * * * * * * * ** * * *17
    > * * * * * AF * * Library Data * * * * * * * * * *26
    > * * * * * BF * * External object1 * * * * * * * *27 [ACPTR]
    > * * * * * CF * * External object2 * * * * * * * *30 [Font in 49/50]
    > * * * * * DF * * External object3 * * * * * * * *27 [Minifont in 49/50]
    > * * * * * EF * * External object4 * * * * * * * *-- [?? in 49/50]
    > * * * * * FF * * * * * * * * * * * * * * * * * * 28 [Integer in 49/50]
    >
    > [End]


    Thanks for the excellent explanation John, (and of course BINT17 has a
    hex value of 00011, etc), Let there be Light! Much appreciated.

    Jacob

  9. Re: Nosy related question

    On Oct 28, 9:09*pm, TW wrote:
    > I don't think that is possible as each dispatched bit of code goes to
    > a single object. *If you have subroutines though like in a library, it
    > would work fine like this:
    >
    > ::
    > CK&DISPATCH0
    > *idnt
    > *SUBROUT1
    > *seco
    > *SUBROUT1
    > ;


    Thanks, Tim. That's about what I figured. Even though my following
    code isn't large, it seemed clunky to duplicate it. Looks like the OR
    method isn't so bad. :-)

    Bill

  10. Re: Nosy related question

    On Oct 28, 6:26*pm, "John H Meyers" wrote:
    > the answer as given by typical ROM code is:
    >
    > (xSTO)
    > ::


    Thanks, John. That's what I was finding when I dissected a number of
    commands to see how they handled various objects. Unfortunately, HP
    wasn't farsighted enough to do a built-in OR for what I wanted. :-)

    Bill

+ Reply to Thread