Restarting stopped COGS (Power save mode?)

ozpropdevozpropdev Posts: 2,425
edited 2016-12-09 - 22:30:00 in Propeller 2
With all the discussion on COG allocation etc. across on the LUT share thread I thought I would bring up another cog allocation scenario to add to the mix.

When the start address S[19:0] of COGINIT is <$200 and D[5]=1 the cog can be restarted with the code already resident in COGRAM.
This works great as long as your aware that a restart also resets DIRx bits.

This demo code starts a cog, waits 4 secs then stops it. 4 secs later restarts it in a different location.
	sys_clk = 80_000_000
	selected_cog = 5

dat		org
		loc	ptra,#@mycode
		coginit	#selected_cog,ptra		'start cog
		waitx	##sys_clk * 4
		cogstop	#selected_cog			'pause cog
		waitx	##sys_clk * 4
		coginit	#32+selected_cog,#restart	'restart cog at different cogram address
here		jmp	#here	

'==== code to stop/start =========

		orgh	$400
		org
mycode		setb	dirb,#0
		setb	dirb,#2		'<< lost on restart
.loop		notb	outb,#0
		waitx	##sys_clk >> 4	'fast flash
		jmp	#.loop

restart		setb	dirb,#2		'*** restore port direction bit
.loop2		waitx	##sys_clk >> 1	'slow flash
		notb	outb,#2
		jmp	#.loop2


Melbourne, Australia

Comments

  • While I had thought about the two normal scenarios, restarting an existing cog with new code, and placing an existing cog in a loop waiting on a hub mailbox, I forgot about the restart without reloading. This is quick and was intended to have a helper cog do a simple chosen routine and shutdown waiting to do another.

    Thanks for the reminder.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 13,059
    Cluso99 wrote: »
    While I had thought about the two normal scenarios, restarting an existing cog with new code, and placing an existing cog in a loop waiting on a hub mailbox, I forgot about the restart without reloading..

    Will COGSTOP be lower power, than WAITX ?

  • jmg wrote: »
    Cluso99 wrote: »
    While I had thought about the two normal scenarios, restarting an existing cog with new code, and placing an existing cog in a loop waiting on a hub mailbox, I forgot about the restart without reloading..

    Will COGSTOP be lower power, than WAITX ?

    COGSTOP stops all toggling within a cog.
  • jmgjmg Posts: 13,059
    cgracey wrote: »
    jmg wrote: »
    Cluso99 wrote: »
    While I had thought about the two normal scenarios, restarting an existing cog with new code, and placing an existing cog in a loop waiting on a hub mailbox, I forgot about the restart without reloading..

    Will COGSTOP be lower power, than WAITX ?

    COGSTOP stops all toggling within a cog.

    So what is the predicted difference in power, between a WAIT and a COGSTOP COG ?

  • jmg wrote: »
    cgracey wrote: »
    jmg wrote: »
    Cluso99 wrote: »
    While I had thought about the two normal scenarios, restarting an existing cog with new code, and placing an existing cog in a loop waiting on a hub mailbox, I forgot about the restart without reloading..

    Will COGSTOP be lower power, than WAITX ?

    COGSTOP stops all toggling within a cog.

    So what is the predicted difference in power, between a WAIT and a COGSTOP COG ?

    There will be much less toggling during a WAIT than occurs during running. The streamer may still be running, but the cog ALU is pretty much suspended, waiting for the WAIT to end.
  • ElectrodudeElectrodude Posts: 1,266
    edited 2016-05-18 - 15:15:33
    Could you add a third stopped-but-allocated state to cogs? The cog would be stopped, but COGNEW wouldn't ever allocate it. This could be used for pausing cogs. But, probably more importantly, if you add an instruction to start two adjacent cogs to facilitate LUT sharing, it would start the first cog and put the second in stopped-but-allocated mode, so the first cog can do coginit(cogid + 1) to start the second cog but so another cog can't steal the second cog in the mean time.
  • jmgjmg Posts: 13,059
    edited 2016-05-19 - 22:20:20
    Could you add a third stopped-but-allocated state to cogs? The cog would be stopped, but COGNEW wouldn't ever allocate it. This could be used for pausing cogs.

    But, probably more importantly, if you add an instruction to start two adjacent cogs to facilitate LUT sharing, it would start the first cog and put the second in stopped-but-allocated mode, so the first cog can do coginit(cogid + 1) to start the second cog but so another cog can't steal the second cog in the mean time.

    Very good points!

    I've proposed a COGFRZ state to cover this, in the other thread.
    Probably better covered here.

Sign In or Register to comment.