Random question: why is COGID a hubop?
ags
Posts: 386
Long stream of consciousness led me to this as I am updating another thread. Understanding that there really is just one HUBOP instruction (one opcode for all 8 hub operations, with the assembler kindly providing "aliases" that set the correct src value for each of the 8 options) - why is COGID a hubop at all? Each cog is a unique physical core - why does the hub need to be involved in returning the three-bit value that is unique to each cog?
Just wondering.
Just wondering.
Comments
It may also be that this would be such a different operation compared to all other instructions that it would take a lot of other changes to support. But it seems possible theoretically, and I would guess there is a very good reason for it.
The speed of COGID is not that important, and you can execute it once after cog start and hold the ID in a register.
You can also use COGID to synchronize the code to the hubslots of the cog, without modifying anything in hubmemory,locks or other cogs.
Andy
How do you know who you are without asking everyone else?
We are not born with our names or social security numbers or whatever engraved in our souls.
Why should a COG be different?
Just wanted you to know that I nearly snarfed my water while reading your reply. Please include snarf warnings in the future!
This could be the best Heaterism ever!!
Another perspective is that every one of us knows our name innately. It roughly translates to "me". There is only an issue when we have to interact with others. Then we have to publish and agree on them. Same thing here. Devices all innately known their MAC address; they must be assigned an IP address.
Is this real, or am I once again imagining things?
Be wary of MAC addresses... very easy to clone in Linux and to travel under a false flag.
@Chris, As an English guy with little understanding of American I can only try to guess what that means:
Did you pee your pants?
Did you choke on your mineral water?
Google translate is not helping here. Seems like an over-reaction to a slightly sideways look at things anyway.
@mindrobots. I did not know there were such things. I'll try to live up to them in future:)
@ags, Did I say this was philosophical? In the absence of anyone else why would I think of having a name? There is no need for one. I might not even realize that there is a "me". Exactly. I know what you mean. But not me, my "MAC address" was strapped to my wrist in the maternity ward. Similarly in the computer world MAC addresses belong to external things like network cards, they are assigned by an external authority, and thank God I can change them if I want.
But google finds everything:
http://en.wiktionary.org/wiki/snarf -> To expel fluid or food through the mouth or nostrils accidentally, usually while attempting to stifle laughter with one's mouth full.
[golf clap]
It's hard work. I only got as far boring stuff like:
snarf - To eat or drink rapidly or eagerly; devour:
snarf - to acquire for onesself, with little concern for social norms, but not quite by stealing.
@photomanks Ouch, there is another one. A phrase with so many meanings...
Would [soccer hooligan head butt] fit better??
Why do we ever need to know or care about the ID of a COG that is doing work for us?
Like slaves back in the day we don't care which one does the job as long as it gets done.
On the other hand why does a COG ever need to know it's ID.
It only has to do what it has been told and keep quite otherwise.
And so, who cares how long it takes a COG to find it's ID? They never should do that.
That's not fair! Should I write something bavarian. ;-)
I love it! Google found me a Glaswegian dictionary!!
This is what I'm thinking. I suppose there could be corner cases where how close a cog is to the IO lines might be at issue and I'm certainly not proficient enough to be delving into it to that level anyway but the cog can't launch itself anyway so I can't even see why it needs to know that then. The rest of the time what cog is actually doing the work is irrelevant. The only thing I have ever really needed is of course the supervisor program to know which cog to stop if loading and unloading dynamically. I can see no need to dedicate silicon to it or make it lightning fast even in a case where knowing it proved necessary.
Golf Clap in this scenario is a 'well played sir'.
That's how I'm looking at it.
So the question is not "Why is cogid a slow hubop?" But rather "Why is there a cogid instruction at all?"
That opcode space could perhaps have been used for something useful.
What are we missing here?
Yes, and I understood. I did not think it necessary to restate.
So let me not be so vague, and back to the (technical) question. The cogid instruction exists. Its behavior is that it will provide a cog with it's unique ID. I agree that I see no criticality regarding the speed of this operation in any use I can think of (but I don't think of everything). No cog can determine another cog's ID through a single instruction. So if a cog can only ask its own ID, why involve the hub?
A better analogy than MAC/IP address could be DNA: a "creator" (please, let's not let this thread wander there philosophically) - let's arbitrarily assign a name to this non-deity, something like... "Chip" - could create a bunch of entities that are all exact clones. Only Chip could tell them apart. That appears to be what has happened. Every time one of the creations is curious about its name, it has to ask Chip. Doesn't Chip have other things to better spend his time with? An alternative is to make each creation just the slightest bit different, just enough so that its DNA is not 100% identical to any other. Chip can decide what that difference is, and make sure that he doesn't allow any two DNA sequences to be identical. He could even do so in such a way there was an order to the difference. Then, if for some reason (whether good or bad reason - it's about the instruction existing, not its utility) if any one of the creations want to know its name, it can just look. Chip can continue doing other more important things.
Presuming that Chip is an intelligent and thoughtful creator, I am wondering if anyone can elaborate on why Chip decided on the former strategy (or could disabuse me of an incorrect presumption). Maybe it was because final verification, or just handling the mask data, was made easier by having 8 exact instances (although I doubt there wasn't some cover cell over the entire chip which could have supported this). Maybe the idea of a cogid wasn't originally planned, and it was easier to modify the hub to provide this rather than the cog processors. Maybe the connections from hub to cog are not direct but switched, and it has to have an address to communicate (doubtful). I can only guess, and wonder what the real reason is.
Since some of the other COGxxx instructions clearly use the hub mechanism, it makes sense to group things like COGID with them rather than separating it out.
Also, I do use cogid for exactly the (bootloaderj) scenario Mike Green offers. I absolutely need to uniquely identify cog instances.
It's not about if the cogid instruction should exist, or be used, or be fast. I am only asking why was it made a hub operation.
Thank goodness you turned up. The voice of reason.
Actually, now that you mention it, I think I have even used COGID in a ZOG loader so that a cog can commit suicide after starting up whatever it was loading.