Assembly Woes

bambino

I've made some good head way making an assembly object, but I'm stumbed over how to call in assembly a cognew and pass a PARemeter.

pub main
   cognew(dothis,@dothat)
 
 
dat

dothis   org

         mov  t1,par

         cognew   @@T1

t1       res    1

dothat   org

         something else

I can call assembly from spin just fine and I am handling arrays OK. I would like to now be able to pass a new cog an array from assembly.
Or is that a NO NO. The manuel shows the upper bits of the destination as the parameter but using the double @ with the call I'm getting confused!

CJ

this example uses t2 to hold the address to load, not present in your code assumes t1 and t2 hold 16 bit addresses
t1 with the new PAR
t2 with the address to be loaded

SHL t1, #16 'replace t1 with the register that has the new PAR to be given
SHL t2, #2 'address to start loading from in main ram
OR t1, t2
OR t1, #8 'for cognew bit
COGINIT t1

that is how it comes across to me

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

Post Edited (CJ) : 1/10/2007 2:40:37 PM GMT

bambino

That was quick, Thanks.
So if I understand you right the:

OR t1, #8 'for cognew bit

If set to less than #8 would be a coginit:

OR t1, #3 

For instance would start/restart cog 3?

And the line:

SHL t2, #2 'address to start loading from in main ram
 

Would be what I normally pass with the offset double@?
And obviously the Par is the array!
·

CJ

correct about the coginit

I am not quite sure on the use of @@ though

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Who says you have to have knowledge to use it?

I've killed a fly with my bare mind.

bambino

Thanks again!! I'll try it out when I get home.

bambino

Ok, I managed to get a cog running from another cog, and I am now able to make my questions a little clearer.

In the code I posted below the spin passes the address of the start of the object, the recieving cog adds it to the offset of the address of the cog I wish to start, and it works!

The questions are this: Say I want to pass an array buffer to the cogs.··············The first ones par is tied up with passing the base address. So, knowing how to code the par in the second coginit from assembly isn't going to help me much if I don't know the address. Is this just poor programming or is there a trick here I'm not seeing?

bambino

I think I've got that one figured out now.

By declaring my array in assembly I can get it's address and just set a var in spin equal to it.

The one thing that still puzzles me though,

cognew(@someRoutine,@Parameter,@stackSpace)
"obviously does not fit the syntax for Spin"

·If you call a routine and pass a variable in par, WHERE then is the stack space for the new cog you just called from spin?

Mike Green

Bambino,
If you're starting an assembly routine, you don't need a stack. You only need "cognew(@someRoutine,@parameter)"

bambino

Thanks Mike,
I can stop chaseing my tale about that now.
I'm going to try declaring my array in assembly and see if I can't get up to speed with Three cogs. So far my SPI is blazing with two cogs, I'm hopeing to do some data validation in a third without slowing the first two down.

Paul Baker

You know how to "dereference" the pointer? Left shift the array index of the element you want to access by the data size (no shift for byte, lsh by 1 for word, lsh by 2 for long) add it to the base address and the result is the address of the element you want to access.

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

Parallax, Inc.

bambino

Thanks Paul,

Actually No. I've been more interested in just getting a few things to work using longs. No doubt I'm wasting a lot of ram at this point as my data is only 12 bits(from a max 1270 converter), The application will not need much program space as it is a data in, data out type application. So longs are fine for now.· I do intend to practice that, I just wanted to get a working app together as quick as I could to make sure my hardware was going to support it, then build a demo and optimize the code from there.

Plus speed is a concern, so processing longs is keeping my up to par with the sample rate of the converter. I thought maybe latter I would use the upper word to keep cnt difference information to keep track of any jitters in my sample rate, but waste is OK for now.