Sure. Depends on what the video needs to do. I'm inclined to put a program there. External RAM won't have the fill rates and parallelism the HUB does. It will be really interesting to see how they can be combined. In any case using it for a nice big buffer is just fine.
That is what i really enjoy. Props software video means all of it is on the table.
P.S. Much as LOVE the Prop II analog pins, I'd love them MORE on the Prop I. The things I could do with a 100uA! :cool: (total pipe dream I know...)
That's a real possibility. I can see there eventually being a lower power, smaller, slower (maybe not pipelined) Prop2 that gets targeted as the successor to the Prop1.
That's a real possibility. I can see there eventually being a lower power, smaller, slower (maybe not pipelined) Prop2 that gets targeted as the successor to the Prop1.
Smaller is mandatory, as it needs to fit in a QFN44, but lower power and slower are more process dependent.
The quickest re-target is to throw LARGE BLOCKS overboard until it fits the paddle for bonding, and not to touch/break the low level stuff at all.
Less Pins, Less RAM, and Fewer COGS - now that COGs can slice, they can drop in count more readily.
(an 8 way slice would allow a single cog to give a Prop 1 a run, subject to VAR.CODE space.)
Targeting small footprint is another variant again.
Competing directly with the Prop1 on power consumption while still having the enhanced I/O of the Prop2 is where I was aiming. Pin count only reduced as a side effect of the smaller Cogs and less Hub RAM. The Cogs won't shrink much though, as the same Prop2 instruction set will be expected. Just different timing with the slower execution.
Say, 64 I/O, 84 pins and double the Prop1 wattage (in static state), wouldn't be impossible.
One COG running 4 instances of the SPIN interpreter.
I suspect it is theoretically possible except as I understand there is no room left in the Spin interpreter COG.
But then when that is rewritten in Prop II PASM code that might free up just enough space.
It probably makes more sense to do Spin tasks at the bytecode level. Each task would just needs its own set of the 5 Spin state variables -- PBASE, VBASE, DBASE, DCURR and PCURR. If you did this at the COG instruction level you would need to provide the set of 6 or 7 scratchpad registers for each task also.
I think the cogs limited ram space it what will limit the usefulness of 4 high level programs sharing one cog.
The programs would have to be really small to fit in, and using C for something that small is nearly pointless.
I think the cogs limited ram space it what will limit the usefulness of 4 high level programs sharing one cog.
The programs would have to be really small to fit in, and using C for something that small is nearly pointless.
I t depends somewhat on what you mean by 'C'.
In a classic/lazy Cut-n-paste any-old-C, you are correct, but if you mean C Tool chain and Tool flows, then that also includes in-line PASM, and access to all the directives for COG and Slice and Debug control.
In that context, far from being pointless, it is very important that the Prop C toolchain can fully support .c files to COG slices.
What is actually in those files, will not be intern-level C.
I think the cogs limited ram space it what will limit the usefulness of 4 high level programs sharing one cog.
The programs would have to be really small to fit in, and using C for something that small is nearly pointless.
I used to think that too. Then the first thing the propgcc guys did was get the compiler to generate native in COG PASM. When they had a workable compiler I just had to try it out. Ended up creating a C version of FullDuplexSerial that has two very light weight threads. It's in the propgcc demos somewhere. So it turns out that it is possible to make useful in COG programs in C.
Having the new task scheduler in Prop II will allow me to make that FullDuplexSerial code much simpler and perform far better. And I'm sure C will be used in other such drivers in Prop II.
jmg,
What is actually in those files, will not be intern-level C.
Perhaps, but I think you will find that it is not rocket science either.
TASKSW will be the solution for anything not needing the responsiveness of the fine grain slicing. You're not losing performance at a course grain and TASKSW will be easily extended to LMM and co., making for a generalised multitasking solution.
I suspect, for this particular implementation, these two options will not mingle much at all. You're all welcome to prove me wrong though.
EDIT: The other point of note is slicing is pre-emptive in nature while TASKSW is co-operative nature. Parallel processing is already a reality with the multi-Cog arrangement but I'm highlighting that allowing for pre-emptive scheduling, keeping the option open for a more capable slicer in future, in the kernels would probably be the right direction to go in.
EDIT2: Hmm, the handling of time proportioning might be a bit of fun for the kernel given the slicer is not priority driven. Something to think about I guess ...
Will there be a gettask D, S command that puts the PC of task S in D? It would make a multitasking kernel that could do more than 4 threads almost trivial, although you would probably want LMM.
Yes, GCC supports inline PASM. I hate to use it though the syntax is ugly and ungainly.
This is strange because I think I just heard that GCC only supports GASS (GNU Assembler) and not PASM in the Spin to C++ thread...
It would be nice for GCC to support PASM as more than just a array of bytes...
This is strange because I think I just heard that GCC only supports GASS (GNU Assembler) and not PASM in the Spin to C++ thread...
It would be nice for GCC to support PASM as more than just a array of bytes...
GAS is just the GNU assembler. When binutils is ported to a new processor GAS is extended to handle the assembly language of that processor. On the Propeller, GAS assembles a syntax that is very similar to PASM but differs in a few respects especially in the area of byte vs. long addressing.
GAS is just the GNU assembler. When binutils is ported to a new processor GAS is extended to handle the assembly language of that processor. On the Propeller, GAS assembles a syntax that is very similar to PASM but differs in a few respects especially in the area of byte vs. long addressing.
Are there any examples of GAS-PASM posted yet, and a comparison of differences ?
Once again, absolutely amazing. I've just read this entire thread in one long marathon session, and I am even more excited than I was before for the release of the p2.
Again, I don't know what I'll use it for, but with all the features being packed into it, I'm sure I can find many many things to do with it.
Fascinating reading as always. Thank you again for the peek into the design/creation process, I can't imagine how much work this is taking behind the scenes, but I assure you when it is all done, there will be at least one person waiting in line to purchase one.
And, judging from discussions here, I'd wager it's going to be a very long line indeed.
Great stuff here, please keep it up.
Comments
That is what i really enjoy. Props software video means all of it is on the table.
That's a real possibility. I can see there eventually being a lower power, smaller, slower (maybe not pipelined) Prop2 that gets targeted as the successor to the Prop1.
Smaller is mandatory, as it needs to fit in a QFN44, but lower power and slower are more process dependent.
The quickest re-target is to throw LARGE BLOCKS overboard until it fits the paddle for bonding, and not to touch/break the low level stuff at all.
Less Pins, Less RAM, and Fewer COGS - now that COGs can slice, they can drop in count more readily.
(an 8 way slice would allow a single cog to give a Prop 1 a run, subject to VAR.CODE space.)
Competing directly with the Prop1 on power consumption while still having the enhanced I/O of the Prop2 is where I was aiming. Pin count only reduced as a side effect of the smaller Cogs and less Hub RAM. The Cogs won't shrink much though, as the same Prop2 instruction set will be expected. Just different timing with the slower execution.
Say, 64 I/O, 84 pins and double the Prop1 wattage (in static state), wouldn't be impossible.
I wonder, does this mean we could see new SPIN commands?, for example:
SETTMASK ( TaskMaskPointer )
TASKNEW ( TaskID, SpinMethod <(ParameterList)>, StackPointer )
Returns: The ID of the newly started task (0-3) if successful, or -1 otherwise,
Also, Sets Default TASKMASK Bits in TaskMask for This Task
TASKSTOP ( TaskID )
ThisTaskID := TASKID
Initial invocation Method becomes TaskID "0" by default?
--
Just thinking out loud
Eldon
One COG running 4 instances of the SPIN interpreter.
I suspect it is theoretically possible except as I understand there is no room left in the Spin interpreter COG.
But then when that is rewritten in Prop II PASM code that might free up just enough space.
The programs would have to be really small to fit in, and using C for something that small is nearly pointless.
I t depends somewhat on what you mean by 'C'.
In a classic/lazy Cut-n-paste any-old-C, you are correct, but if you mean C Tool chain and Tool flows, then that also includes in-line PASM, and access to all the directives for COG and Slice and Debug control.
In that context, far from being pointless, it is very important that the Prop C toolchain can fully support .c files to COG slices.
What is actually in those files, will not be intern-level C.
I used to think that too. Then the first thing the propgcc guys did was get the compiler to generate native in COG PASM. When they had a workable compiler I just had to try it out. Ended up creating a C version of FullDuplexSerial that has two very light weight threads. It's in the propgcc demos somewhere. So it turns out that it is possible to make useful in COG programs in C.
Having the new task scheduler in Prop II will allow me to make that FullDuplexSerial code much simpler and perform far better. And I'm sure C will be used in other such drivers in Prop II.
jmg,
Perhaps, but I think you will find that it is not rocket science either.
Does GCC already support in line PASM ?
Did you need to use in-line PASM for any of that ?
No, there is no PASM in my FullDuplexSerial in C code. I was surprised to be able to get the thing up to 115200 baud:)
I suspect, for this particular implementation, these two options will not mingle much at all. You're all welcome to prove me wrong though.
EDIT: The other point of note is slicing is pre-emptive in nature while TASKSW is co-operative nature. Parallel processing is already a reality with the multi-Cog arrangement but I'm highlighting that allowing for pre-emptive scheduling, keeping the option open for a more capable slicer in future, in the kernels would probably be the right direction to go in.
EDIT2: Hmm, the handling of time proportioning might be a bit of fun for the kernel given the slicer is not priority driven. Something to think about I guess ...
This is strange because I think I just heard that GCC only supports GASS (GNU Assembler) and not PASM in the Spin to C++ thread...
It would be nice for GCC to support PASM as more than just a array of bytes...
Are there any examples of GAS-PASM posted yet, and a comparison of differences ?
Again, I don't know what I'll use it for, but with all the features being packed into it, I'm sure I can find many many things to do with it.
Fascinating reading as always. Thank you again for the peek into the design/creation process, I can't imagine how much work this is taking behind the scenes, but I assure you when it is all done, there will be at least one person waiting in line to purchase one.
And, judging from discussions here, I'd wager it's going to be a very long line indeed.
Great stuff here, please keep it up.
It has been a long time coming.
cheers,
rich