Shop OBEX P1 Docs P2 Docs Learn Events
PASM question — Parallax Forums

PASM question

port513port513 Posts: 50
edited 2008-09-27 14:11 in Propeller 1 
entry                   movd    :par,#_dpin             'load input parameters _dpin/_cpin/_locks/_auto
                        mov     x,par
                        add     x,#11*4
                        mov     y,#4
:par                    rdlong  0,x
                        add     :par,dlsb
                        add     x,#4
                        djnz    y,#:par

The above code is from Keyboard.spin

What dows the movd [noparse]:p[/noparse]ar, #_dpin do?
What I'm trying to understand is how the input parameters are sent to PASM code.


/Henke

Comments

  • Mike GreenMike Green Posts: 23,101
    edited 2008-09-25 20:18
    This sets up the RDLONG instruction at : par to copy the input parameters. Since this initialization routine is executed only once, this first MOVD could be eliminated and the RDLONG could be written as ": par RDLONG _dpin,x"
  • port513port513 Posts: 50
    edited 2008-09-25 20:50
    Why isn't [noparse]:p[/noparse]ar (_dpin) increased by #4 as x?
    now they increas by

    add [noparse]:p[/noparse]ar, dlsb why?


    dlsb = 1<<9


    /Henke
  • TimmooreTimmoore Posts: 1,031
    edited 2008-09-25 21:43
    Its increased by 1 since memory inside a cog is indexed by longs. the reason is its 1<<9, is the destination address is stored in the instruction from that bit up. Take a look in the spin/pasm manual at the asm instruction layout and see where the desintiation address is stored. movd writes directly to just eh destination address part of the long.
  • port513port513 Posts: 50
    edited 2008-09-26 18:33
    Timmoore said...
    Its increased by 1 since memory inside a cog is indexed by longs. the reason is its 1<<9, is the destination address is stored in the instruction from that bit up. Take a look in the spin/pasm manual at the asm instruction layout and see where the desintiation address is stored. movd writes directly to just eh destination address part of the long.
    It would be nice if you can tell me what manual I should look in, I can't find anything in Prop Manual 1.1 about that Cog RAM is indexed by longs. The only thing it tells me is that it is 512*32 bits and that Main RAM/ROM is long, word och byte adressable.
    If possible give me an explaination of the adress in Cog RAM and the 1<<9 operation.
    Remember I'm new to Propeller [noparse];)[/noparse]


    /Henke

    Post Edited (port513) : 9/26/2008 7:21:37 PM GMT
  • Mike GreenMike Green Posts: 23,101
    edited 2008-09-26 19:30
    Do you understand the RDLONG instruction? If not, read the description first.

    Cog RAM consists of 32-bit long words and each long has an address (0, 1, ..., 511)

    Hub RAM consists of 8-bit bytes and each byte has an address (0, 1, ..., 32767).
    The bytes can be grouped into 16-bit words and 32-bit long words (longs) on appropriate
    2-byte and 4-byte boundaries. Hub ROM works the same for addresses 32768 to 65535.

    RDLONG transfers a long from a Hub address that's on a 4-byte boundary to a location in
    cog RAM. It ignores the least significant 2 bits of the Hub address.

    The cog address field of the RDLONG instruction is in bits 17-9. There are no index registers
    so, if you want to access successive cog memory locations, you have to change the address
    in the instruction itself. The 1<<9 is used to add a 1 to the destination field of the RDLONG
    instruction.
  • port513port513 Posts: 50
    edited 2008-09-26 19:46
    Shame on me [noparse];)[/noparse]
    I did read the manual but it's Friday night soo·[noparse];)[/noparse]


    /Henke
  • port513port513 Posts: 50
    edited 2008-09-26 20:58
    Where can I read about the effect of instructions such as that rdlong ignore 2 bits in the adress?


    /Henke
  • Paul BakerPaul Baker Posts: 6,351
    edited 2008-09-26 22:52
    The section discussing DAT starting on page 208 talks about the requirement of word values being word aligned and long values being long aligned. While it isn't explict on the 2 least significant bits being set to 0, this is the mechanical interpretation of what is discussed in the DAT section.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Paul Baker
    Propeller Applications Engineer

    Parallax, Inc.
  • port513port513 Posts: 50
    edited 2008-09-27 07:56
    Maybe I'm just to tired right now but in page 208 I fan find this line of code.

    byte word $FFAA, long $BB995511

    And that tells me that this is a byte aligned word sized data and a byte aligned long sized data. So where should I find the requirements of a word sized being word aligned?
    I can't really find the requirements.


    /Henke
  • hippyhippy Posts: 1,981
    edited 2008-09-27 11:27
    byte word $FFAA, long $BB995511

    ( For some reason that's not displaying in my browser within your code-quote )

    I'm not entirely sure where the requirements are stated for word and long alignment but you do have to distinguish between data storage ( where alignment and non-alignment is a matter of your own decision making ) and how such data is accessed using word[noparse]/noparse or long[noparse]/noparse in Spin and using rd/wrword and rd/wrlong in PASM where data should be aligned to suit those commands.

    For such word accesses the lsb is treated as zero, for long accesses two lsb's are treated as zero, so if the data is not correctly aligned what is accessed will likely not be as expected.

    It's not so much that word and long data must be aligned in anyway, but that data should be aligned to meet the expectations of commands which implicitly expect such alignment.

    You could for example align a long however you wanted, but you might not then be able to simply use rdlong to retrieve its value. You could however use four rdbyte commands or (sometimes ) two rdword commands.
  • port513port513 Posts: 50
    edited 2008-09-27 14:11
    hippy said...
    byte word $FFAA, long $BB995511

    ( For some reason that's not displaying in my browser within your code-quote )

    I'm not entirely sure where the requirements are stated for word and long alignment but you do have to distinguish between data storage ( where alignment and non-alignment is a matter of your own decision making ) and how such data is accessed using word[noparse]/noparse or long[noparse]/noparse in Spin and using rd/wrword and rd/wrlong in PASM where data should be aligned to suit those commands.

    For such word accesses the lsb is treated as zero, for long accesses two lsb's are treated as zero, so if the data is not correctly aligned what is accessed will likely not be as expected.

    It's not so much that word and long data must be aligned in anyway, but that data should be aligned to meet the expectations of commands which implicitly expect such alignment.

    You could for example align a long however you wanted, but you might not then be able to simply use rdlong to retrieve its value. You could however use four rdbyte commands or (sometimes ) two rdword commands.
    Thanks!

    Now it's much clearer [noparse];)[/noparse]


    /Henke
Sign In or Register to comment.