Things are happening so fast, and my mind was so caught up in my own ideas, I completely missed the point Chip's cooperative multitasking suggestion four pages back, as an alternative to interleaved multi-threading. (At least I think that was the intent of the TASKxxx commands.) 'Sorry, Chip!
Now that I've taken the time to read it, I really like it. Let me make sure I understand:
····There's a hardware-supported four-task queue that holds a "live" bit, Z, C, and the PC for each task.
····TASKNEW D adds a task at D to the four-task (max) round-robin queue. (Sets C on wc if there's no slot available?) ····TASKID D returns the id (0, 1, 2, or 3) of the running task in D. ····TASKEND ends the current task and removes it from the queue.
I wonder if we need one more command:
····TASKNXT passes control to the next task but doesn't get evicted from the queue.
Also, I assume that something like TASKNEW D,S, with S being the task address and D returning the task id is out because you're using a HUBOP, right?
Chip, are you thinking of including both this mechanism and the SWAPZC command, or is this an either/or choice? I'd probably forgo the latter if I had to choose.
Supose if COG has fast SERIN/OUT.
It is in You construction rom to Run LMM directly on serial IN?
I didn't understand this at first, but simonl noticed something, so I looked closer. Sapieha, you are talking about streaming in multi-threaded code and executing it very fast, right?
Phil Pilgrim (PhiPi) said...
Things are happening so fast, and my mind was so caught up in my own ideas, I completely missed the point Chip's cooperative multitasking suggestion four pages back, as an alternative to interleaved multi-threading. (At least I think that was the intent of the TASKxxx commands.) 'Sorry, Chip!
Now that I've taken the time to read it, I really like it. Let me make sure I understand:
····There's a hardware-supported four-task queue that holds a "live" bit, Z, C, and the PC for each task.
····TASKNEW D adds a task at D to the four-task (max) round-robin queue. (Sets C on wc if there's no slot available?) ····TASKID D returns the id (0, 1, 2, or 3) of the running task in D. ····TASKEND ends the current task and removes it from the queue.
I wonder if we need one more command:
····TASKNXT passes control to the next task but doesn't get evicted from the queue.
Also, I assume that something like TASKNEW D,S, with S being the task address and D returning the task id is out because you're using a HUBOP, right?
Chip, are you thinking of including both this mechanism and the SWAPZC command, or is this an either/or choice? I'd probably forgo the latter if I had to choose.
Thanks,
Phil
Phil, we could do both TASKNEW, etc. and SWAPZC, so you could do things however you'd like. They're both not expensive to implement. Also, if we made simple bit-substitution banking (same mechanism as indirect), we could do even more. Of course, the TASK instructions would provide the highest performance, as there's no intervening software required. And none of these are HUBOPs, they're all %000110 instructions (was slated for ENC), so they are single-cycle.
One of aspects in fault tolerant system is to test cores for fault ( IO RAM CPU ) name it.
And byte of core with faul.
With only smal comand set and protokol
And it is very handy method.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Chip Gracey said...
And none of these are HUBOPs, they're all %000110 instructions (was slated for ENC), so they are single-cycle.
Got it! I assume that, as in the HUBOPs, S is being used as an opcode extension, which rules out its use as an operand, right? (Those bits have gotta go somewhere! )
· I just read something interesting that sounds alot like the current propeller, minus the DMA.·
·· ·· Quoting wikipedia
As an example usage of DMA in a multiprocessor-system-on-chip, IBM/Sony/Toshiba's Cell processor incorporates a DMA engine for each of its 9 processing elements including one power-processor element (PPE) and eight synergistic processor elements (SPEs). Since the SPE's load/store instructions can read/write only its own local memory, an SPE entirely depends on DMAs to transfer data to and from the main memory and local memories of other SPEs. Thus the DMA acts as a primary means of data transfer among cores inside this CPU (in contrast to cache-coherent CMP architectures such as Intel's coming general-purpose GPU, Larrabee).
DMA in Cell is fully cache coherent (note however local stores of SPEs operated upon by DMA do not act as globally coherent cache in the standard sense). In both read ("get") and write ("put"), a DMA command can transfer either a single block area of size up to 16KB, or a list of 2 to 2048 such blocks. The DMA command is issued by specifying a pair of a local address and a remote address: for example when a SPE program issues a put DMA command, it specifies an address of its own local memory as the source and a virtual memory address (pointing to either the main memory or the local memory of another SPE) as the target, together with a block size. According to a recent experiment, an effective peak performance of DMA in Cell (3 GHz, under uniform traffic) reaches 200GB per second.[noparse][[/noparse]5] ····Do we have·virtual memory addresses currently?
··· P.S. you have mail in your mailbox [noparse]:)[/noparse]
A question about TASKxxx. When the cog starts, would the foreground program automatically be task 0? Or would the first TASKNEW transfer control to the task manager, not to return until the task queue is empty again? If the foreground program is task 0, will there be a mechanism to force a COGSTOP when the task queue becomes empty? Or would task 0 simply not be allowed to END itself?
Sapieha,
This has been discussed before. The only ROM that it is possible to have is either masked ROM or a small amount of fusible link type OTP (like one 32-bit register). The fusible link ROM takes a lot of chip area to implement.
Correct, OTP is EPROM without a means to erase it. We will not be using a process which supports (E)EPROM. We will be implementing code protection which will address 90% of customer's desires.
This list seemed to be growing faster than I could read it.....
I did finally find the end and now I have a few comments.
Chip, Please don't take any of the rants personally.
I love the work You have done, The PROP is the best micro I have ever had the pleasure to develop on.
The fact that you ask your customers what we want on the next PROP is phenomenal.
[noparse][[/noparse]RANT 1]
I am disappointed that the COG count may now be 8 and not 16...
On More that a quarter of the projects I've built so far I have had to stitch together two or more COG programs to fit within the 8 COG PROP.
It was interesting and even fun(I love a challenge.) but it was also very time consuming.
It complicated my code immensely , to the point that in one of those projects I had to write pages of comments just to document how I got it all to fit.
Now theirs nothing wrong with documentation but the hole point of the Propeller is SIMPLICITY.
At 160 MHz and TACK it will be much eraser to do this for my CURRENT Projects, But buy the time Prop II is released I was hoping to have 16 COGs to help simplify and speed up my future projects.
IF fast serial communication between two COGs works well than This is less of a concern, BUT I cant see how 2 x PROP II (8 COGS) costs less than 1x PROP II (16 COGS).
[noparse][[/noparse]RANT 2]
If I read this wrong please let me know.
It looks like "cache-line memory" was what was proposed to mitigate the HUB access bottle neck and now it is NOT going to be in PROP II?
With the hard limit of < 512 Longs per COG for Data/Code, moving both in/out of the COG is very impotent.
I'm not an expert on LMM, but moving 8 longs in/out of a COG per HUB access should really help the speed hit you get for LMMs?
My hope is to use the PROP II on a 10/100 Mbs Ethernet link, and moving lots of data in/out of the COGs is needed.
(Other COGs would assemble and disassemble packets.)
[noparse][[/noparse]RANT 3]
Asking our opinions on the Next PROP Is the coolest thing ever!!!.
I was hoping to have one this year...(You never gave me cause to think I would... Just hoping)
It doesn't sound very likely.
Can you give us a Pessimistic and an Optimistic guess on when PROP II will be available?( I wont hold you to it... really... NO REALLY...)
[noparse][[/noparse]END RANTS]
Chip can you tell us more about the de/serializer hardware.
What speed do you think it will work at?
Anything else you can tell us about the PROP II would be great!
It seems like I find My self behine the " 8 BALL " w/ ever chip I get used to., Is it fina$$. possiable in todays market to make both?????......I really really like the BS2. Its simplicity ( Its in BASIC$$$)YAE!!!) , Its got a great EDITOR/COMPILER, But its a tad slow, And some of the things I come up w/ need a little more speed. This is were the Propeller comes in. Its hard for me to write in (spin,ASM),But Im tring hard to learn the new Platform....Know I see this (the PROP change) and I get disgruntuled
If a "CHANGE" is do, why not make it for the better. The U.S.of A.put a MAN on the MOON!!!, Then it made the BS2...HotRod the Propeller but remember the MOON and the BS2!!!!!!!!!!!!!!!!!!!!!!!!!!_WMc$_----8/29/08
Program.
Code1.· = Init Code
Code2.· = Run Code
Codex.· = END, Test etc...
All has same global variables.
Cog starts with Code1
Code1 ends its run
Reload Code2 wiht Global variables stil in COG
Code2 ends its run
Reload Codex wiht Global variables stil in COG
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty.
I see you want code "overlays" in part of the cog RAM all working on the same data set, also in, a different part of, COG RAM.
I have also felt a need for this.
Looks like with the Prop IIs proposed repeat instruction (REP) and auto-incrementing/decrementing pointers this could easily be done without stopping the COG and restarting it with new overlay code. Just add code to the end of each overlay section to load and run the next section. Should be about as quick using the instructions and addressing modes and not take very many instructions at that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I know its currently limited by 9 bits of addressing, but there has to
be an elegant way to accomplish this to provide more instruction
space, or at least more local ram.
I would say that I am amazed what you can do with ~496 longs.
There really is no elegant way to expand the cog's addressing space.
There are many techniques for doing this, but they're all sloppy / messy / far far from elegant.
Remember also that any cog RAM has to be replicated by 8 or 16.
It's just not going to happen.
"Overlay" was the name used in the bad old days of programming the IPM PC when our code + data was too big to fit in the 640K memory limit of that ghastly machine. There would be a small section of permanently resident code, in low memory, which would load other parts of code to higher memory as and when needed. Data/Stack etc would be at top of RAM.
This was often done with a so called "overlaying" linker that would add code to some of your function calls (From say C or PLM) to automatically load the overlays from disk, over writing other currently unused sections of code.
You had to organize your program carefully to make sure interrelated functions were in the right sections.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The "old days" were just fine. They went "bad" when IBM introduced the PC with it's Intel segmented architecture, MSDOS and... well we just hated it. Prior to that the company I worked for designed and built it's own CPUs for embedded systems (Radar). Had it's own operating system etc etc.
Oops: Off topic again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
--Steve
My thinking have hyperthreading.
Its My hobby and in my work with computers start with first IMSAI have help me to overcome many problems.
My motto "Think 1 time for att have no more that 10 minute work"
Ps. Tack in swidish >Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
tack–noun
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Now that I've taken the time to read it, I really like it. Let me make sure I understand:
····There's a hardware-supported four-task queue that holds a "live" bit, Z, C, and the PC for each task.
····TASKNEW D adds a task at D to the four-task (max) round-robin queue. (Sets C on wc if there's no slot available?)
····TASKID D returns the id (0, 1, 2, or 3) of the running task in D.
····TASKEND ends the current task and removes it from the queue.
I wonder if we need one more command:
····TASKNXT passes control to the next task but doesn't get evicted from the queue.
Also, I assume that something like TASKNEW D,S, with S being the task address and D returning the task id is out because you're using a HUBOP, right?
Chip, are you thinking of including both this mechanism and the SWAPZC command, or is this an either/or choice? I'd probably forgo the latter if I had to choose.
Thanks,
Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
What code protection option(s) will the Prop2 have?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Mike
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Yes it is only idea.
PropII >Master Has Code.
PropII >Slave start it.
1. Master send start adres
2. Slawe executes and send next adres to master.
3 Master send next code .... and so on
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
One of aspects in fault tolerant system is to test cores for fault ( IO RAM CPU ) name it.
And byte of core with faul.
With only smal comand set and protokol
And it is very handy method.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Post Edited (Sapieha) : 9/25/2008 12:14:52 PM GMT
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
··
·· Quoting wikipedia
As an example usage of DMA in a multiprocessor-system-on-chip, IBM/Sony/Toshiba's Cell processor incorporates a DMA engine for each of its 9 processing elements including one power-processor element (PPE) and eight synergistic processor elements (SPEs). Since the SPE's load/store instructions can read/write only its own local memory, an SPE entirely depends on DMAs to transfer data to and from the main memory and local memories of other SPEs. Thus the DMA acts as a primary means of data transfer among cores inside this CPU (in contrast to cache-coherent CMP architectures such as Intel's coming general-purpose GPU, Larrabee).
DMA in Cell is fully cache coherent (note however local stores of SPEs operated upon by DMA do not act as globally coherent cache in the standard sense). In both read ("get") and write ("put"), a DMA command can transfer either a single block area of size up to 16KB, or a list of 2 to 2048 such blocks. The DMA command is issued by specifying a pair of a local address and a remote address: for example when a SPE program issues a put DMA command, it specifies an address of its own local memory as the source and a virtual memory address (pointing to either the main memory or the local memory of another SPE) as the target, together with a block size. According to a recent experiment, an effective peak performance of DMA in Cell (3 GHz, under uniform traffic) reaches 200GB per second.[noparse][[/noparse]5]
····Do we have·virtual memory addresses currently?
··· P.S. you have mail in your mailbox [noparse]:)[/noparse]
A question about TASKxxx. When the cog starts, would the foreground program automatically be task 0? Or would the first TASKNEW transfer control to the task manager, not to return until the task queue is empty again? If the foreground program is task 0, will there be a mechanism to force a COGSTOP when the task queue becomes empty? Or would task 0 simply not be allowed to END itself?
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
I have one technical question on You chip technology?
It is possible in it have OTP rom?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
This has been discussed before. The only ROM that it is possible to have is either masked ROM or a small amount of fusible link type OTP (like one 32-bit register). The fusible link ROM takes a lot of chip area to implement.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I did finally find the end and now I have a few comments.
Chip, Please don't take any of the rants personally.
I love the work You have done, The PROP is the best micro I have ever had the pleasure to develop on.
The fact that you ask your customers what we want on the next PROP is phenomenal.
[noparse][[/noparse]RANT 1]
I am disappointed that the COG count may now be 8 and not 16...
On More that a quarter of the projects I've built so far I have had to stitch together two or more COG programs to fit within the 8 COG PROP.
It was interesting and even fun(I love a challenge.) but it was also very time consuming.
It complicated my code immensely , to the point that in one of those projects I had to write pages of comments just to document how I got it all to fit.
Now theirs nothing wrong with documentation but the hole point of the Propeller is SIMPLICITY.
At 160 MHz and TACK it will be much eraser to do this for my CURRENT Projects, But buy the time Prop II is released I was hoping to have 16 COGs to help simplify and speed up my future projects.
IF fast serial communication between two COGs works well than This is less of a concern, BUT I cant see how 2 x PROP II (8 COGS) costs less than 1x PROP II (16 COGS).
[noparse][[/noparse]RANT 2]
If I read this wrong please let me know.
It looks like "cache-line memory" was what was proposed to mitigate the HUB access bottle neck and now it is NOT going to be in PROP II?
With the hard limit of < 512 Longs per COG for Data/Code, moving both in/out of the COG is very impotent.
I'm not an expert on LMM, but moving 8 longs in/out of a COG per HUB access should really help the speed hit you get for LMMs?
My hope is to use the PROP II on a 10/100 Mbs Ethernet link, and moving lots of data in/out of the COGs is needed.
(Other COGs would assemble and disassemble packets.)
[noparse][[/noparse]RANT 3]
Asking our opinions on the Next PROP Is the coolest thing ever!!!.
I was hoping to have one this year...(You never gave me cause to think I would... Just hoping)
It doesn't sound very likely.
Can you give us a Pessimistic and an Optimistic guess on when PROP II will be available?( I wont hold you to it... really... NO REALLY...)
[noparse][[/noparse]END RANTS]
Chip can you tell us more about the de/serializer hardware.
What speed do you think it will work at?
Anything else you can tell us about the PROP II would be great!
Thanks Chip,
I love your work!
LewisD
If a "CHANGE" is do, why not make it for the better. The U.S.of A.put a MAN on the MOON!!!, Then it made the BS2...HotRod the Propeller but remember the MOON and the BS2!!!!!!!!!!!!!!!!!!!!!!!!!!_WMc$_----8/29/08
Thanks
I mised that discussion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
I have question on COGNEW instruction.
It load entire COG.
My question. It is posible to ad possiblity to load only X longs?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
COG = code + variables
Program.
Code1.· = Init Code
Code2.· = Run Code
Codex.· = END, Test etc...
All has same global variables.
Cog starts with Code1
Code1 ends its run
Reload Code2 wiht Global variables stil in COG
Code2 ends its run
Reload Codex wiht Global variables stil in COG
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 8/30/2008 1:41:42 PM GMT
I see you want code "overlays" in part of the cog RAM all working on the same data set, also in, a different part of, COG RAM.
I have also felt a need for this.
Looks like with the Prop IIs proposed repeat instruction (REP) and auto-incrementing/decrementing pointers this could easily be done without stopping the COG and restarting it with new overlay code. Just add code to the end of each overlay section to load and run the next section. Should be about as quick using the instructions and addressing modes and not take very many instructions at that.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Yes.
You naming "Overlays" is correct I have in mind repeat or other powerful hardware Chip proposed.
It is one of My idea to overcome 512 barrier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Post Edited (Sapieha) : 8/30/2008 2:08:20 PM GMT
be an elegant way to accomplish this to provide more instruction
space, or at least more local ram.
I would say that I am amazed what you can do with ~496 longs.
My first system have 8080 CPU and 1k RAM not ROM and programing only with switsh
I was amazed what big it was
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
There are many techniques for doing this, but they're all sloppy / messy / far far from elegant.
Remember also that any cog RAM has to be replicated by 8 or 16.
It's just not going to happen.
This was often done with a so called "overlaying" linker that would add code to some of your function calls (From say C or PLM) to automatically load the overlays from disk, over writing other currently unused sections of code.
You had to organize your program carefully to make sure interrelated functions were in the right sections.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You say "bad old days"
It was not so bad.
Smal amount of RAM brigs more programing skill in coding.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
Sapieha
Oops: Off topic again.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Post Edited (heater) : 8/30/2008 4:03:41 PM GMT