Shop OBEX P1 Docs P2 Docs Learn Events
Cogarama — Parallax Forums

Cogarama

K2K2 Posts: 693
edited 2010-08-26 08:44 in Propeller 1
After launching seven cogs, is there any way for the SPIN interpreter in cog0 to be replaced with code of my creation?

I'm thinking that if SPIN were stripped down to just the loader code so that one's app could share cog1 with the loader, then cog1 could launch cogs two through seven and then cog0. N'est-ce pas?

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2010-08-25 22:05
    coginit(cogid, @fn, parameter) should do the trick.
  • Heater.Heater. Posts: 21,230
    edited 2010-08-26 00:14
    K2 have a look in the run_zog.spin file of ZOG.

    The idea is that a loader program in PASM is started in Cog 0 using the method kuroneko shows.

    That loader as it is running COG can do whatever it likes with HUB memory. It ends up by starting the zog interpreter in it's own cog. This could be adapted for whatever code you want to run with now Spin remaining in the Prop at all.
  • K2K2 Posts: 693
    edited 2010-08-26 07:05
    This is great! Thank you.

    How big is the loader and how can it finish loading code into the RAM in its own cog without walking over itself?
  • K2K2 Posts: 693
    edited 2010-08-26 07:31
    Just thinking out loud, perhaps the reason there aren't a full 512 longs available is because a few of them are devoted to loader code?
  • Heater.Heater. Posts: 21,230
    edited 2010-08-26 07:32
    K2:
    How big is the loader and how can it finish loading the RAM in its own cog without walking over itself?

    That's the whole point of my post. In run_zog there are a handful of lines of Spin that start up the loader. The loader is written in PASM so it runs entirely within the COG. As a result it could clear all of HUB RAM if it wanted and would still be running independently.

    As it happens that loaders purpose is to move a ZPU bytecode program down to address zero in HUB and then start the ZPU interpreter (Zog) in a cog to run those byte codes. Any Spin code gets trampled on but it's not needed anymore. Basically I run C programs from byte codes using Zog rather than Spin programs from bytecodes using the Spin interpreter.

    Still, the technique can be used to start up whatever you like.
  • K2K2 Posts: 693
    edited 2010-08-26 07:41
    Heater. wrote: »
    That's the whole point of my post. In run_zog there are a handful of lines of Spin that start up the loader. The loader is written in PASM so it runs entirely within the COG. As a result it could clear all of HUB RAM if it wanted and would still be running independently.

    This I understand. You are clearing HUB in order to install your own bytecode that an interpreter of your own creation executes. Clever. But I'm not following how that relates to what kuroneko is illustrating or how your ZOG interpreter installed itself into COG RAM, except that there were COG RAM reserved just for the loader.

    I apologize for being dense. I'm sure you're answering my question...I'm just not connecting the dots.
  • Heater.Heater. Posts: 21,230
    edited 2010-08-26 07:55
    K2, OK

    The original question was:
    "After launching seven cogs, is there any way for the SPIN interpreter in cog0 to be replaced with code of my creation?

    To which kuroneko gave a concise answer. My example of run_zog shows how that has been used in practice. Firstly the Spin interpreter replaces itself in COG with the loader. Then the loader replaces itself in that same COG with the ZPU interpreter.

    (Hmm.. I don't have the code in front of me but I think that actually the original COG 0 Spin part just exits and COG 0 stops so we end up with the new interpreter in COG 1 with all other COGs inactive. That could be easily changed though.)
  • K2K2 Posts: 693
    edited 2010-08-26 08:16
    I think we are getting at the nub of my confusion.

    "First the Spin interpreter replaces itself..."

    "Then the loader replaces itself..."

    How does one replace oneself? How does a COG write over the very memory it is executing out of? It can't unless it is a Magic Shrinking Loader as featured in Alice In Wonderland.

    Since I don't believe in Magic Shrinking Loaders, I conclude that there must either be a reserved part of COG RAM that contains the loader or else there is another tiny controller, which we know nothing about, that operates in the background doing things like transfering machine code to COG RAM when asked.
  • Heater.Heater. Posts: 21,230
    edited 2010-08-26 08:29
    K2:
    How does one replace oneself? How does a COG write over the very memory it is executing out of?

    Ahh, now I see the issue.

    Thing is that when you do a COGNEW or COGINIT in Spin that actually comes down to a COGINIT instruction in PASM inside the interpreter. COGINIT is a single PASM instruction that loads 496 LONGS into COG from HUB and the starts it. All in one go. In this way a COG can uses COGINIT to totally replace itself with whatever other code.

    So yes, there is indeed a "Magic Shrinking Loader". It's all done in hardware in the COGINIT instruction.

    In fact I think you will find the "tiny controller, which we know nothing about" documented in the Propeller manual under the PASM COGINIT instruction. Of course if you don't know what you are looking for it's easy to miss.

    Again, have a look at run_zog, you will see how that works out. There is no loop fetching instructions from HUB to COG, just a single COGINIT instruction and poof it's done.
  • K2K2 Posts: 693
    edited 2010-08-26 08:44
    Fantabulous as usual, Heater. Thank you!

    That is one powerful heap big instruction! It must invoke activate a passel of sequential logic inside the COG cpu.

    I love your poof. There's not enough poof anymore.
Sign In or Register to comment.