You might want to rethink the name "TS Spin". It could acquire a bad connotation among users who find it ... um ... "tough" to understand.
-Phil
Just a placeholder name, just as Prop II is, by no means am I married to the term.·Lack of understanding of a concept doesn't inhibit the use of it, so long as·using it is clear and understandable. Nearly all users of·TVs don't fully understand how it works, but use it with little difficulty. But if the mechanism of use is contorted then it won't be used, such as timed recording on VCRs, the average user doesn't understand how to set the clock which is a prerequisite for timed recording.·
b) A task is an execution time slot that has its own PC/Z/C.
c) Initially, only task 0 is active (normal mode).
d) As soon as a 'TASKNEW D' instruction is executed, the next available task is begun at address D. C=1 if no free task was available.
e) Execution proceeds from one task to the next, looping.
f) Empty task slots are skipped and given no time.
f) There are two modes in which all tasks must collectively operate: either 'single-instruction' or 'threaded'.
···· In single-instruction mode, tasks switch after each instruction.
···· In threaded mode, tasks switch only after a 'TASKNXT' instruction.
g) A task may execute 'TASKID D' to learn its task number.
h) When a task executes a 'TASKEND' instruction, it is shut down and its task slot becomes available for reassignment via another 'TASKNEW D'.
i) A subtle register re-mapping scheme will allow the same code to execute on multiple tasks while mainting unique variables.
···· Clumps of registers actually spanning $000..$0FF can be addressed via·a lower range, whereby the task ID will be substituted for the upper address bits.
···· A 'TASKREG [noparse][[/noparse]mode,n]' instruction will set up single-instruction/threaded mode and the register clump granularity.
Sorry, I thought I remembered two instructions per clock for 320 MIPS. What I read probably implied two instructions for each equivalent Prop I clock, instead.
Anyway, here's how I see TASKSLP working:
1. In addition to a PCsave register, cc bits, and enable bit, each task would have a "sleep" bit and a count register.
2. When the task is started, its enable bit would be set and its sleep bit cleared, indicating that its next instruction can be executed whenever its turn comes up.
3. When a task executes a TASKSLP D,S instruction, D would get loaded into the task's count register, then S would be added to D. (TASKSLP uses the same opcode slot now occupied by WAITCNT, which allows two arguments.) Then, the enable bit would get cleared and the sleep bit set.
4. The hardware would monitor each task's count register for a match with CNT. Whenever a match occurs, and if sleep is set, it clears sleep and sets enable.
5. A task slot would only be available for a TASKNEW if both enable and sleep are clear. (TASKEND would clear both bits.)
For a single-task cog, TASKSLP would have the same time granularity (one clock/one instruction) as WAITCNT would have had, thus obviating the need for a separate WAITCNT.
-Phil
Cool, Phil!
So, it seems like this new definition could be seemlessly implemented, as it only internally redefines what WAITCNT does. No need to change the name, then. It would be nice if all this tasking could be handled generically, and not as any kind of exceptional circumstance. The cogs are just multitasking. Period. They just start up with one task -- kind of like the Propeller starts up with one cog.
'Love your tasking proposal! And the register banking is brilliant! It completely satisfies any objectives that overlays might have accomplished, but a lot more cleanly. Just to make sure I understand: when n is set to 2, for example, only addresses $000 - $01F are affected by the banking scheme, right?
Chip,
Nice scheme ... both the sharing of memory and Phil's tasking instructions. The default case looks like the current Prop I system and it cleanly expands by powers of 2 to 8 threads with either LMM-type multitasking or multi-threading. The thread related banking solves the issue of how to easily maintain separate variables for each thread.
@Chip
Nice! I think I would like it and use it, but all this multitasking/threading stuff kinda scares me in that the simplicity will evaporate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1011, so be surprised!
Advertisement sponsored by dfletch:
Come and join us on the Propeller IRC channel for fast and easy help!
Channel: #propeller
Server: irc.freenode.net or freenode.net
If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
Any task could write directly to $004..$01F, though, if they wanted. Getting to the real $000..$003 is impossible, though, unless you're task 0.
One subtle thing about this scheme is that if you only have three tasks (0..2), the funny business would end at $00B, in the above·case, instead of clobbering some entire power-of-2 range. I think it will be helpful, also, to have an instruction which sets the limit on number of tasks, so that an arbitrary lid could be kept on things.
Could 8 tasks actually run without affecting overall spin speed?
With only one task running would spin act the same as we know now?
It seems a shame to not have a faster spin option when only running one task.
One thought of mine that has to do the some of the waitxxx options in spin is that it could be multitasked fairly easily if one was willing to shed a little clock cycle accuracy. I have run into using a repeat until ina[noparse][[/noparse]pinx] a number of times when I didn't want to lock the cog up. A specialized repeat or something of that nature would fill the bill for me in many instances.
The instruction pipeline can be more tightly interleaved, due to the four-port RAM. At each clock cycle, three reads and one write — all to different addresses — can take place simultaneously.
tpw_man said...
@Chip
Nice! I think I would like it and use it, but all this multitasking/threading stuff kinda scares me in that the simplicity will evaporate.
The simplicity's still there. All these new things are just extras. Think of them as·new tools sitting quietly in·the toolbox. We can put them to use whenever we're ready to.
There is a problem for us stretch-it-to-the-limit types, though: if the limits are way out there, we might go crazy trying to stretch things to them·(I hate chess for this reason - my brain is current-limited and chess·presents a giant 'short' - oh, and those folks that are 'good' at·chess are usually 'good' just because they memorized a lot of moves and tactics, not because they are thinking creatively·-·It's just erudite smugness).
So far, the Propeller has been simple, but flexible, and people have made great sport of getting it to·do neat things. I·wouldn't want·to upset that balance, so whatever we add to it will have to be useful, fun, and done in the most seamless way possible - no warts, or things you must go around to get something done. So, try not to worry. I don't want it to get hosed up, either.
In the late 1980's, I really wanted to learn to program Windows so that we could start making our 8051 tools into Windows applications. I bought·some object-oriented Borland development system which seemed to be the Holy Grail -- we would program in this cutting-edge object paradigm and create cool Windows applications. Anyway, being·pumped full of propaganda about 'object-oriented programming', I dove in. I was overwhelmed trying to figure out how polymorphism ('bees are bugs that have wings, ants are bugs without wings - but they are all bugs - hence they 'descend' from a common 'ancestor' and', bla, bla, bla..)·WAS GOING to be applied to something like an 8051 assembler. I actually thought that there was no·way around objects in this new world of programming - objects were now the singular means of achieving any solution. But..... HOW??? I was so tied up in knots over all this, that I just abandoned·the whole thing·and went back to 80x86 assembler, as it made sense. Years later, I realized that objects had been COMPLETELY over-prescribed in that book I was reading. It was almost brain-damaging. My point is that we shouldn't think that some new feature dictates HOW something must get done. All these new things do is provide improved efficiency for solving certain problems. They don't need to overwhelm anybody or get in their way.
It's too bad the Propeller can't be taught in the same method a modern video game is. If you've every played some complex game on an XBox you'll witness how a lot can be conveyed incrementally, without even a manual. You build up, bit by bit, as you do new things in the game.
So with four tasks the pipeline would normally have one stage of one instruction from each task in it? Or does tasking disable pipelining?
If the pipe is filled with different stages of different tasks, this is VERY cool, as we could potentially run 64 hardware threads total on the eight cogs.
I am very curious how hub access would play out; from other messages it looks like waitcnt and waitpeq et al would work just fine.
Best,
Bill
Chip Gracey (Parallax) said...
Proposed Cog Multitasking
a) There are EIGHT potential tasks per cog.
b) A task is an execution time slot that has its own PC/Z/C.
c) Initially, only task 0 is active (normal mode).
d) As soon as a 'TASKNEW D' instruction is executed, the next available task is begun at address D. C=1 if no free task was available.
e) Execution proceeds from one task to the next, looping.
f) Empty task slots are skipped and given no time.
f) There are two modes in which all tasks must collectively operate: either 'single-instruction' or 'threaded'.
In single-instruction mode, tasks switch after each instruction.
In threaded mode, tasks switch only after a 'TASKNXT' instruction.
g) A task may execute 'TASKID D' to learn its task number.
h) When a task executes a 'TASKEND' instruction, it is shut down and its task slot becomes available for reassignment via another 'TASKNEW D'.
i) A subtle register re-mapping scheme will allow the same code to execute on multiple tasks while mainting unique variables.
Clumps of registers actually spanning $000..$0FF can be addressed via a lower range, whereby the task ID will be substituted for the upper address bits.
A 'TASKREG [noparse][[/noparse]mode,n]' instruction will set up single-instruction/threaded mode and the register clump granularity.
bambino said...
160Mips with a 160 Mhz clock? What am I missing here? Generally I would figure a 4 clock cycle and that would equate to 40 MIPs.
To provide background on Phil's comments, the current Propeller actually has a·5 stages of execution: Fetch Instruction, Fetch Source, Fetch Destination, Execute Instruction and Write Result, but it's structured so that when the current instruction is executing the next instruction is fetched, this makes maximum use of the single port SRAM and improves it from 5 clocks/instruction to 4.
The pipeline for the next Propeller will do even more overlapping so that every instruction appears to operate in 1 clock cycle. The logic for the pipeline is more complex because you can end up with code sequences where the information you need isn't availible yet. To illustate this look at the following code:
...
MOV Var, #0
.. (more than 4 instructions later)
ADD Var, #1
ADD Var, #1
Now the result should by 2 (0 + 1 + 1), but without doing some fancy footwork with how the pipeline works the result would equal 1. Here a crude representation of the pipeline: ·
ISDeR
ISDeR
ISDeR
....
I = fetch instruction
S = fetch source
D = fetch destination
e = let the ALU settle (execute)
R = write results
The answer of 1 from the first·ADD isn't known until the begining of it's Result stage, but that location is accessed by the second ADD in it's destination stage. Because that location isn't updated until the clock cycle after it's needed by the second ADD, special things must be done keep things working like they should.
But this is all hidden from the programmer, really only the unaccounted for side effects must be known about, which is quite few. The only side effect on the current Propeller's slight overlapping·is the requirement of an intervening instruction between an instruction modification and executing that instruction.
Chip Gracey (Parallax) said...
So far, the Propeller has been simple, but flexible, and people have made great sport of getting it to do neat things. I wouldn't want to upset that balance, so whatever we add to it will have to be useful, fun, and done in the most seamless way possible - no warts, or things you must go around to get something done..
That certainly seems to be the case with the multi-tasking options - very simple, very impressive, well done. That gives an effective 8x8=64 Virtual Cog LMM so with that I'd be happy for the Prop II to be 8 cog + lots of memory.
"It's too bad the Propeller can't be taught in the same method a modern video game is."
I think it can. There is absolutely no reason why this discussion is even relevant to the new Propeller user. They can do the obvious thing we all did, and just use COGs as they need to use them. Eventually, a barrier is reached and other engineering is there for them.
Prop I works this way now. Prop II is going to continue that, from all I see here.
The biggest thing is some time and more experience in the presentation. For the most part, the design is very discoverable. Applying can be a headache, or challenge depending on mood and deadline, but that's true of a lot of stuff!
Over time, more educators and enthusists are going to continue to contribute toward this and "Propeller for Dummies" or "Adventures" will appear and be useful. It's just new, and it's gonna get newer!
My only mistake if You incorporate SERIN/SEROUT You must loock it to one task
Ps. Reload counters dito. Type TASKID n.
The way things are shaping up, each task (including the native task 0) will have some of its own flipflops to define what it is (potentially) waiting for. This way, WAITCNT, WAITPEQ, and WAITPNE·can be supported for threads, without hanging the whole cog.
I can't see any benefit to locking any tasks to particular purposes, as timing is all over the place, anyway, for any task.
Chip Gracey (Parallax) said... ·oh, and those folks that are 'good' at·chess are usually 'good' just because they memorized a lot of moves and tactics, not because they are thinking creatively·-·It's just erudite smugness).
Ok, now I have to say something!· You're wrong about chess!· Yes, you can make yourself a lot better by memorizing good beginnings and endings, but not even computers can memorize what to do in the middle of the game, it's just too complex.· And, applying learned tactics to new situations is exactly what creativity is about!
Chip Gracey (Parallax) said...
The simplicity's still there. All these new things are just extras. Think of them as·new tools sitting quietly in·the toolbox. We can put them to use whenever we're ready to.
...
Gee Chip, that and all that follows was nicely conceived.·I don't play Xbox, but I'm sure that paragraph plays good to those who do.·I also lived through some of that Borland trama but came out of it relatively unscathed. My final observation (other than the poorly done tool-chain) was that someone had too much time on their hands and growing memory and/or swap was just a challenge to be filled. Yes, it was lots of hype just like everything else someone is trying to sell from diapers to demagoguery.
Your task switching strategy looks fine. It's also nice you·posited that WAITCNT can be maintained syntactically·as a degenerate TASKSLP for some legacy support. Being able to move from one chip to another with just detecting the type rather than using a wholesale replacement of tool set would be nice ... although it is entirely possible that this product might end up with some other market·position besides Propeller-II.
My point on it was at in one instruction mode 2 tasks can give problem in sending and receiving (Only one task can do it).
It is not problem in IO, WAITCNT, WAITPEQ, and WAITPNE al these task not edit port value.
Samt if I write to counter one value in 1 task and other value in supose 3 task it can be very bad.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
Chip Gracey (Parallax) said... ·oh, and those folks that are 'good' at·chess are usually 'good' just because they memorized a lot of moves and tactics, not because they are thinking creatively·-·It's just erudite smugness).
Ok, now I have to say something!· You're wrong about chess!· Yes, you can make yourself a lot better by memorizing good beginnings and endings, but not even computers can memorize what to do in the middle of the game, it's just too complex.· And, applying learned tactics to new situations is exactly what creativity is about!
Okay. You're right.·I overstated the matter. I do think that game is a recipe for madness, though.
My point on it was at in one instruction mode 2 tasks can give problem in sending and receiving (Only one task can do it).
It is not problem in IO, WAITCNT, WAITPEQ, and WAITPNE al these task not edit port value.
Samt if I write to counter one value in 1 task and other value in supose 3 task it can be very bad.
Oh, I see what you're saying. I think you would just have to write the code so that different threads don't try to use the same resource, like a CTR, for example. If any code tried to do otherwise, it would be as senseless as multiple programs trying to manipulate a single I/O pin at the same time. You just have to avoid this by intent.
About having separate flipflops for maintaing what each task is WAITing for: I think it only makes sense to do this for WAITCNT, if anything. Afterall, it is only a few-instructions to·replace this hardware function·in software. The big benefit to doing this in hardware is being able to turn clocks back over to other active tasks, and in a best case, have all tasks in WAITCNTs so that cog power consumption can finally drop. First, I must get the multitasking working, then approach this secondary issue.
Yes. You are corect. CRT Serial-IO is context sensitive.
Sorry if I are obtrusive
You are not obtrusive, at all. I know English is not your first (or even 4th) language. You're doing fine, though, and I'm glad you're interested in the Propeller's future.
Would it be possible for a sleeping threads (one waiting for waitcnt, waitpne, waitpeq) execution slice to be freed up for the other threads when its sleeping?
ie if there are only two threads on a cog, and one of them is waiting for a pin, can the other thread grab all the cycles?
If so, guess what, we have close to zero latency free interrupt equivalents!
ie something like: (sorry for the messed up syntax, its been a while)
tasknew ra
tasknew rb
' main task on cog, no cycles taken by waiting threads
This would give the same capability, but more general purpose, as interrupts, and I suspect other than a few lost cycles here and there it should be possible to free up the cycles spend waiting by inactive threads.
Best,
Bill
Chip Gracey (Parallax) said...
About having separate flipflops for maintaing what each task is WAITing for: I think it only makes sense to do this for WAITCNT, if anything. Afterall, it is only a few-instructions to replace this hardware function in software. The big benefit to doing this in hardware is being able to turn clocks back over to other active tasks, and in a best case, have all tasks in WAITCNTs so that cog power consumption can finally drop. First, I must get the multitasking working, then approach this secondary issue.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ www.mikronauts.com - a new blog about microcontrollers
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 9/1/2008 8:35:28 PM GMT
a) There are EIGHT potential tasks per cog.
b) A task is an execution time slot that has its own PC/Z/C.
c) Initially, only task 0 is active (normal mode).
d) As soon as a 'TASKNEW D' instruction is executed, the next available task is begun at address D. C=1 if no free task was available.
e) Execution proceeds from one task to the next, looping.
f) Empty task slots are skipped and given no time.
f) There are two modes in which all tasks must collectively operate: either 'single-instruction' or 'threaded'.
···· In single-instruction mode, tasks switch after each instruction.
···· In threaded mode, tasks switch only after a 'TASKNXT' instruction.
g) A task may execute 'TASKID D' to learn its task number.
h) When a task executes a 'TASKEND' instruction, it is shut down and its task slot becomes available for reassignment via another 'TASKNEW D'.
i) A subtle register re-mapping scheme will allow the same code to execute on multiple tasks while mainting unique variables.
···· Clumps of registers actually spanning $000..$0FF can be addressed via·a lower range, whereby the task ID will be substituted for the upper address bits.
···· A 'TASKREG [noparse][[/noparse]mode,n]' instruction will set up single-instruction/threaded mode and the register clump granularity.
·····Register remapping detail (n = TASKREG mode setting, ttt = task id)
··········· bank· I/S/D··· ··substitute
······· n·· size· address··· address
·······
······· 0·· 1···· 000000000· %000000ttt
······· 1·· 2···· 00000000x· %00000tttx
······· 2·· 4···· 0000000xx· %0000tttxx
······· 3·· 8···· 000000xxx· %000tttxxx
······· 4·· 16··· 00000xxxx· %00tttxxxx
······· 5·· 32··· 0000xxxxx· %0tttxxxxx
······· 6·· 64··· 000xxxxxx· %0ttxxxxxx· (limited to 4 tasks)
······· 7·· 128·· 00xxxxxxx· %0txxxxxxx· (limited to 2 tasks)
······· You can see that under normal, single-task cog operation, this remapping scheme will have no effect, as ttt=0.
······ ·These remapped registers can be used for anything, including variables, return addresses, code, etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Is this be Spin, ASM or both?
James
So, it seems like this new definition could be seemlessly implemented, as it only internally redefines what WAITCNT does. No need to change the name, then. It would be nice if all this tasking could be handled generically, and not as any kind of exceptional circumstance. The cogs are just multitasking. Period. They just start up with one task -- kind of like the Propeller starts up with one cog.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
'Love your tasking proposal! And the register banking is brilliant! It completely satisfies any objectives that overlays might have accomplished, but a lot more cleanly. Just to make sure I understand: when n is set to 2, for example, only addresses $000 - $01F are affected by the banking scheme, right?
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Nice scheme ... both the sharing of memory and Phil's tasking instructions. The default case looks like the current Prop I system and it cleanly expands by powers of 2 to 8 threads with either LMM-type multitasking or multi-threading. The thread related banking solves the issue of how to easily maintain separate variables for each thread.
Nice! I think I would like it and use it, but all this multitasking/threading stuff kinda scares me in that the simplicity will evaporate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I am 1011, so be surprised!
Advertisement sponsored by dfletch:
Come and join us on the Propeller IRC channel for fast and easy help!
Channel: #propeller
Server: irc.freenode.net or freenode.net
If you don't want to bother installing an IRC client, use Mibbit. www.mibbit.com
task 0: $000..$003
task 1: $004..$007
task 2: $008..$00B
task 3: $00C..$00F
task 4: $010..$013
task 5: $014..$017
task 6: $018..$01B
task 7: $01C..$01F
Any task could write directly to $004..$01F, though, if they wanted. Getting to the real $000..$003 is impossible, though, unless you're task 0.
One subtle thing about this scheme is that if you only have three tasks (0..2), the funny business would end at $00B, in the above·case, instead of clobbering some entire power-of-2 range. I think it will be helpful, also, to have an instruction which sets the limit on number of tasks, so that an arbitrary lid could be kept on things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
My only mistake if You incorporate SERIN/SEROUT You must loock it to one task
Ps. Reload counters dito. Type TASKID n.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 9/1/2008 9:51:16 PM GMT
Could 8 tasks actually run without affecting overall spin speed?
With only one task running would spin act the same as we know now?
It seems a shame to not have a faster spin option when only running one task.
One thought of mine that has to do the some of the waitxxx options in spin is that it could be multitasked fairly easily if one was willing to shed a little clock cycle accuracy. I have run into using a repeat until ina[noparse][[/noparse]pinx] a number of times when I didn't want to lock the cog up. A specialized repeat or something of that nature would fill the bill for me in many instances.
The instruction pipeline can be more tightly interleaved, due to the four-port RAM. At each clock cycle, three reads and one write — all to different addresses — can take place simultaneously.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
There is a problem for us stretch-it-to-the-limit types, though: if the limits are way out there, we might go crazy trying to stretch things to them·(I hate chess for this reason - my brain is current-limited and chess·presents a giant 'short' - oh, and those folks that are 'good' at·chess are usually 'good' just because they memorized a lot of moves and tactics, not because they are thinking creatively·-·It's just erudite smugness).
So far, the Propeller has been simple, but flexible, and people have made great sport of getting it to·do neat things. I·wouldn't want·to upset that balance, so whatever we add to it will have to be useful, fun, and done in the most seamless way possible - no warts, or things you must go around to get something done. So, try not to worry. I don't want it to get hosed up, either.
In the late 1980's, I really wanted to learn to program Windows so that we could start making our 8051 tools into Windows applications. I bought·some object-oriented Borland development system which seemed to be the Holy Grail -- we would program in this cutting-edge object paradigm and create cool Windows applications. Anyway, being·pumped full of propaganda about 'object-oriented programming', I dove in. I was overwhelmed trying to figure out how polymorphism ('bees are bugs that have wings, ants are bugs without wings - but they are all bugs - hence they 'descend' from a common 'ancestor' and', bla, bla, bla..)·WAS GOING to be applied to something like an 8051 assembler. I actually thought that there was no·way around objects in this new world of programming - objects were now the singular means of achieving any solution. But..... HOW??? I was so tied up in knots over all this, that I just abandoned·the whole thing·and went back to 80x86 assembler, as it made sense. Years later, I realized that objects had been COMPLETELY over-prescribed in that book I was reading. It was almost brain-damaging. My point is that we shouldn't think that some new feature dictates HOW something must get done. All these new things do is provide improved efficiency for solving certain problems. They don't need to overwhelm anybody or get in their way.
It's too bad the Propeller can't be taught in the same method a modern video game is. If you've every played some complex game on an XBox you'll witness how a lot can be conveyed incrementally, without even a manual. You build up, bit by bit, as you do new things in the game.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
So with four tasks the pipeline would normally have one stage of one instruction from each task in it? Or does tasking disable pipelining?
If the pipe is filled with different stages of different tasks, this is VERY cool, as we could potentially run 64 hardware threads total on the eight cogs.
I am very curious how hub access would play out; from other messages it looks like waitcnt and waitpeq et al would work just fine.
Best,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
The pipeline for the next Propeller will do even more overlapping so that every instruction appears to operate in 1 clock cycle. The logic for the pipeline is more complex because you can end up with code sequences where the information you need isn't availible yet. To illustate this look at the following code:
Now the result should by 2 (0 + 1 + 1), but without doing some fancy footwork with how the pipeline works the result would equal 1. Here a crude representation of the pipeline:
·
The answer of 1 from the first·ADD isn't known until the begining of it's Result stage, but that location is accessed by the second ADD in it's destination stage. Because that location isn't updated until the clock cycle after it's needed by the second ADD, special things must be done keep things working like they should.
But this is all hidden from the programmer, really only the unaccounted for side effects must be known about, which is quite few. The only side effect on the current Propeller's slight overlapping·is the requirement of an intervening instruction between an instruction modification and executing that instruction.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Post Edited (Paul Baker (Parallax)) : 9/2/2008 3:09:26 AM GMT
That certainly seems to be the case with the multi-tasking options - very simple, very impressive, well done. That gives an effective 8x8=64 Virtual Cog LMM so with that I'd be happy for the Prop II to be 8 cog + lots of memory.
My English is to bad to talk on programings skill sorry.
I hop so You understand My posts and if not at You talk to My to explain it.
Sorry at then post is litle of topic
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I think it can. There is absolutely no reason why this discussion is even relevant to the new Propeller user. They can do the obvious thing we all did, and just use COGs as they need to use them. Eventually, a barrier is reached and other engineering is there for them.
Prop I works this way now. Prop II is going to continue that, from all I see here.
The biggest thing is some time and more experience in the presentation. For the most part, the design is very discoverable. Applying can be a headache, or challenge depending on mood and deadline, but that's true of a lot of stuff!
Over time, more educators and enthusists are going to continue to contribute toward this and "Propeller for Dummies" or "Adventures" will appear and be useful. It's just new, and it's gonna get newer!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Yes that would indeed need to be Bold Face typed in any manuel you come up with!
I can't see any benefit to locking any tasks to particular purposes, as timing is all over the place, anyway, for any task.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Your task switching strategy looks fine. It's also nice you·posited that WAITCNT can be maintained syntactically·as a degenerate TASKSLP for some legacy support. Being able to move from one chip to another with just detecting the type rather than using a wholesale replacement of tool set would be nice ... although it is entirely possible that this product might end up with some other market·position besides Propeller-II.
Good luck.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
My point on it was at in one instruction mode 2 tasks can give problem in sending and receiving (Only one task can do it).
It is not problem in IO, WAITCNT, WAITPEQ, and WAITPNE al these task not edit port value.
Samt if I write to counter one value in 1 task and other value in supose 3 task it can be very bad.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Yes. You are corect. CRT Serial-IO is context sensitive.
Sorry if I are obtrusive
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Would it be possible for a sleeping threads (one waiting for waitcnt, waitpne, waitpeq) execution slice to be freed up for the other threads when its sleeping?
ie if there are only two threads on a cog, and one of them is waiting for a pin, can the other thread grab all the cycles?
If so, guess what, we have close to zero latency free interrupt equivalents!
ie something like: (sorry for the messed up syntax, its been a while)
tasknew ra
tasknew rb
' main task on cog, no cycles taken by waiting threads
ra: ' myint handler
waitpeq ina,#myint
' handle virtual interrupt
jmp #ra
rb: ' my2ndint handler
waitpeq ina,#my2ndint
jmp #rb
This would give the same capability, but more general purpose, as interrupts, and I suspect other than a few lost cycles here and there it should be possible to free up the cycles spend waiting by inactive threads.
Best,
Bill
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers
You and most of the guys posting know way more about this than I ever will. You build it, and I know I'll like it.
I love my Propeller (and all my·Parallax goodies)·and I am just starting out. Thanks for all you put into this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Whit+
"We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney
Post Edited (Whit) : 9/2/2008 12:48:20 PM GMT