An idea: the chances of two or more adjacent cogs being free could be increased by tweaking the cog allocation. Rather than just allocating whichever free cog has the lowest cogid (I think this is how it is being done?), cogs could be allocated to maximize the number of adjacent free cogs. For example, if you had four cogs like this: OOXO (where X is allocated, and O is free), then cog #4 should be allocated next, rather than cog #1. This wouldn't eliminate the problem, because you could still allocate a bunch of cogs and then stop them in a pattern that doesn't give adjacent free cogs, but it would make it more likely that you have adjacent free cogs.
For any kind of cog-to-cog link, there just needs to be some way to select the cog, or cogs. Then, you have something certain to work.
That is exactly the point.
Using adjacent cogs, you "fix" the spectrum of possibilities and create the pre-condition of finding two adjacent free cogs.
I still think that a multiplexed FIFO with corresponding opcodes for reading with blocking and writing is better. because the end of the FIFO could also be some pins.
The issue I see with the shared LUT is that you are creating a two tier shared-memory hierarchy... There is already a shared pool of memory, it works, it doesn't have the problems of choosing adjacent COGs, why do you need a second version of that ? what would it be 2 times faster ?....
You already have a 2 tier execution model (HUB/COG), I welcome it, but for communication between cogs ? I find it a bit too restrictive, somehow not in the propeller spirit...
About the OBEX... looking for two adjacent cogs can be done in software. Once that is done, a coginit can be done with the returned cog numbers. No cognew problems here!!!
This is the problem. You may discover that two adjacent cogs are free, but when you go to start them, they may not be free, anymore. What was free at cycle N is sometimes not free at cycle N+1.
Sorry @cgracey may I have an explanation from the chip builder (with understandable wording) where the issues are because I really can't understand.
How are the cogs started? Usually in the main app from the programmer
How are the obex objects started? Again usually in the main app from the programmer.
Can the obex object dinamically start a cog? yes, of course. And how many? Up to all cogs available. Perhaps it can require even more cogs than available (because other objects have already allocated them) )thus not matching its requirements to operate. It depends on how many cogs are already in use. It depends on the order the programmer starts the various objects.
I think that such behaviour should be documented in the object docs for the others to use correctly.
Now, if the start method of an objects "cognew" a cog and then "coginit cogid+1" the second returning a status "done" when finished. Isn't here also a matter of documentation? Isn't here enough that such object states that no other objects should be launched until the procedure is not completed? That this object should be eventually launched the first?
If other objects (perhaps launched before) dinamically starts other cogs can create issues, but such objects can potentially be incompatible or create issues even today, even on the P1, isn't it?
How are this two behaviours different?
The hardware decision to launch an available cog occurs in one clock cycle, only. This is how it must be for atomicity with COGNEW. There is no waiting for anything to finish, only the decision to start can be made in one clock.
I've been mulling over how to provide LUT sharing without setting the stage for a future software crisis, and I just can't see how to do it, shy a ton of logic.
Nothing compares to immediate r/w LUT sharing. There is a very fast central data conduit in the form of he hub RAM with egg-beater, but there is big latency there. LUT-sharing would cut latency by an order of magnitude. It's important for the architecture that all cogs are equal, though. In relation to cog 5, cog 1 and cog 6 would not be equal if only cog 6 could share its LUT with cog 5.
I can make an object that will automatically search for two adjacent cogs without any problems whatsoever. No additional instructions required!!! I can do it in P1 too!!!
My contention is that this is not true. You cannot do it on the P1 either.
Chip has explained why in a previous post here.
No need to post a refutation in actual code. A description of the general idea, or pseudo code, will do.
Heater,
It is the same way I map which cogs are used and which are free in my PropOS.
I have a dummy "jmp $" and start free cogs using this routine. Each cog new returns the cog# started until no free cogs are found. Now I know which cogs are used and which are free, so I build a table. Then I stop all the cogs I started.
The difference with the P2 and shared LUT, or for that matter using specific cogs to minimise latency with the egg beater, is that each time I perform a cognew I would check if I now have cogs meeting my requirements. If so, I return the unwanted cogs by stopping them, and either restart the required cogs or repoint the software dummy routine (easy with hub exec).
I think most are missing the primary way the majority of users start cogs.
Usually a main routine (typically cog 0) will start objects. If those objects require their own cog(s) the start routine will start it/them, and typically returns the cogid+1. At this time, the main routine may start another object, and so it goes. Thus, a pair (or triplet, etc) of operating cogs may be launched by an object.
I still maintain that all cogs will be equal. Each cog will have a direct path via shared LUT, to both the lower and the upper adjacent cogs. To avail oneself of this path, consecutive cogs may/will need to be started/reserved by the initialising software.
I can even forsee where some users could specifically utilise most cogs with direct data paths rather than the data being passed via hub to extract better performance than they could via hub. I see this as a beneficial behaviour of the P2, and certainly not a detriment.
Many of us have used various unforeseen quirks in the P1 to distinct advantage. Bill's LMM method is a specific point in question and this has resulted in hub exec and the egg beater in the P2. Others have used the Video section to output serial data. Should we preclude these thing because they "are not in the spirit of the propeller" ???
The hardware decision to launch an available cog occurs in one clock cycle, only. This is how it must be for atomicity with COGNEW. There is no waiting for anything to finish, only the decision to start can be made in one clock.
This seems to be the best place to focus on what seems to be essentially a housekeeping issue.
I've been mulling over how to provide LUT sharing without setting the stage for a future software crisis, and I just can't see how to do it, shy a ton of logic.
Complete any-COG to any-COG LUT connects would be very logic hungry, and also likely slow, with all that routing and muxes....
Could any of the pin-transfer ideas or logic be used to speed this up ?
ie it seems the COG <-> Pin-Cell link has been tuned and proven nicely, and allows 64 destinations with workable routing ?
A variant on that with less destinations(16), but more bandwidth (2x, 4x?), could give a solution ?
eg a byte-wide, DDR serial link, could transfer 32b in 2 sysclks, and if maybe 4 (or more) of those local links could connect to COGS, you can link any-any up to N connections.
Nothing compares to immediate r/w LUT sharing. There is a very fast central data conduit in the form of he hub RAM with egg-beater, but there is big latency there. LUT-sharing would cut latency by an order of magnitude. It's important for the architecture that all cogs are equal, though. In relation to cog 5, cog 1 and cog 6 would not be equal if only cog 6 could share its LUT with cog 5.
COG allocation is on an all-equal basis, so it is a placement problem, to get adjacent COGs.
There are no additional restrictions, (now DACs are freed) and you can already define COG# now.
Just some cases need to be more general.
Heater,
It is the same way I map which cogs are used and which are free in my PropOS.
I have a dummy "jmp $" and start free cogs using this routine. Each cog new returns the cog# started until no free cogs are found. Now I know which cogs are used and which are free, so I build a table. Then I stop all the cogs I started.
The difference with the P2 and shared LUT, or for that matter using specific cogs to minimise latency with the egg beater, is that each time I perform a cognew I would check if I now have cogs meeting my requirements. If so, I return the unwanted cogs by stopping them, and either restart the required cogs or repoint the software dummy routine (easy with hub exec).
If you start up cogs on an experimental basis to find two in a row, you might choke off a COGNEW from some unrelated code written by someone else. That could be problematic, as now your testing is causing other, unrelated programs to fail when they wouldn't have, otherwise. All those errors have to be handled, somehow. There's no way out of this, except to allocate cogs at the start of an app, and that undermines the concept of random reallocation of cog assets. It's kind of like reserving seats in a bus station.
Each cog new returns the cog# started until no free cogs are found. Now I know which cogs are used and which are free, so I build a table. Then I stop all the cogs I started.
So far so good.
Now, to get adjacent pairs of COGs you need to know that you have a COG ID N and then claim COG ID N+1.
It's not clear to me how this is possible without a race condition in the general case.
...
Nothing compares to immediate r/w LUT sharing.
Positively agreed. So irrespective of any caveats, why would you not include it?
Would it not be better to offer it, even with caveats such that experienced programmers/engineers could make the P2 perform even better? It might be the difference in getting a major customer!
There is a very fast central data conduit in the form of he hub RAM with egg-beater, but there is big latency there. LUT-sharing would cut latency by an order of magnitude. It's important for the architecture that all cogs are equal, though.
In relation to cog 5, cog 1 and cog 6 would not be equal if only cog 6 could share its LUT with cog 5.
Surely all cogs are equal??? Cog 5 has a direct conduit (shared LUT) with both Cog 4 and with Cog 6. So every cog has a direct conduit with both its adjacent cogs.
We are not saying only Cog 5 has a direct conduit with Cog 6, but Cog 7 does not have a conduit to its neighbours!
I think it is easy to explain and understand. It is definately not like some chips that have a plenthora of peripherals, but they are tied to specific pins, so some peripherals become either/or.
... you might choke off a COGNEW from some unrelated code written by someone else. ...
There's no way out of this, except to allocate cogs at the start of an app, and that undermines the concept of random reallocation of cog assets. It's kind of like reserving seats in a bus station.
COGNEW must already have some means to arbitrate same-SysCLK COGNEWs ?
Can that be extended, to arbitrate pair (or more) requests ?
I'm still unclear on physical LUT dual-porting : if it is E-O porting, you need pair allocates. but if it overlays two halves as
(N-1,N), and (N,N+1) then I think you need to allocate 3 COGS ?
I've been mulling over how to provide LUT sharing without setting the stage for a future software crisis, and I just can't see how to do it, shy a ton of logic.
Well, this is probably really ugly but what if you add a 16 bit mask register that COGNEW uses to decide which COGs are candidates for allocation. If a bit is set then COGNEW can allocate that COG if it isn't already running. If it's not set, COGNEW skips over that COG and goes on to the next one. If you set that mask so that every other bit is set and then do COGNEW
Heater,
It is the same way I map which cogs are used and which are free in my PropOS.
I have a dummy "jmp $" and start free cogs using this routine. Each cog new returns the cog# started until no free cogs are found. Now I know which cogs are used and which are free, so I build a table. Then I stop all the cogs I started.
The difference with the P2 and shared LUT, or for that matter using specific cogs to minimise latency with the egg beater, is that each time I perform a cognew I would check if I now have cogs meeting my requirements. If so, I return the unwanted cogs by stopping them, and either restart the required cogs or repoint the software dummy routine (easy with hub exec).
If you start up cogs on an experimental basis to find two in a row, you might choke off a COGNEW from some unrelated code written by someone else. That could be problematic, as now your testing is causing other, unrelated programs to fail when they wouldn't have, otherwise. All those errors have to be handled, somehow. There's no way out of this, except to allocate cogs at the start of an app, and that undermines the concept of random reallocation of cog assets. It's kind of like reserving seats in a bus station.
What if you add a new form of COGNEW that does this looking for two in a row? If it finds them, it starts both at the same time with the same code. It's up to one of them to use COGINIT to start its neighbor with the code it actually wants it to run if necessary. If two in a row aren't found, COGNEW fails.
...
Nothing compares to immediate r/w LUT sharing.
Positively agreed. So irrespective of any caveats, why would you not include it?
Would it not be better to offer it, even with caveats such that experienced programmers/engineers could make the P2 perform even better? It might be the difference in getting a major customer!
There is a very fast central data conduit in the form of he hub RAM with egg-beater, but there is big latency there. LUT-sharing would cut latency by an order of magnitude. It's important for the architecture that all cogs are equal, though.
In relation to cog 5, cog 1 and cog 6 would not be equal if only cog 6 could share its LUT with cog 5.
Surely all cogs are equal??? Cog 5 has a direct conduit (shared LUT) with both Cog 4 and with Cog 6. So every cog has a direct conduit with both its adjacent cogs.
We are not saying only Cog 5 has a direct conduit with Cog 6, but Cog 7 does not have a conduit to its neighbours!
I think it is easy to explain and understand. It is definately not like some chips that have a plenthora of peripherals, but they are tied to specific pins, so some peripherals become either/or.
But it takes paradigm-disrupting measures to assure that you can get two adjacent cogs. I just don't like that idea.
I've been mulling over how to provide LUT sharing without setting the stage for a future software crisis, and I just can't see how to do it, shy a ton of logic.
Well, this is probably really ugly but what if you add a 16 bit mask register that COGNEW uses to decide which COGs are candidates for allocation. If a bit is set then COGNEW can allocate that COG if it isn't already running. If it's not set, COGNEW skips over that COG and goes on to the next one. If you set that mask so that every other bit is set and then do COGNEW
Heater,
It is the same way I map which cogs are used and which are free in my PropOS.
I have a dummy "jmp $" and start free cogs using this routine. Each cog new returns the cog# started until no free cogs are found. Now I know which cogs are used and which are free, so I build a table. Then I stop all the cogs I started.
The difference with the P2 and shared LUT, or for that matter using specific cogs to minimise latency with the egg beater, is that each time I perform a cognew I would check if I now have cogs meeting my requirements. If so, I return the unwanted cogs by stopping them, and either restart the required cogs or repoint the software dummy routine (easy with hub exec).
If you start up cogs on an experimental basis to find two in a row, you might choke off a COGNEW from some unrelated code written by someone else. That could be problematic, as now your testing is causing other, unrelated programs to fail when they wouldn't have, otherwise. All those errors have to be handled, somehow. There's no way out of this, except to allocate cogs at the start of an app, and that undermines the concept of random reallocation of cog assets. It's kind of like reserving seats in a bus station.
What if you add a new form of COGNEW that does this looking for two in a row? If it finds them, it starts both at the same time with the same code. It's up to one of them to use COGINIT to start its neighbor with the code it actually wants it to run if necessary. If two in a row aren't found, COGNEW fails.
We could do that multi-cog COGNEW thing, but it will lead to the fragmented malloc problem, where an eventual clean-up would be needed to get the active cogs contiguous again, so that chunks of cogs could be allocated once more, and that is not possible to do with cogs.
I'm quite sure when Windows freezes up now and then for a split second, it's making RAM allocations contiguous again so that it can meet a new malloc request that fragmentation was preventing.
Part of the issue is that you might not want two in a row, but a fixed separation (eg cog 1 and cog 5) to work in with the egg beater spacing.
I think the key thing to acknowledge is that because you have 16 cogs, cogs could (potentially) be executing the exact same cognew as the exact same time, with unpredictable results. To prevent this, you have to invoke the hub slot round-robin, which in effect inserts a variable startup delay of 0..15 cycles but resolves any contention, because only one cog can start (one or two) new cogs on 'its' cycle.
I think this is a similar 'deterministic once running' philosophy we'll have with the egg beater anyway
Regarding starting a pair, you can encode the second cog id request in the next higher nibble (bits 7 to 4), but you'd need bit 8 to signal the difference between requesting cog 0 or not.
The difficulty is how to pass the start address for 2 cogs in one instruction, perhaps ALTDS could help, not sure.
Once you arrive at needing multiple clock cycles to kick off new cogs, things start to free up, and indeed it might be possible to have a bit mask of arbitrary cog start requests, which rotates against a bit mask of running cogs, rotating one per cycle, until a match is made.
... you might choke off a COGNEW from some unrelated code written by someone else. ...
There's no way out of this, except to allocate cogs at the start of an app, and that undermines the concept of random reallocation of cog assets. It's kind of like reserving seats in a bus station.
COGNEW must already have some means to arbitrate same-SysCLK COGNEWs ?
Can that be extended, to arbitrate pair (or more) requests ?
I'm still unclear on physical LUT dual-porting : if it is E-O porting, you need pair allocates. but if it overlays two halves as
(N-1,N), and (N,N+1) then I think you need to allocate 3 COGS ?
It overlaid halves, as in your second supposition, but allocating any two adjacent cogs would give you sharing.
Heater,
It is the same way I map which cogs are used and which are free in my PropOS.
I have a dummy "jmp $" and start free cogs using this routine. Each cog new returns the cog# started until no free cogs are found. Now I know which cogs are used and which are free, so I build a table. Then I stop all the cogs I started.
The difference with the P2 and shared LUT, or for that matter using specific cogs to minimise latency with the egg beater, is that each time I perform a cognew I would check if I now have cogs meeting my requirements. If so, I return the unwanted cogs by stopping them, and either restart the required cogs or repoint the software dummy routine (easy with hub exec).
If you start up cogs on an experimental basis to find two in a row, you might choke off a COGNEW from some unrelated code written by someone else. That could be problematic, as now your testing is causing other, unrelated programs to fail when they wouldn't have, otherwise. All those errors have to be handled, somehow. There's no way out of this, except to allocate cogs at the start of an app, and that undermines the concept of random reallocation of cog assets. It's kind of like reserving seats in a bus station.
Chip,
I guess I maintain that you should at least understand the basics of what any object is doing. The same understanding is required for the use of hub ram, and for pins. If you don't understand the overall picture, you shouldn't be doing it.
Remember, I am presuming professional/commercial usage where certain expectations must be met.
While a hobbyist may not properly understand the objects requirements, he/she can ask on the forum. A mistake is not regarded at a catastrophe.
If you are marketing the P2 primarily to the hobbyist and not the professional, then perhaps there is some merit in your stance. Otherwise I would have thought that the objective for the P2 would have been for best practical performance, caveats included.
We could do that multi-cog COGNEW thing, but it will lead to the fragmented malloc problem, where an eventual clean-up would be needed to get the active cogs contiguous again, so that chunks of cogs could be allocated once more, and that is not possible to do with cogs.
Dang, that could be a problem if some OBEX program leaves every second Cog vacant ...
I'm quite sure when Windows freezes up now and then for a split second, it's making RAM allocations contiguous again so that it can meet a new malloc request that fragmentation was preventing.
Windoze is just weird! And always has been since Win3 days.
I don't know about you, but if shared LUT makes it in, I expect to produce some objects with more than 2 cooperating cogs. Perhaps a string of 4 or more consecutive cogs!
Why not just include the feature but restrict objects in obx.
I proposed this earlier and can't see why this would not be a simple implementation:
Reserve two adjacent cogs(or any number of pairs) for future use by some means of a key for access, then they are sure to be available because they require a key to launch them.
ReserveCog[CogId, accesskey]
Run the Reserve at the top of the main program to set aside a cog(s) for later, then require a key to get it to run. The key is defined in the Reserve function. No other cog can accidentally use it.
I'm still unclear on physical LUT dual-porting : if it is E-O porting, you need pair allocates. but if it overlays two halves as
(N-1,N), and (N,N+1) then I think you need to allocate 3 COGS ?
It overlaid halves, as in your second supposition, but allocating any two adjacent cogs would give you sharing.
Cool. Nice to have that clarified.
Allocating two would give you N, N+1, but if you wanted three way co-operation, which is possible with two halves(N-1,N+1), then surely you now need 3 adjacent COGs ? (master in the middle)
ie Bill's suggestion becomes a user choice of
COGNEW
COGNEW2 wc
COGNEW3 wc
Remember, I am presuming professional/commercial usage where certain expectations must be met.
While a hobbyist may not properly understand the objects requirements, he/she can ask on the forum. A mistake is not regarded at a catastrophe.
If you are marketing the P2 primarily to the hobbyist and not the professional, then perhaps there is some merit in your stance. Otherwise I would have thought that the objective for the P2 would have been for best practical performance, caveats included.
As official mouthpiece that I am ... Parallax is primarily educationally minded. Commercial and hobbyist developers are both encouraged though.
As tubular pointed out above, I have been trying to point out the requirement of variable cog spacing, as required to minimise latency using the egg beater design. It is more difficult with the egg beater, but it will be done.
Thus, IMHO we just need to allocate/reserve any specific cogs during the initialisation of the main code.
BTW I am not so sure there will be many of these types of objects starting/stopping/starting cogs. It's just something the software architect must take care off, as he/she does with hub usage and pin usage.
We could do that multi-cog COGNEW thing, but it will lead to the fragmented malloc problem, where an eventual clean-up would be needed to get the active cogs contiguous again, so that chunks of cogs could be allocated once more, and that is not possible to do with cogs.
Maybe, in very extreme cases, but remember P2 is a Microcontroller, it is not a Microprocessor.
Anything that needs more than one COG, sounds like fundamental engine room stuff, unlikely to be added / removed like some fluffy app.
General GUI stuff, I can see a case for more flexible use, but that's only a single COG type usage anyway.
If someone does want to turn P2 into an OS-running beast, then that OS can also manage any required clean-ups.
Not seeing a practical problem here ?
As tubular pointed out above, I have been trying to point out the requirement of variable cog spacing, as required to minimise latency using the egg beater design. It is more difficult with the egg beater, but it will be done.
Thus, IMHO we just need to allocate/reserve any specific cogs during the initialisation of the main code.
BTW I am not so sure there will be many of these types of objects starting/stopping/starting cogs. It's just something the software architect must take care off, as he/she does with hub usage and pin usage.
If objects aren't written to accommodate worst-case hub timing, they will not work. I would not write cog code that relied on cogs being any particular number apart. It's just asking for trouble.
Comments
That is exactly the point.
Using adjacent cogs, you "fix" the spectrum of possibilities and create the pre-condition of finding two adjacent free cogs.
I still think that a multiplexed FIFO with corresponding opcodes for reading with blocking and writing is better. because the end of the FIFO could also be some pins.
The issue I see with the shared LUT is that you are creating a two tier shared-memory hierarchy... There is already a shared pool of memory, it works, it doesn't have the problems of choosing adjacent COGs, why do you need a second version of that ? what would it be 2 times faster ?....
You already have a 2 tier execution model (HUB/COG), I welcome it, but for communication between cogs ? I find it a bit too restrictive, somehow not in the propeller spirit...
The hardware decision to launch an available cog occurs in one clock cycle, only. This is how it must be for atomicity with COGNEW. There is no waiting for anything to finish, only the decision to start can be made in one clock.
I've been mulling over how to provide LUT sharing without setting the stage for a future software crisis, and I just can't see how to do it, shy a ton of logic.
Nothing compares to immediate r/w LUT sharing. There is a very fast central data conduit in the form of he hub RAM with egg-beater, but there is big latency there. LUT-sharing would cut latency by an order of magnitude. It's important for the architecture that all cogs are equal, though. In relation to cog 5, cog 1 and cog 6 would not be equal if only cog 6 could share its LUT with cog 5.
Chip has explained why in a previous post here.
No need to post a refutation in actual code. A description of the general idea, or pseudo code, will do.
It is the same way I map which cogs are used and which are free in my PropOS.
I have a dummy "jmp $" and start free cogs using this routine. Each cog new returns the cog# started until no free cogs are found. Now I know which cogs are used and which are free, so I build a table. Then I stop all the cogs I started.
The difference with the P2 and shared LUT, or for that matter using specific cogs to minimise latency with the egg beater, is that each time I perform a cognew I would check if I now have cogs meeting my requirements. If so, I return the unwanted cogs by stopping them, and either restart the required cogs or repoint the software dummy routine (easy with hub exec).
Usually a main routine (typically cog 0) will start objects. If those objects require their own cog(s) the start routine will start it/them, and typically returns the cogid+1. At this time, the main routine may start another object, and so it goes. Thus, a pair (or triplet, etc) of operating cogs may be launched by an object.
I still maintain that all cogs will be equal. Each cog will have a direct path via shared LUT, to both the lower and the upper adjacent cogs. To avail oneself of this path, consecutive cogs may/will need to be started/reserved by the initialising software.
I can even forsee where some users could specifically utilise most cogs with direct data paths rather than the data being passed via hub to extract better performance than they could via hub. I see this as a beneficial behaviour of the P2, and certainly not a detriment.
Many of us have used various unforeseen quirks in the P1 to distinct advantage. Bill's LMM method is a specific point in question and this has resulted in hub exec and the egg beater in the P2. Others have used the Video section to output serial data. Should we preclude these thing because they "are not in the spirit of the propeller" ???
This seems to be the best place to focus on what seems to be essentially a housekeeping issue.
Complete any-COG to any-COG LUT connects would be very logic hungry, and also likely slow, with all that routing and muxes....
Could any of the pin-transfer ideas or logic be used to speed this up ?
ie it seems the COG <-> Pin-Cell link has been tuned and proven nicely, and allows 64 destinations with workable routing ?
A variant on that with less destinations(16), but more bandwidth (2x, 4x?), could give a solution ?
eg a byte-wide, DDR serial link, could transfer 32b in 2 sysclks, and if maybe 4 (or more) of those local links could connect to COGS, you can link any-any up to N connections.
COG allocation is on an all-equal basis, so it is a placement problem, to get adjacent COGs.
There are no additional restrictions, (now DACs are freed) and you can already define COG# now.
Just some cases need to be more general.
If you start up cogs on an experimental basis to find two in a row, you might choke off a COGNEW from some unrelated code written by someone else. That could be problematic, as now your testing is causing other, unrelated programs to fail when they wouldn't have, otherwise. All those errors have to be handled, somehow. There's no way out of this, except to allocate cogs at the start of an app, and that undermines the concept of random reallocation of cog assets. It's kind of like reserving seats in a bus station.
Now, to get adjacent pairs of COGs you need to know that you have a COG ID N and then claim COG ID N+1.
It's not clear to me how this is possible without a race condition in the general case.
Would it not be better to offer it, even with caveats such that experienced programmers/engineers could make the P2 perform even better? It might be the difference in getting a major customer! Surely all cogs are equal??? Cog 5 has a direct conduit (shared LUT) with both Cog 4 and with Cog 6. So every cog has a direct conduit with both its adjacent cogs.
We are not saying only Cog 5 has a direct conduit with Cog 6, but Cog 7 does not have a conduit to its neighbours!
I think it is easy to explain and understand. It is definately not like some chips that have a plenthora of peripherals, but they are tied to specific pins, so some peripherals become either/or.
Can that be extended, to arbitrate pair (or more) requests ?
I'm still unclear on physical LUT dual-porting : if it is E-O porting, you need pair allocates. but if it overlays two halves as
(N-1,N), and (N,N+1) then I think you need to allocate 3 COGS ?
What if you add a new form of COGNEW that does this looking for two in a row? If it finds them, it starts both at the same time with the same code. It's up to one of them to use COGINIT to start its neighbor with the code it actually wants it to run if necessary. If two in a row aren't found, COGNEW fails.
But it takes paradigm-disrupting measures to assure that you can get two adjacent cogs. I just don't like that idea.
what about a
COGNEW2 wc
that starts a cog pair from the same cog image, with same par?
The code in the cog could then use the lowest bit of its cogid (ideally placed in the carry flag) to run odd/even cog code...
This way if there is NOT a pair available, COGNEW2 fails.
Obex objects that use paired cogs use COGNEW2, single cog objects use COGNEW.
Does not seem too complicated.
We could do that multi-cog COGNEW thing, but it will lead to the fragmented malloc problem, where an eventual clean-up would be needed to get the active cogs contiguous again, so that chunks of cogs could be allocated once more, and that is not possible to do with cogs.
I'm quite sure when Windows freezes up now and then for a split second, it's making RAM allocations contiguous again so that it can meet a new malloc request that fragmentation was preventing.
Part of the issue is that you might not want two in a row, but a fixed separation (eg cog 1 and cog 5) to work in with the egg beater spacing.
I think the key thing to acknowledge is that because you have 16 cogs, cogs could (potentially) be executing the exact same cognew as the exact same time, with unpredictable results. To prevent this, you have to invoke the hub slot round-robin, which in effect inserts a variable startup delay of 0..15 cycles but resolves any contention, because only one cog can start (one or two) new cogs on 'its' cycle.
I think this is a similar 'deterministic once running' philosophy we'll have with the egg beater anyway
Regarding starting a pair, you can encode the second cog id request in the next higher nibble (bits 7 to 4), but you'd need bit 8 to signal the difference between requesting cog 0 or not.
The difficulty is how to pass the start address for 2 cogs in one instruction, perhaps ALTDS could help, not sure.
Once you arrive at needing multiple clock cycles to kick off new cogs, things start to free up, and indeed it might be possible to have a bit mask of arbitrary cog start requests, which rotates against a bit mask of running cogs, rotating one per cycle, until a match is made.
It overlaid halves, as in your second supposition, but allocating any two adjacent cogs would give you sharing.
I guess I maintain that you should at least understand the basics of what any object is doing. The same understanding is required for the use of hub ram, and for pins. If you don't understand the overall picture, you shouldn't be doing it.
Remember, I am presuming professional/commercial usage where certain expectations must be met.
While a hobbyist may not properly understand the objects requirements, he/she can ask on the forum. A mistake is not regarded at a catastrophe.
If you are marketing the P2 primarily to the hobbyist and not the professional, then perhaps there is some merit in your stance. Otherwise I would have thought that the objective for the P2 would have been for best practical performance, caveats included.
Windoze is just weird! And always has been since Win3 days.
I don't know about you, but if shared LUT makes it in, I expect to produce some objects with more than 2 cooperating cogs. Perhaps a string of 4 or more consecutive cogs!
I proposed this earlier and can't see why this would not be a simple implementation:
Reserve two adjacent cogs(or any number of pairs) for future use by some means of a key for access, then they are sure to be available because they require a key to launch them.
ReserveCog[CogId, accesskey]
Run the Reserve at the top of the main program to set aside a cog(s) for later, then require a key to get it to run. The key is defined in the Reserve function. No other cog can accidentally use it.
Not sure it has any virtue or not, but seems like would take less logic than connecting between cogs...
Wait, I think I see that's a dumb idea because you can do that already anyway.
Still, maybe there's something else the second LUT port could be used for that's simple?
Allocating two would give you N, N+1, but if you wanted three way co-operation, which is possible with two halves(N-1,N+1), then surely you now need 3 adjacent COGs ? (master in the middle)
ie Bill's suggestion becomes a user choice of
COGNEW
COGNEW2 wc
COGNEW3 wc
Oh, ok, good point - that makes it now
COGNEW n
Where users can ask for any number of Consecutive Cogs, for more complex chaining schemes...
Thus, IMHO we just need to allocate/reserve any specific cogs during the initialisation of the main code.
BTW I am not so sure there will be many of these types of objects starting/stopping/starting cogs. It's just something the software architect must take care off, as he/she does with hub usage and pin usage.
Anything that needs more than one COG, sounds like fundamental engine room stuff, unlikely to be added / removed like some fluffy app.
General GUI stuff, I can see a case for more flexible use, but that's only a single COG type usage anyway.
If someone does want to turn P2 into an OS-running beast, then that OS can also manage any required clean-ups.
Not seeing a practical problem here ?
If objects aren't written to accommodate worst-case hub timing, they will not work. I would not write cog code that relied on cogs being any particular number apart. It's just asking for trouble.