[resolved][puzzle] Identify yourself!
kuroneko
Posts: 3,623
It's Friday the 13th and for some unexplained reason the cogid instruction stopped working. However, you urgently need this information, i.e. your cog's ID. All you know is:
Clarification: startup context
Post Edited (kuroneko) : 12/25/2009 2:01:11 PM GMT
- At least one and at most four other cogs are running, doing stuff.
- You are not allowed to disturb them or interfere with their operation.
- PASM: par points to private scratch space, size 64 longs
Clarification: startup context
- you wake up at location $000 in PASM district
- Who are you?
Post Edited (kuroneko) : 12/25/2009 2:01:11 PM GMT
Comments
If every cog wants its ID, they share the information on a stack in hub ram, so they can figure out which cogs had to wait
more or less, and there will be a tendency for the stack to get reports from cogs in order. Just a guess. It involves counters
or watching what other cogs are doing in the hub or some other global resource, relative to cog0, and cogself, methinks.
There is timing, hub order, and global resources, and cog0, at least, to try to use to get ID, if that is how it is defined.
edit:Hmmm. Did I break the rules of the game? I don't think so because a cog wouldn't expect a cogID failure, so it wouldn't
be programmed to try something else. I assume someone has a broken Propeller and needs to use it anyway, and programmed
to compensate. I would be very surprised if there is a way to handle an unanticipated failure like this one in runtime.
Post Edited (VIRAND) : 12/17/2009 9:50:55 AM GMT
@Andrey: Yes, that is the basic idea. Although I'm not quite sure why you'd want to wait at all. Just do a hub op and record cnt. You always return from it at 16n+m. All you need is m. And yes, one free cog is enough and certainly less than 64 longs are required. But that would have been telling. It gets more tricky - if not impossible - when all 7 remaining cogs are in use.
@VIRAND: This puzzle is not to be taken too seriously. Regardless, you can't make assumptions about existing cog IDs as reference. For all you know you could be cog 0. Getting the reference point was the challenge.
Post Edited (kuroneko) : 12/17/2009 10:41:17 AM GMT
Post Edited (kuroneko) : 12/17/2009 2:25:07 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
I'm not an expert on the Propeller YET. I assumed that the Propeller always boots an initial instance of Spin in Cog0. No?
- you wake up at location $000 in PASM district
- Who are you?
It doesn't matter. The whole thing is a thought experiment. You don't get to chose startup conditions. All you know is that your code is invoked with par pointing at long storage[noparse][[/noparse]64].Probably dumb questions, and I'm sure the answer is in the manual somewhere, but I'm at work at the moment, so here goes ...
What is a cog that has not been explicitly started actually doing, and is there any way to tell (from another cog) that it is in this state?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
So I guess that means as far as other cogs are concerned, it doesn't exist. Even with a particular cog running, unless it wants to talk to you you have no way of telling unless you know that it's doing something specific at a certain time ... and even that might be hard to observe.
What are you after?
Thanks for that. I'd really like an instruction (or small piece of code) that could tell me the state of a cog - it would make dynamic allocation of cogs a bit easier - i.e. when a cog has finished it simply stops itself, and then the system can detect that and re-use the cog for something else. At the moment, I think I'd have to be able to poll the cog, or or have the cog set a flag when it's finished.
Just starting to think about a possible new Catalina-compatible Prop OS (codename "Catalyst").
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
" * you wake up at location $000 in PASM district
* Who are you?"
lol - sounds like a bad night... or a good one depending on your particular preference.
You did say that it was Friday the 13th though.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 12/18/2009 3:17:41 AM GMT
In OS environment, the best would be to assume that tasks/programs do not use COGINIT/COGSTOP, but call OS services for such things.
I'd be interested in seeing any such code you know of. The problem with imposing a 'procedural' solution is that sometimes users will want to run existing SPIN programs that don't abide by the procedures.
Of course, I understand that any information you get will only be aproximate - but it would still be handy to be able find out (aproximately) how many cogs an 'unknown' program (i.e. one for which you have only a binary file) actually uses.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
Post Edited (kuroneko) : 12/25/2009 5:55:08 AM GMT
Yes, that should work. Thanks.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina