Passing multiple parameters to a COG running assembly.

m.r.b. · 2007-08-21 11:32

I am still fairly new to SPIN/PROP. chip.... My background is 10+ years PIC (including 18Fxxxx), 5 years before that Z80 CPU & Z80 core MCU's etc...
So... don't shoot me down in flames etc...

Quick question...

I have started a new COG with an assembly program in it, for speed of execution...
(tranlated SPIN I believe·can only change states of pins at best about 29KHz(ish), because its a translated language!!!)

You can·use PAR to pass ONE parameter register for the ASM program....
I have already managed to pass a single LONG to an ASM program, through PAR!!!

I however want to pass more than one 32 bit register to the ASM program....

If·I have multiple·LONG variables·in my parent object, declared sequentially...

IE:-

VAR
·· long x· 'This is the first thing I want to pass to ASM
·· long y· 'This is the second thing I want to pass to ASM
·· long z· 'This is the last thing I want to pass to asm...

·· long OtherThing 'Nothing to do with the ASM program
·· long SomethingElseAgain

In ASM, could I read like this???· (PAR is @x in ASM 'call'....)

·· rdlong fred,PAR
·· rdlong bert,PAR+1
·· rdlong tim,PAR+2

The silly names are just to get the idea across....

Regards M.R.B.

Graham Stabler · 2007-08-21 12:11

Lesson three shows this:

http://forums.parallax.com/showthread.php?p=647408

your basic idea is correct but the implementation is different

Ale · 2007-08-21 12:14

PAR can contain a pointer to a table of longs, words, bytes whatever you need, and that is passed to asm:

CNT
ptr = 0x7ff0

PUB blabla(..) ..

long[noparse][[/noparse]ptr] := first_val

long[noparse][[/noparse]ptr+4] := second_val

(..)

cognew (@init, ptr)

DAT

init mov tab_ptr,PAR
rdlong val0, tab_ptr
add tab_ptr,#4
rdlong val1, tab_ptr

(..)

that works

have fun

Graham Stabler · 2007-08-21 12:35

They don't have to be a table even, as long as they are defined contiguously they will sit in adjacent memory locations e.g:

VAR

long cog
long pin1
long pin2

if you passed @pin1 it would be addressed as PAR and pin2 would be addressed as PAR+4 (because the address is in bytes)

Graham

ericball · 2007-08-21 12:46

1. PAR is a 14 bit value (see PASM COGINIT in the manual for why).· It's meant to pass a long pointer to HUB memory.
2. don't forget VARs of different sizes will be reordered.
3. If you're passing static data (i.e. stuff which doesn't get updated after the COG is started), there's no reason you can't set the DAT values directly before calling COGNEW.· (Just be aware COGNEW takes time to execute.)

VAR
   long x  'This is the first thing I want to pass to ASM
   long y  'This is the second thing I want to pass to ASM
   long z  'This is the last thing I want to pass to asm...
 
   long OtherThing 'Nothing to do with the ASM program
   long SomethingElseAgain
 
fredptr := @x
bertptr := @y
timptr := @z
 
DAT
 
   rdlong fred,fredptr
   rdlong bert,bertptr
   rdlong tim,timptr
 
fredptr LONG 0
bertptr LONG 0
timptr  LONG 0

Graham Stabler · 2007-08-21 13:29

And further to what Eric said if you know you don't want to change the variables you can actually assign values to the variables used in the assembly code directly before you call coginit and you avoid pointers all together. See lesson one on the same link as above.

Graham

m.r.b. · 2007-08-22 11:20

Thanks... The ASM lessons, and post examples cover what I wanted to know..
The pointer method looks the best way, for what I want to do....
Because ... The values are dynamic (step time delay(s)+step count, for a clock-direction stepper motor driver!!!)

Erik Friesen · 2007-08-22 21:43

Another way I have passed an address to assembly is to pass the par, then load an address to the par location from spin, then read the address from assembly.· I have used this where I have multiple cogs that I want to communicate with in assembly.··Remember that the @symbol·translates the address into a number.· Don't try to @ something twice as I have done.·

Paul Baker · 2007-08-22 22:00

A technique I use for pass by value (a value which needs to be communicated to the assembly program but does not change during the execution of the assembly program) is to declare a variable at the end of the assembly routine, then simply assign it's value in Spin before cognew. Like the following:

PUB go
· var1 := 126
· var2 := -1
· cognew(@asmentry, 0)
· ...

DAT
asmentry ...
...

var1 LONG 0
var2 LONG 0

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

Parallax, Inc.

Fred Hawkins · 2007-08-22 23:11

Paul Baker (Parallax) said...
does not change during the execution of the assembly program

Paul, is there any particular reason that these values·can not be changed in the assembly program? From inside the assembly they would be just another named register, right?

deSilva · 2007-08-22 23:44

Erik Friesen said...
Don't try to @ something twice as I have done.

I shall try to explain this: There are four (!) sorts of @ in SPIN

(1) One is used to find the address-offset of a DAT-Variable as a constant. This is little bit tricky. There is something like a "constant-context" during the SPIN compilation, where all constant expressions are evaluated; this happens most notably in the CON section, but also whenever the directive constant(...) is used, and for all presets or machine language operands in the DAT section.

Notably for the last application address-offsets are very handy (@datname), it can be added to or subtracted from them, and even differences can be stated (@end-@start or constant(@end-@start)); most other operations are more or less dangerous

Note that these are not addresses, but just some numbers to be offset later! The reason is, that during the evaluation of constants the compiler is not yet in the situation to understand where the addressed variables will be allocated to!

(2) The second kind of @ is the adress of DAT variables as such (@datname NOT in a constant context); this number is known by the compiler when generating the code.

(3) The third kind of @ is an address of VAR variables. Why is there a difference? Well you can instantiate more than one object, which will lead to a multiplication of the VAR section, but there will be only ONE code section. Thus the poor code cannot know for which object it will have to work. This has to be computed from case to case dynamically!

(4) the fourth kind of @ is the address of a "local" variable (or a routine parameter). As SPIN routines can be called recursively this is an address in the stack, different from call to call, but independent of the object instantiation.

But this was just the preface, now to the question: Why @@ ?

Well, for the situation (1) - and for this situation only! - this address offset can be converted to a value corresponding to situation (2)

Example:
X := constant(@datvar)
Y := @datvar
Z := @@X

I am confident you will now understand that X < Y and Y == Z

Post Edited (deSilva) : 8/22/2007 11:57:53 PM GMT

Paul Baker · 2007-08-23 00:05

Fred Hawkins said...

Paul Baker (Parallax) said...
does not change during the execution of the assembly program

Paul, is there any particular reason that these values·can not be changed in the assembly program? From inside the assembly they would be just another named register, right?

Correct, they are variables, but once they are loaded into the cog they become disassociated with the copy in hub memory, so any changes made to thier contents is done in cog only. This is akin to what happens when you change the value of a parameter in a C function,·you change only the local copy, not the origination·variable.

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

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 8/23/2007 8:00:43 PM GMT

deSilva · 2007-08-23 00:12

I think Fred was aware of this, as he had read my tutorial

! He just wondered why he should not be allowed to change it locally in the COG; of course he can.

deSilva · 2007-08-23 00:58

Both

It depends from what side you are looking ...

Fred Hawkins · 2007-08-23 03:15

I am staunchly in the assembly camp. Myopically.

mirror · 2007-08-23 04:00

Fred Hawkins said...
I am staunchly in the assembly camp. Myopically.

Myopically? Isn't that Mypokeially?

ericball · 2007-08-24 14:50

Paul Baker (Parallax) said...
does not change during the execution of the assembly program
Fred Hawkins said...
Paul, is there any particular reason that these values·can not be changed in the assembly program? From inside the assembly they would be just another named register, right?

Certainly.· One the DAT variables have been copied from HUB to COG, there is no reason the PASM code can't do as it wishes with that "register".· (Personally, I just think of it as 496 words of RAM, with 16 memory mapped registers.)

The important fact to recognize is once the DAT variable has been copied from HUB to COG, any changes to the HUB version will not be automatically reflected in the COG version.· (And vice-versa.)
·

Passing multiple parameters to a COG running assembly.

Comments