Shop OBEX P1 Docs P2 Docs Learn Events
Spin memory layout — Parallax Forums

Spin memory layout

I'm working on a byte code interpreter written in PASM but with some Spin code used to interface to things like serial ports, SD cards, LCDs, and keyboards. I'm trying to figure out a good layout for my code and was wondering how a Spin program is laid out in memory. I'm assuming that the main code is loaded into hub memory starting at $0000 but where does the stack start and in what direction does it grow? I'm particular, I'm wondering if I can assume that high memory above the Spin/PASM code and above the Spin stack is available for my use.

Comments

  • RaymanRayman Posts: 14,646
    edited 2018-08-24 10:48
    I think you're right, upper memory is free.
    Except that the main Spin cog has no set stack size and could use all of the remaining memory, if it wanted too...
  • Rayman wrote: »
    I think you're right, upper memory is free.
    Except that the main Spin cog has no set stack size and could use all of the remaining memory, if it wanted too...
    So the stack is placed right after the user's program and grows up towards the top of memory?
  • VAR data is located immediately after the program code in the last object. The stack follows immediately after the VAR data, and yes, the stack grows up towards the top of memory.
  • Dave Hein wrote: »
    VAR data is located immediately after the program code in the last object. The stack follows immediately after the VAR data, and yes, the stack grows up towards the top of memory.
    Perfect. Thanks! I'm sure I knew that at some point but it's been a while since I've done any Spin/PASM programming so I wanted to make sure.

  • Am I running into a problem with @ vs. @@ vs. @@@ here? I seem to be getting the wrong address for @@image. I need the physical hub address.
    OBJ
    
      runtime : "vm_runtime"
    
    CON
    
      _clkmode = XTAL1 + PLL16X
      _clkfreq = 80000000
    
      hub_memory_size = 32 * 1024
      
      vm_mbox_size = runtime#_MBOX_SIZE * 4
      vm_state_size = runtime#_STATE_SIZE * 4
    
      vm_mbox = hub_memory_size - vm_mbox_size
      vm_state = vm_mbox - vm_state_size
      
      vm_stack_size = 1024
      vm_stack = vm_state - vm_stack_size
      
    PUB start
      runtime.init_serial(p_baudrate, p_rxpin, p_txpin)
      runtime.init(vm_mbox, vm_state, vm_stack, vm_stack_size, @@image)
      waitcnt(clkfreq+cnt) ' this is a hack!
      runtime.show_state(vm_state)
      runtime.run(vm_mbox, vm_state)
      repeat
    
    DAT
    
    ' parameters filled in before downloading hub_loader.binary
    p_baudrate          long    115200
    p_rxpin             byte    31
    p_txpin             byte    30
    
    image               file    "advsys2.dat"
    
  • Hmmm... I also seem to be having a trouble with including the at sign in my text. How do I quote it so it doesn't get interpreted as markup?
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2018-08-25 01:26
    David Betz wrote:
    Hmmm... I also seem to be having a trouble with including the at sign in my text. How do I quote it so it doesn't get interpreted as markup?
    Email Jim Ewald <jewald@parallax.com>. This is a long-standing issue. Text enclosed in code blocks needs to be displayed using <pre>, and [noparse] needs to be implemented. I'm promised that this will happen "soon." But another voice can't hurt. :)

    -Phil
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-08-25 01:57
    So the line of interest is
      runtime.init(vm_mbox, vm_state, vm_stack, vm_stack_size, @ @image)
    
    (Note: I inserted a space between the two @ characters so it would display)

    This should be
      runtime.init(vm_mbox, vm_state, vm_stack, vm_stack_size, @image)
    

    The single @ character will get you the address of a variable. The double @ is used to convert an object offset to an absolute address. It adds the address of the beginning of the object to the value after the double @.
  • I need the absolute address. Eventually this gets passed to coginit and is used by PASM code to access the contents of the file "advsys2.dat" in memory.
  • I guess my question is, how do I get the absolute hub address of a DAT symbol using openspin?
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-08-25 02:05
    @image gives you the absolute address of image when used within a method. If you use @image within a DAT section it will give you the offset from the beginning of the object.
  • David BetzDavid Betz Posts: 14,516
    edited 2018-08-25 02:07
    Interesting. I guess I must have some other error in my code then. The single at sign doesn't seem to be giving me the correct address. At least, dereferencing it doesn't give me the contents of the binary file that I included using the file directive in the DAT section. That part of the code looks like this:
    DAT
    
    ' parameters filled in before downloading hub_loader.binary
    p_baudrate          long    115200
    p_rxpin             byte    31
    p_txpin             byte    30
    
    image               file    "advsys2.dat"
    
    So code in a method should be able to get the absolute hub address of "image" using the syntax (at)image. Is that correct?
  • Ah, maybe I see what's going wrong. I think the data in the "image" array is not correctly word aligned because it is preceded by two byte variables. Could that be my problem?
  • Correct, code in a method can use (at)image to get the absolute hub address of a DAT symbol "image". (Code in a DAT section would have to use a more complicated method involving a run-time fixup, unless you're using bstc or fastspin, in which case triple (at) will do the trick.)

    I don't think the "file" directive imposes any particular alignment on the file contents, so if you need it long aligned put an empty "long" in front of it.
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-08-25 02:24
    Yes, your file data is starting at an odd word address due to the two bytes you declared. You need to add a "long" line before the file line to align it on a long boundary.
  • Dave Hein wrote: »
    Yes, your file data is starting at an odd word address due to the two bytes you declared. You need to add a "long" line before the file line to align it on a long boundary.
    Thanks! Now I'm on to another problem...

Sign In or Register to comment.