Newcomer Questions about Prop operation

demestav · 2009-08-04 09:58

Hello all!

This is my first post here. Let me just tell you, this is one great community! Well done!

I am getting my feet wet with Prop and I have a beginner question.

About processing. I am reading the FullDuplexLibrary. I can see that in the DAT section the processing goes back and forth between the RECEIVE and TRANSMIT part of the code. Now this runs continuously on the cog. What I dont understand is what happens when a PUBlic function is called from another cog. For example what happens when the FullDuplexLibrary.rxflush is called? When will that part of the code be executed?

Thanks!

demestav

Mike Green · 2009-08-04 13:37

The assembly language instructions in a DAT section, as you've noted, execute in a single cog. They're actually copied into the cog during the COGNEW or COGINIT that starts the cog as when the "start" method of FullDuplexSerial is called from some other part of your program, usually initialization. The Spin part of your program is "executed" by the Spin interpreter which is an assembly language program that's copied into a cog from ROM after a reset. This interpreter reads your program from HUB RAM and "executes" it (including the COGNEW used to start FullDuplexSerial in another cog). It's this first cog running the Spin interpreter that eventually executes rxflush at the same time that the assembly routine (in a 2nd cog) is doing receive / transmit.

Just to complicate matters, you can have more than one cog executing a Spin interpreter by using COGNEW to start a new Spin interpreter that has its own stack area and starts with a specific method call (see the chapter in the Manual on COGNEW for details).

Nick Mueller · 2009-08-04 13:58

Let me explain it a bit simpler.

You do have two processors (COGs) running:
#1 is running the SPIN code. This *includes* the functions written in SPIN for the FDS-lib (for example rxflush)
#2 is running the assembler part (in the DAT-section). Most of the time, it sits and waits for work to come.

The rxflush-code (in SPIN) just manipulates a few values (rxhead, rxtail, ... out of my head) that are shared with #2. These values are in HUB-RAM.

The basic principle is to agree upon a communication protocol through some (or one) register in HUB-RAM. There is no way to *directly* influence a COG as soon as it is running. Only by setting flags / shared memory.
All this maybe sounds quite odd, but as soon as you've understood the principle, you will like it.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

RinksCustoms · 2009-08-04 14:16

its my understanding that the asm part gets launced in another cog and monitors/changes variable arrays in the calling object, which would then pass the data back to the main prog. When your main sends an obj.method{parameter(s)} the referenced obj then modifies variables that the asm is monitoring within its loops (or monitoring for a change in just one var to then go scan the others for a change).
ie,. the asm is always testing for a change in at least one variable to break out of the RX/TX loop to do something else. Otherwise, the asm cog would just be stuck in the TX/RX loop indefinitely until that cog was stopped.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Quicker answers in the #propeller chat channel on freenode.net. Don't know squat about IRC? Download Pigin! So easy a caveman could do it...
http://folding.stanford.edu/ - Donating some CPU/GPU downtime just might lead to a cure for cancer! My team stats.

demestav · 2009-08-04 16:31

Thanks all three of you for the detailed answers!!! I think I got the idea!

@Nick Mueller : So as you said, the DAT part is executed continuously on #2 cog and we have access on its memory variables through the #1 cog since they are located on the HUB memory. How do we define that the variables used in the DAT are stored in the HUB memory and not on the cog local memory?

Thanks again...

Mike Green · 2009-08-04 16:53

The variables used in the DAT section that's copied to the cog's memory are kept in the cog. They're just initialized from the DAT section. There are special instructions used to access hub memory from a cog and these are the only way to access hub memory (RDxxxx/WRxxxx). When a cog is started, there's a 14 bit parameter that's passed using the COGNEW instruction. This is normally used as the address (on a long boundary ... hence only 14 bits) of a parameter table used to communicate with the cog.

The above is true for assembly programs. For Spin programs, which are interpreted by a built-in assembly program, all variables are in the shared (HUB) memory. There is no access to the cog's memory (used by the Spin interpreter) except for some special registers (PHSA, FRQA, DIRA, OUTA, etc.)

ericball · 2009-08-04 16:58

demestav said...
Thanks all three of you for the detailed answers!!! I think I got the idea!

@Nick Mueller : So as you said, the DAT part is executed continuously on #2 cog and we have access on its memory variables through the #1 cog since they are located on the HUB memory. How do we define that the variables used in the DAT are stored in the HUB memory and not on the cog local memory?

Thanks again...

HUB RAM is shared by all COGs (whether they be running PASM code or the SPIN interpretter), so the question is really "How to you pass a HUB address to PASM code?"· Once the PASM code has the address, it can read & write the variable.· There are three methods to pass the address:

1. For a single LONG (or array of LONGs), the PAR register is loaded with the second parameter from COGINIT/COGNEW;· i.e. COGNEW( @cogstart, @shvar)
2. The SPIN code may update the PASM code before invoking COGINIT/COGNEW as if it were any other variable; i.e. shvar1addr := @shvar1.· This should not be done if multiple cogs may be updating these PASM variables at the same time since there is only one instance of the PASM code in HUB RAM.
3. As a variation on #1 - the second parameter may be the address of a table of addresses.· i.e. shvaraddr[noparse][[/noparse]0] := @shvar1··COGNEW( @cogstart, @shvaraddr[noparse][[/noparse]0] );

(Note: depending on usage & structure of the shared variables, it may be necessary to also use LOCKs to prevent read/write conflicts.)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum

Nick Mueller · 2009-08-04 17:31

> How do we define that the variables used in the DAT are stored in the HUB memory and not on the cog local memory?

Not wanting to contradict the other answers, but from a less detailed and higher POV:
Basically, you pass a pointer to some structure (your layout) to the COG at the moment you start it. Thats the PAR that is almost always referenced to in the first few lines of any ASM-code.
This pointer (plus offsets by your definition; pointer might also point to an array of pointers, as you want) is *the* key-element when starting any instance of some ASM-code in a COG.
Beware, I'm talking about ASM! SPIN is different.

There are other techniques, but this is the most obvious one. But ... well ... others might contradict.

Nick

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Never use force, just go for a bigger hammer!

The DIY Digital-Readout for mills, lathes etc.:
YADRO

demestav · 2009-08-05 09:05

Those were some really nice answers. Thanks guys; really! I have a much clearer picture now!

It's funny because as I was reading your answers, some other questions popped up in my head by they were finally answered through the rest of the thread.
I think I got some basic understanding of how prop works.

Can't wait to get my hands on a Prop...

Thanks again everyone.

Newcomer Questions about Prop operation

Comments