coginit(HUBEXEC_NEW,@blink,0) 'launch hub-exe program in free cog syntax questi
Bob Drury
Posts: 236
in Propeller 2
coginit(HUBEXEC_NEW_PAIR,@blink,0) "HUB_EXEC_NEW" launches next availble cog with PASM code starting @blink . HUBEXEC_NEW_PAIR where does the the second cog start from? I believe the PASM
code is in HUB ram and the program counter is pointing to HUBRAM set by compiler and fetches 32 bit
PASM code in the HUB. I guess what I am trying to do is define what HUBEXEC and COGEXEC means.
Maybe I missed it in the documentation but it seems to be unerstood.
Regards
Bob (WRD)
Comments
Yep, that's correct:
In hubexec, it's still a Cog doing the execution of a program. Just that its instructions are fetched from hubRAM instead of cogRAM. There's no extra hub CPU.
When a single cog is started coginit has the address to run from coginit(HUBEXEC,@PASM1,0) where does the second cog start from with coginit(HUBEXEC_NEW_PAIR,@PASM1,0)?
Regards and Thanks
Bob (WRD)
From the silicon doc (under LUT RAM sharing):
"In order to find and start two adjacent cogs with which this write-sharing scheme can be used, the COGINIT instruction has a
mechanism for finding an even/odd pair and then starting them both with the same parameters. It will be necessary for the
program to differentiate between even and odd cogs and possibly restart one, or both, with the final, intended program."
If I understand,both cogs will then take COGINIT(HUBEXEC_NEW_PAIR,@PASM1,0) will run PASM1 separately using Cog independent program Counters and cog cpu. Would you then have code for the pair looking for odd even COGID then seperate the code action by this? Do you have an example how to do this so I can add this to my notes I am making. I would assume the COGEXEC_NEW_PAIR you would do the same thing. With this overhead is it just as easy to start the second cog with a second COGINIT instruction or are there other benefits (maybe code executes in the exact same instruction cycle)?
Regards and Thanks
Bob (WRD)
The main feature is like free memory allocation. The cogs started are not explicitly requested by ID. Otherwise, yeah, two COGINITs would be just as good.
Startup of the two cogs will be phase difference of one clock tick I'd guess. Because that's the timing an identical block load from hubRAM will enforce through the egg-beater. EDIT: Maybe could also be 1-in-8 chance of being 7 ticks apart too. Again, based on egg-beater. EDIT2: The 1-in-8 chance will be predictable based on modulo'd least three bits of subtraction of the CT count, the load address>>2, and launchee cog ID. Hehe, of course, not knowing the cog ID beforehand makes prediction a little tricky.
The _NEW_PAIR variants are only made to find a pair of cogs that allow LUT sharing. Only cog 0 and 1, or 2 and 3 and so on can share their LUTs for fast data exchange without going over the hubram.
I never used it, so far, but I would guess this code allows to separate the code for the two cogs:
DAT org 0 TwoCogs cogid tmp testb tmp,#0 wc if_c jmp #Second First ... Second ...Andy
Will test out.
Regards and Thanks
Bob (WRD)