assembler and spin combination

psavolai · 2006-06-27 09:19

Hi,

having programmed for living for quite a long time Spin looks relatively straightforward to me.

What I am missing is some sort of documentation·of the relationship between Spin and Assembler.

Looking at Chips tv-objects they seem to contain Spin "controller" and some assembler "worker" routines.

1. What are the size limits for such assembler sub routines ?
2. What type of variable exchange happens between those two ?
3. Cog usage ?
4. stack issues ?

5.·any·documentation·on the subject ?

regards,

petri.

cgracey · 2006-06-27 16:41

psavolai said...

Hi,

having programmed for living for quite a long time Spin looks relatively straightforward to me.

What I am missing is some sort of documentation·of the relationship between Spin and Assembler.

Looking at Chips tv-objects they seem to contain Spin "controller" and some assembler "worker" routines.

1. What are the size limits for such assembler sub routines ?
Each COG has 512 longs (32-bits), 496 of which are general-purpose RAM registers which hold the program and data for that COG. So, the maximum COG program size is 496 longs.

2. What type of variable exchange happens between those two ?
At launch time, the COG is passed a long pointer that thereafter appears read-only in the PAR register. This is for passing the address of some structure which might be useful to the COG. Other COGs and Spin programs might reference this same structure.

3. Cog usage ?
When a program runs in a COG, it is completely self-contained. Unless it writes to main memory, affects I/O pins, or affects other COGs' execution, you might never know it was there. It will take 500uA per MIPS, though.

4. stack issues ?
Stack issues only exist for Spin programs. They require some main memory workspace in which to breathe.

5.·any·documentation·on the subject ?
Jeff is writing a huge manual that is almost ready for print.·I imagine that it will be posted within several days. Otherwise, there is a lot to be gleaned from the forums for now.

regards,

petri.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

psavolai · 2006-06-30 08:45

Thanks Chip.

Just to make sure:

1. If I have 3 assembler subprograms under my main spin block
is it the total of those 3 soubroutines that is supposed to be under 496 or is
it just the one which is currently executing ?

2. If my "main" spin block is running in Cog0
is the assembler subroutine swapped in cog0 memory and later on swapped out
when it returns. Basically I'd like to know where the spin
context is kept while my assembler routine is·busy hogging all the 496 longs.

petri.

·

cgracey · 2006-06-30 16:39

psavolai said...
Thanks Chip.

Just to make sure:

1. If I have 3 assembler subprograms under my main spin block
is it the total of those 3 soubroutines that is supposed to be under 496 or is
it just the one which is currently executing ?

Those subroutines are run by launching them into a COG using COGNEW or COGINIT. If they are all part of the same assembly program, this would require one COGNEW and they had better fit in 496 longs. If they are all separate programs, they will each need their own COG and each must fit in 496 longs.

2. If my "main" spin block is running in Cog0
is the assembler subroutine swapped in cog0 memory and later on swapped out
when it returns. Basically I'd like to know where the spin
context is kept while my assembler routine is·busy hogging all the 496 longs.

Your assembly routine would most likely run concurrently with your Spin program (COGNEW). If you wanted to·run your assembly code in the same COG that your Spin program·was running in,·you would use:

COGINIT(COGID, @asmcode, parvalue)

It would not return to your Spin code afterwards, though. It would have to either run until reset, shut itself down, or chain to another assembly program.

petri.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Chip Gracey
Parallax, Inc.

janb · 2006-07-29 23:03

Hi,
I try to get myself oriented a bit more.
Does it mean if I choose to write·even a small section of my algo in assembler, this routine will always require separate cog or at least one can't go back from asm to SPIN code after
COGINIT(COGID, @asmcode, parvalue) is called?
Or on can write a hybrid algo in SPIN & assembler and·the same cog would·execute either SPIN or assembler code, back and forth, ·depending what is calling what?
Thanks
Jan·

parsko · 2006-07-30 08:45

Jan,

If you see pages 339-352 in the manual, they should clear up a bunch (I just read 'em last night, and many things "clicked").

My understanding, you can:

- Only run Spin code in one cog at a time
- Only run Assy code in one cog at a time (it's own cog)
- You can run Assy code in the same cog as spin, but you have to "restart" the cog into the assembly code
- Spin and Assm code must be run separately, aka no mixing code, period

The next logical question would be, if I were to run assm code in the same cog by restarting into the assm code, how long would that take? I think, someone please confirm, that it takes about 400 clocks. So at 80Mhz, you would need 400/80_000_000 = 5us = 0.000_005sec.

I just grasped this yesterday, hence why I write, often you learn by teaching, I hope I haven't written the wrong thing...

-Parsko

janb · 2006-07-30 21:12

thanks,
5 us is fast enough
Jan

Paul Baker · 2006-07-31 17:53

It is possible to restart a SPIN cog if the original SPIN cog was replaced by an assembly cog, but you have to setup a few parameters and point to the SPIN interpreter in memory to get it to work. Unless you really need that additional cog for assembly, it is much much easier to keep the original cog running SPIN.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
...

parsko · 2006-07-31 20:16

Jan,

I think I was mistaken, but I DO remember Chip saying that it was around 400 (actually, the number in my head is 384) clocks to start a new COG. If you view the following post, it says that it takes 103us to start a COG. This does seem to make more sense than 5us. I tried searching, but couldn't find anything else helpfull...

http://forums.parallax.com/forums/default.aspx?f=25&m=132607&g=132773#m132773

-Parsko

Mike Green · 2006-07-31 20:53

When you start an assembly COG, the Propellor copies 496 longs from HUB memory to the COG memory, zeroes the last 16 longs, then starts execution from location zero. Some of the last 16 longs are special purpose and the writing of zeros is effectively ignored (like CNT and PAR). This does take several hundred microseconds to do.

Most assembly programs are designed to be started, then run continuously. They may wait for an I/O pin setting or a particular location in HUB RAM to be changed. Frequently, an assembly routine will have a location in HUB RAM that is a command value. The assembly routine sets it to -1 when it finishes its initialization, then waits for a SPIN program to put something other than a -1 in that location. This may be a starting address and size of a buffer (packed together into one long) or the number of an action to be performed and a HUB address of more control information. The assembly routine does what it's supposed to do, then sets the location to -1 again. This process can be very short. Maximum time to access a HUB location is about 22 clock cycles. Add 3 or 4 instructions at 4 cycles each and you have maybe 40 clock cycles between when the SPIN program signals the assembly routine and when the assembly routine actually starts doing something. This takes well under a microsecond. If the assembly routine is responding to an I/O pin change, we're talking 50-60ns with the waitpeq/waitpne instructions.

pjv · 2006-07-31 23:21

Hi All;

Back in March, I did some launch timing tests, and these were reported on the Propeller Beta Tester's forum.

http://forums.parallax.com/forums/default.aspx?f=24&m=113608

Cheers,

Peter (pjv)

parsko · 2006-08-01 06:39

Peter,

I'm not sure anyone has access to that, only Beta Testers... at least I know I can't (just tried).

-Parsko

pjv · 2006-08-01 15:44

Hello Parsko;

Thanks for letting me know that. Here is a copy of that post.

Now that I know more about the Propeller, I aught to go and check these figures again....... they were pretty early on, and perhaps not optimum. But at least thats what I found then.

Hi All;
 
For those who care.....
 
I've just done some speed tests at 80 MHz:
 
Spin launching an assembler cog takes about 12 uSec.
 
Spin launching a spin cog takes about 225 uSec.
 
Now need to see about assembler launching assembler & spin.
 
 
Post Edit...... Finally got an assembler to launch an assembler, and that procedure takes about 110 uSec
 
Cheers,
 
Peter (pjv)
 
Post Edited (pjv) : 3/7/2006 12:49:42 AM GMT

Cheers,

Peter (pjv)

Mike Green · 2006-08-01 15:58

The 110us sounds right. 512 longs have to be transferred from HUB to COG at an optimal rate (about 5/us at 80MHz) plus some set up time. The SPIN startup time includes that plus the SPIN interpreter initialization time. Another 110us or so seems like a lot. Chip could fill us in on just what it's doing during that time.
Mike

assembler and spin combination

Comments