Spin memory layout

David Betz · 2018-08-24 10:45

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.

Rayman · 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...

David Betz · 2018-08-24 10:51

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?

Dave Hein · 2018-08-24 11:58

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.

David Betz · 2018-08-24 12:00

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.

David Betz · 2018-08-25 00:58

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"

David Betz · 2018-08-25 00:59

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) · 2018-08-25 01:25

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 Hein · 2018-08-25 01:55

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 @.

David Betz · 2018-08-25 01:57

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.

David Betz · 2018-08-25 02:01

I guess my question is, how do I get the absolute hub address of a DAT symbol using openspin?

Dave Hein · 2018-08-25 02:03

@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 Betz · 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?

David Betz · 2018-08-25 02:08

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?

ersmith · 2018-08-25 02:13

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 Hein · 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.

David Betz · 2018-08-25 02:29

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...

Spin memory layout

Comments