HUBEXEC and DAT Initializing

Bob Drury

In the following code cog 1 is running in HUBEXEC mode.The DAT section is also being used to define symbols for the COG RAM regusters, ORG 0 defines symbol constant CogCntDly0 and CogCntDly1. When retrieving data from Cog 1 using DEBUG symbol address CogCntDly0 and CogCntDly1 the initial cog stored value are random numbers. I believe this to mean that HUBEXEC does not load anything to the COG RAM other than the PC (program counter) to point to some address in the HUB RAM for fetching the first instruction. The compiler must substitue into HUB RAM assembly language the Cog 1 address references for CogCntDly0 and CogCntDly1 based on ORG 0. This would mean that in HUBEXEC mode you cannot use the DAT section to assign any initial values to CogCntDly0 and CogCntDly1 but the assembly symbol address are determined by the Propeller tool compiler. Can someone confirm this?

Regards and Thanks
Bob (WRD)

CON
    _clkfreq = 200_000_000
     CogNum  = 1

PUB main()
    debug(udec(CogCntDly0))
    debug(udec(CogCntDly1))
    COGINIT(HUBEXEC + CogNum,@hubRDBYTE,@HubCntDly) 'PTRA set to hubRAM address of cntDelay
    waitms(5000)
    debug(udec(CogCntDly0)) 
    debug(udec(CogCntDly1))
    repeat 'keep cog running


DAT
            ORGH 'HUBEXEC Ram

hubRDBYTE
            debug("Value before RDBYTE")
            debug(udec(CogCntDly0))
            debug(udec(CogCntDly1))
            rdbyte CogCntDly1, ptra
            debug("Value sfter RDBYTE")
            debug(udec(CogCntDly0))
            debug(udec(CogCntDly1))
loop
            jmp #Loop
'------------------------------------------------------------------------------
HubCntDly    byte    128
'------------------------------------------------------------------------------
            ORG 0
CogCntDly0   long    0
CogCntDly1   long    1234

evanh

Makes sense. I think you've got it all correct. You can call it one of those gotchas.

I can't say I've used hubexec as an explicit new task myself. Compiled code will usually be based in hubexec but that's all cotton-wool'd in the language build environment.

Bob Drury

Thanks for reply. Yes I thought the same thing. Looking at the code you could get the impression that ORG 0 data had a starting values but the values in the cog are completely random.
Regards
Bob (WRD)

Ariba

In HUBEXEC mode the hubram block with the code generated by the assembler, gets not copied to the cogram. So you can not have initialized registers.
If you want that, you can start the cog in COGEXEC mode and jump then to hubexec.

But for sure CogCntDly0/1 are initialized in the hubram image of the code.

Ariba

Here is an example that starts in cogexec and jumps then to hubexec:

pub main()
  coginit(16, @cogcode, @hubcode)
  repeat

DAT
        org     0
cogcode jmp     ptra
Led     long    60
Delay   long    10_000_000
        orgh
hubcode drvnot  Led
        waitx   Delay
        jmp     #hubcode

Rayman

Been a while since this was discussed, but looks like the hubexec way would have a significant speed advantage...

AJL

Hubexec would have an advantage on starting execution, but a disadvantage on execution of anything but straight line code. Branches flush the FIFO which takes time.

Bob Drury

Ariba that code for starting In Cogexec then switching Hubexec to load Data I think is really neat and I am going to add this to the notes.
Thanks and Regards
Bob (WRD)