Passing Assembly Parameters From Spin Vars vs Spin Stack... Dangerous???

pjv

Hi All;

I am still learning Spin, and am looking for some advice from the experts here.

I have just discovered that I can pass temporary parameters to my assembly programs directly from local variables (par-referenced) in a Spin method, instead of needing to first have the Spin method place the values in (par-referenced) Spin Vars.

These parameters are just PASM initialization values, and are stored there once they are transferred, and are no longer required by Spin.

Is this legitimate, or is that fraught with danger as presumably in the direct approach they come from the Spin method stack.

This approach cleans up my Spin code as well as simplifies my PASM code.

Advice please ??

Cheers,

Peter (pjv)

Heater.

In Spin both method parameters and local variables are kept on the stack. They effectively don't exist after the method has returned. The stack space they occupied can be over written by subsequent method calls.

So we see there is no problem passing method parameters and locals to pasm running on other cogs as long as you can be sure the other cog has read/written them before the method returns.

You might want to look at the F32 floating point object in OBEX as an example of doing exactly that.

JonnyMac

There's no need to make copies of parameters if you're not using them in the interface code. If the PASM code needs to "talk" back to Spin you may want to put the address of your first parameter into your "mailbox" variable and then pass the address of that to the PASM cog.

var

  long  cog
  
  long  mailbox
  long  mbparm


pub start(parm1, parm2, parm3)

  stop
  
  mailbox := @parm1
  cog := cognew(@entry, @mailbox)

  repeat while (mailbox)
  
  return cog

(Edit) If there's a concern about the PASM access to values that are on the stack your start() method could always wait on some signal from the PASM cog before exiting.

pjv

Hello;

@ Heater; Thanks for the confirmation.

@ Jonny; What I'm doing in PASM is really quite complicated. I don't use the conventional "start" or "stop" methods. The (desired) cogs get launched, and never stop, and, as you suggest, use mailboxes to communicate back and forth to Spin.


I have multiple assembler programs running in each cog, and Spin needs to be able to communicate with each of those threads very quickly, and does so through a window that appears every1 usec. So my concern was that the parameters passed from Spin through the mailbox (perhaps a dozen or so longs) would not be corrupted while they were being read from the stack of the Spin method.

Prior to this "revelation" I would first store the parameters in Spin VARS, and passing that address through the mailbox. Its simpler, shorter and faster to now find that they can be passed directly from the stack/local method variables.

Many thanks.

(Edit) Jonny, I have exactly that, a signal from each thread of every multi-threading cog to optionally "freeze" the method until it is permitted by the cog to continue.

Cheers,

Peter (pjv)

msrobots

Stumbled over this and wonder how this will work with Spin2 having the stack in the cog.

Kye is using this in his Fat_Engine a lot and I got used to it also.

But without the stack in Hub all parameters passed to pasm will need (permanent?) assigned Hub-ram.

Any thoughts?

Enjoy!

Mike