Whatever it could be, I didn't yet had learned before, on the subject of written English, was suddenly injected in my mind, in the last hour or so.
Improvements at blinking eyes pace!
And the best part of it: there are no pals, trying to kill each other, simply by reading something about changes on the round robin scheme.
Yanomani
I think the controversy was bypassed when someone realized that each cog can keep its own slot, but when the slot is not used, someone else can have it - and this new behavior can be enabled - it's not automatic. So, standard round-robin access was not compromised. The secret sauce was not adulterated.
Looks good - but I wonder if instead of the eight 3 bit fields another eight bits might not suffice?
ie lowest 8 bits = slots current cog can use
next lowest 8 bits = slots of cogs that can "steal" this cogs slot.
I am wondering if using relative cog indications will be difficult to document
maybe it would be easier if COGID returned a cog bit mask instead ... ie %00000001 ... %10000000, a return of %00000000 would mean could not allocate cog
then the cog references could be an absolute bit mask, allowing easier planning?
other cog | this cog
can use | claims
76543210|76543210 cog id
11111111|00000001 cog 1 says any cog can use its slot
I like the bit mask, too, but it doesn't offer any prioritization.
And, yes, eight 3-bit fields of relative cog numbers would be a pain to set up. Like in SETTASK, as soon as %000 was found in the offer order, that would mean anybody.
Hey, maybe the 8-bit offer mask could be the top-priority, with everyone else being implied lower-priority. I think a single level of priority is all that is needed. Those not in the priority mask are flying stand-by.
The forum sw blocks me from quoting when there is a percent sign embedded. I sit just my PC/IE10?
re Chips post #3115 & others.
I had thought that a cog could make its slot available to another specific cog, or the pool, when not required. But this makes existing drivers unfriendly to give up their unused slots.
That is why I would think it better for a high priority cog to claim slots as low or high priority. If another cog claims the relevant slot as a priority, it now gets it. Tough luck - the programmer/sw just needs to handle this case.
So I see each cog as enabling its ability to access other cogs free slots, and if it does so, then it can claim some of those as "I am highest priority". Its quite simple and basic.
Only 1 cog will have priority, otherwise it is shared on a round-robbin basis from the cog# of the free slot.
I don't really see the requirement for a cog to be able to yield its slot to another cog as priority. But if you think that's a good idea, then its another option.
"000000 just don't try to execute a hub instruction after setting this value - you'll hang."
C.W.
Yes! I agreed with you, then saw Chip's post and realized it was already covered, meaning the original intent was the right intent, and that our side discussion really was just that.
I didn't like, "if you do this, it will hang", but that's precisely what it should do. There is assembly language for you.
I like the bit mask, too, but it doesn't offer any prioritization.
And, yes, eight 3-bit fields of relative cog numbers would be a pain to set up. Like in SETTASK, as soon as %000 was found in the offer order, that would mean anybody.
Hey, maybe the 8-bit offer mask could be the top-priority, with everyone else being implied lower-priority. I think a single level of priority is all that is needed. Those not in the priority mask are flying stand-by.
We need some short-cut around the eight 3-bit fields, or some simple formula that is robust.
How about make the values absolute instead of relative in both the mask and bitfields?
It's going to take knowledge of what is loaded where anyway.
That is what I was going to say. I don't think there is a formula without simplifying the model.
We need a query instruction so that COGS can read the state of the HUB and potentially change behavior. Absolute bit fields will help sort this kind of thing out. And that all means people will need to just run specific COGS to have this all work for them, or leave the "slot offered" mode turned off.
I like this. Was quite a shock for me. IMHO, priorities get complex. This way, the developer can plan and IMHO, should plan it all out.
When a COG is waiting for the HUB I assume a flag is set. PENDING = TRUE
When a HUB slot appears that is PENDING = FALSE, use it instead of waiting for the required slot.
If COGS aren't used there automatically FREE slots for the other COGS.
If all COGS are trying to access HIUB at the same time, normal default slots apply.
This seems simple and automatic, or have I missed something?
When a COG is waiting for the HUB I assume a flag is set. PENDING = TRUE
When a HUB slot appears that is PENDING = FALSE, use it instead of waiting for the required slot.
If COGS aren't used there automatically FREE slots for the other COGS.
If all COGS are trying to access HIUB at the same time, normal default slots apply.
This seems simple and automatic, or have I missed something?
I think the goal is to have a way to make it deterministic if needed.
When a COG is waiting for the HUB I assume a flag is set. PENDING = TRUE
When a HUB slot appears that is PENDING = FALSE, use it instead of waiting for the required slot.
If COGS aren't used there automatically FREE slots for the other COGS.
If all COGS are trying to access HIUB at the same time, normal default slots apply.
This seems simple and automatic, or have I missed something?
We have to maintain the existing 1:8 structure for deterministic code that may be bitbanging, etc. So we have to default back to the way it was.
But, rather than just allocate the free slots on a first come basis, we want to be able to allocate it in at least a small priority, so that we can know that it will get at least a certain number of slots in 8, provided we control the cog(s) that must not use all their slots. This is the raw basics anyway.
That is what I was going to say. I don't think there is a formula without simplifying the model.
We need a query instruction so that COGS can read the state of the HUB and potentially change behavior. Absolute bit fields will help sort this kind of thing out. And that all means people will need to just run specific COGS to have this all work for them, or leave the "slot offered" mode turned off.
I like this. Was quite a shock for me. IMHO, priorities get complex. This way, the developer can plan and IMHO, should plan it all out.
I think that if we had alterable priorities in the hub, some objects might get written someday to constantly reassign their own priority for some purpose, leading to flakiness. This would not be good. My gut tells me that slot assignment needs to be a private affair among participating cogs. Other cogs can live with their 1:8 slot timing and request more, but not tamper with others' priorities. There was something in the PC that I had to deal with once that was like this, and it was messy. I wish I could remember what it was.
That is exactly the goal in my mind. People can write for the default case. Where more is needed, a programmer is going to have to sort through the COGS and free up that which is needed.
I think that if we had alterable priorities in thbiects might get writtensubay to constantly reassign their own priority for some purpose, leading to flakiness. This would not be good. My gut tells me that slot assignment needs to be a private affair among participating objects. Other objects can live with their 1:8 slot and request more, but not tamper with others' priorities. There was something in the PC that I had to deal with once that was like this, and it was messy.
I agree with you.
I meant alter their own behavior, such as lowering a bitrate, or offering a subset of their functionality, not alter how another COG is doing things.
I like the model presented by the sets of bits. I don't think much of a general priority scheme.
Edit: Maybe it is the best idea to keep it private. One cog could make an adjustment that affects behavior in another, etc... No query is best.
I think that if we had alterable priorities in the hub, some objects might get written someday to constantly reassign their own priority for some purpose, leading to flakiness. This would not be good. My gut tells me that slot assignment needs to be a private affair among participating cogs. Other cogs can live with their 1:8 slot timing and request more, but not tamper with others' priorities. There was something in the PC that I had to deal with once that was like this, and it was messy. I wish I could remember what it was.
Yes, a cog should not be able to take another's slot unless that cog specifically yields it.
We are only talking about if a cog can set a high or low priority to claim another cog's slot. Unless of course its available.
So we are discussing how to implement the priority.
AAA = first priority claim slot, it is the cog number that has the first claim on this slot
BBB = second priority claim slot, this is the cog that gets this slot of AAA does not have a pending access
CCC = third priority claim slot, this is the cog if AAA and BBB don't need the slot
If AAA=BBB, CCC=0, any cog can grab the slot, there is no priority
if AAA=CCC, BBB=0, cog AAA does not get any slots
SETHUB #0-7,D/#
GETHUB reg,#0-7
This would allow an "OS" to dynamically change hub priorities
I like the bit mask, too, but it doesn't offer any prioritization.
And, yes, eight 3-bit fields of relative cog numbers would be a pain to set up. Like in SETTASK, as soon as %000 was found in the offer order, that would mean anybody.
Hey, maybe the 8-bit offer mask could be the top-priority, with everyone else being implied lower-priority. I think a single level of priority is all that is needed. Those not in the priority mask are flying stand-by.
There was something in the PC that I had to deal with once that was like this, and it was messy. I wish I could remember what it was.
Perhaps something about the many evolutionary video cards, and their secret, rock buried , video modes!
They used to behave as a castle of cards; every newly loaded software could mess the whole thing, without any noticeable clue for the still running ones.
Only the poor miserable user could ever notice, that some pigeon decided to build a nest, just on his tv set outdoor antenna, blasting in pieces the whole image.
I'd become allergic to them, starting from this point!
- excellent point, a cog must voluntarily give up its hub slice, ie another may not grab it unless the cog is not using it
- still an eight entry hub slot table would allow good control over "left over" hub bandwidth
above SETUP defines the arguments as:
hubslot = 0..7
R = cogid voluntarily releases its slot if '1', only cogid can set this
H = hog mode, coigid claims all available unused hub cycles (low priority non-deterministic hub access)
BBB = cog that gets slot hubslot if cog(hubslot) does not need it (if BBB can use it)
CCC = cog that gets slot hubslot if cog(hubslot) and cog(BBB) does not need it (if CCC can use it)
BBB and CCC can be modified by any cog
R and H can only be modified by default "owner" cog
I think that if we had alterable priorities in the hub, some objects might get written someday to constantly reassign their own priority for some purpose, leading to flakiness. This would not be good. My gut tells me that slot assignment needs to be a private affair among participating cogs. Other cogs can live with their 1:8 slot timing and request more, but not tamper with others' priorities. There was something in the PC that I had to deal with once that was like this, and it was messy. I wish I could remember what it was.
... but it could only take unused, voluntarily released cycles, so it would not impact determinism.
As a matter of fact, a "Boss Hog" that released its own (guaranteed) slot, but claimed all unused slots, would be a useful benchmark of how much hub bandwidth is being unused.
... but it could only take unused, voluntarily released cycles, so it would not impact determinism.
As a matter of fact, a "Boss Hog" that released its own (guaranteed) slot, but claimed all unused slots, would be a useful benchmark of how much hub bandwidth is being unused.
Bill
It's also a good point, for the systems programmer, enabling it to tune the many possibilities of task mixing and distribution, among a group of COGs!
Perhaps something about the many evolutionary video cards, and their secret, rock buried , video modes!
They used to behave as a castle of cards; every newly loaded software could mess the whole thing, without any noticeable clue for the still running ones.
Only the poor miserable user could ever notice, that some pigeon decided to build a nest, just on his tv set outdoor antenna, blasting in pieces the whole image.
I'd become allergic to them, starting from this point!
Blaaargh!
Yanomani
I had forgotten about all that. I remember it well, though. What a mess video modes were. I remember coaxing applications into using certain modes by modifying their support files. That was when EGA was transitioning to VGA and all APA modes were somewhat custom. What I miss about that time was how reliable the computer was, despite those kinds of issues.
If you were on higher end PC Video Systems at the time, there was also microcode cards and a complex dance of memory resident bits and pieces that all had to work to drive things like 1024x768 in an awesome 16 colors!
Then again, sorting this paid well. (was my first indie consulting gig)
If the cog wants its slot, it get it. If a cog does not use its available slot, it is available and it has no part in the process. This is the normal default, and requires no settings. It remains deterministic. It makes no difference to this cog if another cog uses its unwanted slot, so any existing driver should work untouched.
Optional (I am in two minds of whether this is even necessary)
If the cog wants to yield its slot (even if it wants it), then it must set a yield flag and a cog# it will yield to. eg YIELD #0..7
A cog can claim extra slots for itself by:
Setting that it can use additional unused slots, and which unused slots it can use, with 2 settings - high priority and low priority.
Note: If we implement the optional YIELD, then a priority slot with yield will steal that cogs slot if required.
Each slot can only have a single high priority cog# assigned to it.
Do we really require more than one priority?
Does this sound acceptable? We can work out the best instruction if we can get the requirements done.
Comments
That is what I'd like to see when a COG sets the LSB to 0, it would always give up it's own slot and only use a donated slot.
C.W.
I think the controversy was bypassed when someone realized that each cog can keep its own slot, but when the slot is not used, someone else can have it - and this new behavior can be enabled - it's not automatic. So, standard round-robin access was not compromised. The secret sauce was not adulterated.
A SETSLOT D/# value of %11111110 would mean 'any slot by my own'.
And of course, we need to plan for a "no-hub" COG, so that makes perfect sense. It gets used via Port D, or something.
I like the bit mask, too, but it doesn't offer any prioritization.
And, yes, eight 3-bit fields of relative cog numbers would be a pain to set up. Like in SETTASK, as soon as %000 was found in the offer order, that would mean anybody.
Hey, maybe the 8-bit offer mask could be the top-priority, with everyone else being implied lower-priority. I think a single level of priority is all that is needed. Those not in the priority mask are flying stand-by.
Chip has you covered:
"%00000000 just don't try to execute a hub instruction after setting this value - you'll hang."
C.W.
re Chips post #3115 & others.
I had thought that a cog could make its slot available to another specific cog, or the pool, when not required. But this makes existing drivers unfriendly to give up their unused slots.
That is why I would think it better for a high priority cog to claim slots as low or high priority. If another cog claims the relevant slot as a priority, it now gets it. Tough luck - the programmer/sw just needs to handle this case.
So I see each cog as enabling its ability to access other cogs free slots, and if it does so, then it can claim some of those as "I am highest priority". Its quite simple and basic.
Only 1 cog will have priority, otherwise it is shared on a round-robbin basis from the cog# of the free slot.
I don't really see the requirement for a cog to be able to yield its slot to another cog as priority. But if you think that's a good idea, then its another option.
Yes! I agreed with you, then saw Chip's post and realized it was already covered, meaning the original intent was the right intent, and that our side discussion really was just that.
I didn't like, "if you do this, it will hang", but that's precisely what it should do. There is assembly language for you.
How about make the values absolute instead of relative in both the mask and bitfields?
It's going to take knowledge of what is loaded where anyway.
C.W.
We need a query instruction so that COGS can read the state of the HUB and potentially change behavior. Absolute bit fields will help sort this kind of thing out. And that all means people will need to just run specific COGS to have this all work for them, or leave the "slot offered" mode turned off.
I like this. Was quite a shock for me. IMHO, priorities get complex. This way, the developer can plan and IMHO, should plan it all out.
When a COG is waiting for the HUB I assume a flag is set. PENDING = TRUE
When a HUB slot appears that is PENDING = FALSE, use it instead of waiting for the required slot.
If COGS aren't used there automatically FREE slots for the other COGS.
If all COGS are trying to access HIUB at the same time, normal default slots apply.
This seems simple and automatic, or have I missed something?
I think the goal is to have a way to make it deterministic if needed.
C.W.
But, rather than just allocate the free slots on a first come basis, we want to be able to allocate it in at least a small priority, so that we can know that it will get at least a certain number of slots in 8, provided we control the cog(s) that must not use all their slots. This is the raw basics anyway.
I think that if we had alterable priorities in the hub, some objects might get written someday to constantly reassign their own priority for some purpose, leading to flakiness. This would not be good. My gut tells me that slot assignment needs to be a private affair among participating cogs. Other cogs can live with their 1:8 slot timing and request more, but not tamper with others' priorities. There was something in the PC that I had to deal with once that was like this, and it was messy. I wish I could remember what it was.
That is exactly the goal in my mind. People can write for the default case. Where more is needed, a programmer is going to have to sort through the COGS and free up that which is needed.
I agree with you.
I meant alter their own behavior, such as lowering a bitrate, or offering a subset of their functionality, not alter how another COG is doing things.
I like the model presented by the sets of bits. I don't think much of a general priority scheme.
Edit: Maybe it is the best idea to keep it private. One cog could make an adjustment that affects behavior in another, etc... No query is best.
We are only talking about if a cog can set a high or low priority to claim another cog's slot. Unless of course its available.
So we are discussing how to implement the priority.
The pace this forum is moving at has made the mind a bit foggy!
At the moment we can't predict how many cycles a HUB instruction will take.
So grabbing a FREE slot instead of the REAL slot doesn't change that.
First glance a data collected with SETRACE shows pipeline STALL of varying cycles.
I am talking multi-tasking of course.
Here is another thought.
Basically, there are eight hub slots available.
The prop is already good with nine bit values :-)
Maybe we could have an eight entry table, sort of pseudo hub control registers, something like the following
AAA = first priority claim slot, it is the cog number that has the first claim on this slot
BBB = second priority claim slot, this is the cog that gets this slot of AAA does not have a pending access
CCC = third priority claim slot, this is the cog if AAA and BBB don't need the slot
If AAA=BBB, CCC=0, any cog can grab the slot, there is no priority
if AAA=CCC, BBB=0, cog AAA does not get any slots
SETHUB #0-7,D/#
GETHUB reg,#0-7
This would allow an "OS" to dynamically change hub priorities
RDLONG reg,addr WC 'where WC means use a FREE slot if availableThis gets around the determinism issue
Perhaps something about the many evolutionary video cards, and their secret, rock buried , video modes!
They used to behave as a castle of cards; every newly loaded software could mess the whole thing, without any noticeable clue for the still running ones.
Only the poor miserable user could ever notice, that some pigeon decided to build a nest, just on his tv set outdoor antenna, blasting in pieces the whole image.
I'd become allergic to them, starting from this point!
Blaaargh!
Yanomani
Revised suggestion, still a hub table
SETHUB hubslot, #RHBBBCCC
As per messages after the one I am quoting
- excellent point, a cog must voluntarily give up its hub slice, ie another may not grab it unless the cog is not using it
- still an eight entry hub slot table would allow good control over "left over" hub bandwidth
above SETUP defines the arguments as:
hubslot = 0..7
R = cogid voluntarily releases its slot if '1', only cogid can set this
H = hog mode, coigid claims all available unused hub cycles (low priority non-deterministic hub access)
BBB = cog that gets slot hubslot if cog(hubslot) does not need it (if BBB can use it)
CCC = cog that gets slot hubslot if cog(hubslot) and cog(BBB) does not need it (if CCC can use it)
BBB and CCC can be modified by any cog
R and H can only be modified by default "owner" cog
Somebody is gonna write one straight away too. What a HOG!
"Boss Hogg"
... but it could only take unused, voluntarily released cycles, so it would not impact determinism.
As a matter of fact, a "Boss Hog" that released its own (guaranteed) slot, but claimed all unused slots, would be a useful benchmark of how much hub bandwidth is being unused.
One priority makes sense. Cogs either must have additional slots, or they want additional slots.
So then, naming a COG for access recognizes the must have case, leaving the want case for all other times.
Bill
It's also a good point, for the systems programmer, enabling it to tune the many possibilities of task mixing and distribution, among a group of COGs!
Yanomani
I had forgotten about all that. I remember it well, though. What a mess video modes were. I remember coaxing applications into using certain modes by modifying their support files. That was when EGA was transitioning to VGA and all APA modes were somewhat custom. What I miss about that time was how reliable the computer was, despite those kinds of issues.
If you were on higher end PC Video Systems at the time, there was also microcode cards and a complex dance of memory resident bits and pieces that all had to work to drive things like 1024x768 in an awesome 16 colors!
Then again, sorting this paid well. (was my first indie consulting gig)
If the cog wants its slot, it get it. If a cog does not use its available slot, it is available and it has no part in the process. This is the normal default, and requires no settings. It remains deterministic. It makes no difference to this cog if another cog uses its unwanted slot, so any existing driver should work untouched.
Optional (I am in two minds of whether this is even necessary)
If the cog wants to yield its slot (even if it wants it), then it must set a yield flag and a cog# it will yield to. eg YIELD #0..7
A cog can claim extra slots for itself by:
Setting that it can use additional unused slots, and which unused slots it can use, with 2 settings - high priority and low priority.
Note: If we implement the optional YIELD, then a priority slot with yield will steal that cogs slot if required.
Each slot can only have a single high priority cog# assigned to it.
Do we really require more than one priority?
Does this sound acceptable? We can work out the best instruction if we can get the requirements done.