Can you transition from Spin to assembly in the same cog?

Dennis Ferron

I'm working on a TV driver, and what I'd like to do is precompute all of the timing/counter/video configuration values in Spin, load all the appropriate registers (again, in Spin), and then have the cog running Spin halt and be reloaded with assembly.

The issue is that if I call into my TV object from cog X, and intend to run the assembly TV driver in cog Y, if I am in Spin and set the video configuration registers and counters in Spin, I will not be setting Y's registers; I will be setting X's (from the calling cog).

What I need to do is start a new cog (Y) in Spin which will initialize Y's registers for the TV driver, meanwhile wait in cog X for the Spin code in Y to finish, and then, from X, kill the Spin process in cog Y and reload Y with an assembly language program and restart it from there.

Is this possible/practical? Also, will restarting clear the registers? (If so, then there is no point to going further with the idea.) Currently I am precomputing the values in Spin but storing them in variables passed to the assembly language driver, and the assembly language driver itself moves them from memory into the configuration registers.

Mike Green

You can't do it. Any time a cog is started up, all the control registers are set to zero. Your technique of precomputing the various control values and having the assembly driver load them into the actual registers is the only way you can do it. You can put the precomputed values and the code to transfer them to the actual registers into an area that you'll reuse later for buffers or other storage, but that's all you can do.

Another thing you can do is have an assembly routine that does something, then overlays itself from the hub memory except for a small loop that does the copy of the new code.

potatohead

...or use the in cog buffer area for your init code, to be overwritten once the COG starts doing it's thing. (hat tip to Eric Ball for that one) At least your executable space isn't really wasted with one time ops.

Funny, I'm headed down the same path. Been getting better at assembly math, trying to do the same thing!

ericball

The most efficent way is to store the computed variables as LONGs in the DAT section, and have those LONGs be part of the 496 LONGs which get copied by the COGNEW/COGINIT. Then it's only a small number of MOVs to set the registers. Then those variables and the space used for the MOVs can be re-used for storage.

Question - would COGINIT( COGID, @pasm_start, @longvars ) work?· (Given·that the registers wouldn't be preserved.)


Post Edited (ericball) : 7/9/2007 5:38:40 PM GMT

ericball

Reloading a Spin cog is probably not a good idea.· But there may be some value in doing it in PASM.

  SHL dataptr, #16
  SHL codeptr, #2
cognum  COGID cognum
  OR cognum, codeptr
  OR cognum, dataptr
  COGINIT cognum  NR
codeptr  LONG    ; address of PASM routine 
dataptr  LONG    ; PAR value

Edit: fixed the SHLs to drop the LSBs.

Post Edited (ericball) : 7/24/2007 4:20:53 PM GMT

Mike Green

Actually, reloading a cog that's running Spin is very reasonable. You can start up an assembly program using Spin or assembly and you can start up Spin from Spin. You could start up a new Spin interpreter from assembly, but the initialization information for the Spin interpreter isn't readily available to assembly programs.

ericball

Mike Green said...
Actually, reloading a cog that's running Spin is very reasonable. You can start up an assembly program using Spin or assembly and you can start up Spin from Spin. You could start up a new Spin interpreter from assembly, but the initialization information for the Spin interpreter isn't readily available to assembly programs.

I'm just thinking that COGINIT( COGID, . . . ) could cause issues with parent SpinMethod VAR & other cleanup.· PASM -> PASM wouldn't have this issue.

Mike Green

What kind of cleanup are you concerned about that wouldn't arise just as well in assembly? You can't resume the Spin program that was running. Any VARs that were in use are still there and can be accessed from other cogs. The stack area is not needed once the Spin interpreter is stopped. It could be used for something else if your program is written to do so.