coginit(HUBEXEC_NEW,@blink,0) 'launch hub-exe program in free cog syntax questi

Comments

• evanh Posts: 15,187

  2021-10-22 22:48

  Yep, that's correct:

  • Hubexec is "execute in place" direct from hubRAM.
  • Cogexec loads a copy of the code from hubRAM into cogRAM then executes from the cogRAM.
• evanh Posts: 15,187

  2021-10-22 22:55 edited 2021-10-22 22:58

  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.
• Bob Drury Posts: 236

  2021-10-22 23:33

  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)
• Ariba Posts: 2,682

  2021-10-23 00:23

  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."
• Bob Drury Posts: 236

  2021-10-23 02:21

  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)
• evanh Posts: 15,187

  2021-10-23 02:57 edited 2021-10-23 03:28

  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.
• Ariba Posts: 2,682

  2021-10-23 07:41

  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
• Bob Drury Posts: 236

  2021-10-23 12:38

  Will test out.
  Regards and Thanks
  Bob (WRD)