COGEXEC_NEW_PAIR Qestion Concerning what Debug is displaying
Bob Drury
Posts: 236
in Propeller 2
I am creating confusion for myself !
The following code uses debug with spin2 and PASM. There are a pair of cogs running in addition to the boot spin2 cog=0. Debug looking at symbol addresses and displaying. There are two cogs with the same symbol names running (COGEXEC_NEW_PAIR) COG 2 and COG 3. COG 0 is using spin2 debug dsiplaying the symbol names. Program loads and runs. Which value is debug reading with 2 cogs having the same symbol value? Is COG 0 debug reading HUB RAM only? And debug values for COG 2\3 are reading from their own COG memory?
{{12.3.0.6_Example_WRD_COGEXEC_NewPair_HUB_COG_Values}}
{
SETQ blocksize-1
WRLONG CogValue0,PTRA PTRA=>@cntDelay0
Example
COG MEMORY values (CogValue0 toCogValue4) are to be transferred
to HUB MEMORY (cntDelay0 to cntDelay4). 5 values to transfer so Q is set to 4
}
CON
_clkfreq = 200_000_000
tpin = 56 ' LED on Eval Board
PUB main()
COGINIT(COGEXEC_NEW_PAIR,@blink01,@cntDelay0) 'PTRA set to hubRAM address of cntDelay0
repeat 'processor clock speed
debug(udec(cntDelay0),udec(cntDelay1))
debug(udec(cntDelay2),udec(cntDelay3))
debug(udec(cntDelay4))
debug(udec(CogValue0),udec(CogValue1))
debug(udec(CogValue2),udec(CogValue3))
debug(udec(CogValue4))
waitms(2000)
'------------------------------------------------------------------------------
DAT
ORG 0 'COGEXEC
blink01
DIRH #tpin
mov pa,ptra 'store ptra to show it is not changed
setq #4 'set Q to block size - 1 = 5-1 = 4
wrlong CogValue0, ptra 'transfer from hub to Cog values
Loop
waitLoop1
COGID CogNum
debug(udec(CogNum),udec(ptra))
OUTL #tpin
waitx CogValue0
debug("finnish waitLoop1")
waitLoop2
OUTH #tpin
waitx CogValue4
debug("finnish waitLoop2")
nop
jmp #Loop
CogNum long 0
CogValue0 long 200_000_000 'values stored in COG
CogValue1 long 225_000_000
CogValue2 long 250_000_000
CogValue3 long 275_000_000
CogValue4 long 300_000_000
'------------------------------------------------------------------------------
DAT
ORGH
cntDelay0 long 0 'values stored in HUB
cntDelay1 long 0
cntDelay2 long 0
cntDelay3 long 0
cntDelay4 long 0
Comments
HubRAM variables are singular shared addresses in hubRAM. All cogs accessing that address are seeing the one stored variable.
CogRAM variables are local to that cog. The same address in each cog is a different variable in different cog, like another instance of an object.
Debug handling treats cogs equally. No special treatment for any one cog, but maybe a difference between Spin and Pasm. I haven't used it enough to know.
In the example code there is one factor that hides the nature of the difference between hubram and cogram: the cog pair are loaded with the same data from hubram and then process it identically.
This means that debug will show the same values regardless of which cog is reporting through debug. If the code performed a cogid specific transform on the data then debug would show this difference between them.
Addition:
Because the example code has the cog transfer the cog variables, that were just loaded from hubram by coginit, back to the same location in hubram the code won’t really have any meaningful effect.
If instead the cog code was reading data from hubram, performing a cogid specific transform and then reporting that through debug there would be meaningful results to display. As it stands, this code only avoids corruption of the results in hubram by having both cogs writing the same results to the single buffer.
It appears that spin2 variables and PASM symbol definitions have an overlap. In the following code CogValue[1] can be used as a variable even though it is not defined as a variable in spin2
but is defined under DAT as ORG 0 symbol CogValue. Is there a reason not to do this? Too some extent not having VAR declarations might be cleaner just declare DAT section with Symbol Names.
Regards
Bob (WRD)
CON _clkfreq = 200_000_000 CogNum = 1 VAR long HubCogValue_Address PUB main() COGINIT(HUBEXEC+CogNUM,@hubRDLONG,@HubValue) 'PTRA set to HUB RAM address of @HubValue repeat WAITMS(1000) HubCogValue_Address := @CogValue[1] 'CogValue is symbol address in HUB RAM Debug(udec(HubValue)) Debug(udec(HubCogValue_Address),udec(CogValue[1])) 'Reading HUB RAM Symbol Value CogValue[1] := 22222 '------------------------------------------------------------------------------ DAT ORGH 'run PASM in COGEXEC + CogNum hubRDLONG Loop nop mov CogValue,#0 debug(udec(CogValue)) rdlong CogValue, ptra 'ptra = @HubValue read HUB store in COG1 debug(udec(CogValue)) waitx ##_clkfreq jmp #Loop HubValue long 1234567890 'values stored in HUB RAM HubNextValue long 0 '--------------------------------------------------------------------------------- ORG 0 CogValue long 0 'values stored in COG RAM CogNextValue long 0The DAT section is part of Spin, the primary purpose is to define initialized data for Spin.
PASM ist just one kind of data for Spin, the compiler/assembler helps you to easy generate such PASM data with mnemonics. But for Spin it's nothing than a data section that exists in hub memory.
If you start a new cog in cogexec mode, this data from hubmemory gets loaded into the cogram, and then it's code for the cog CPU.
Symbols that lands in cogram, always have two addresses: The hubram-address inside the DAT section in hub, and the cogram address that it gets when loaded into the cogram.
The difference between variables declared in VAR and DAT sections is: