Rayman/kwinn: Yes, CUDA is a building-block model for arranging the process into a multi-pipeline solution, aka production lining. And that's how it's done, even on the Prop. It's not something the compiler just magically sorts out for you.
A typical controller chip is very much performing this job, it is running a defined parallel process that is split off from the main CPU. When someone runs a Cog as an I/O processor then you've just found something that can be run in parallel. [noparse]:)[/noparse]
If there is no room for splitting the process up into smaller chunks for simultaneous processing then multiprocessor support can't help you.
Having now said that, instruction prefetching and CPU super-scalar and pipelining structures do deal with localised parallel execution of a sequential process. But each additional stage and layer adds to the support circuitry required just to correctly trigger stalls and/or reloading the correct instructions. It must be hideous for the designers to look at. I presume they even oversize the instruction fetch bus so as to have spare instructions to choose from for execution.
It would be fair to say that there is a self-reinforcing feedback going on in that world. Where the more bloat there is the better a deeper prefetch works. And the deeper the prefetchers become the more coders will bloat their code.
None of which is in the Propeller mandate of deterministic timing, ie: Stalls are not an option.
In theory a compiler could perform the arranging of instructions for multiple fine-grain threads. Shifting the complex stall logic out of the CPU. The DEC Alpha CPU just started down this road but was never allowed to flourish so we won't know how good it could have been.
I think Bill is on the right track in that self modifying code will require an instruction in between as I suspect the model will have a pipeline.
Here is my take (no inside info)...
I + d fetch & decode
S + D + e fetch & execute
R· result writeback
So when in cycle 2 the fetch I of intruction#2 will take place, and when in cycle 3 fetch S+D of instruction #2 & fetch I of instruction#3 will take place. This will mean 3 cycles being executed concurrently with a 3 cycle instruction = 1 cycle per instruction. Chip has said there the cog memory is quad access which translates to 3 read and 1 write.
Providing in cycle 3 the writeback can also be gated to the fetch I of instruction#3 if required, this will work.
Bill, while we expect 6 instructions to execute between hub reads/writes, don't forget we can read 4 x longs per read/write. Together with auto-increment, this will make an excellent LMM machine. We also have a repeat instruction which may also help.
My take on the longer term PropIII would be the need for 16+ cogs, 96-104 I/O. The cogs would be in a group of 4 where 1 cog could 'steal' by configuration the adjacent cog's cog-memory to be used in·a bank scheme. Banked cog memory (128 long banks)·may also be feasible.
Anyway, whatever the PropII brings, we will once again take it beyond what Chip expects it to do :-) Heaven forbid if this thread turns out to be "Why won't it run Windoze"... or even worse, "Why does Windoze run so slow" on PropII.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Ok, I'm new to all this Propeller chip; got the official book on programming the chip (form Amazon this year); will get a DIP chip and buy all the hardware elsewhere unless I get paid a loan I made, in which case I'll buy a the demo board.
I have to say I spent about two hours (not one after the other) reading this thread, and everyone has very good arguments defending and opposing whatever the point of discussion may be.
I have to agree with CHIP (parallax person) on the fact that C is somewhat difficult to learn:
My initial "µicro-encounter" was with PICs. I program PICs (10F, 12F, 16F and 18F, now moving to 24H and maybe dsPICs). Started with assembler and later bought PicBasic PRO and my life got easier, the development time was reduced significantly.
I agree with the person stating that C is more "standard" and almost no programmer likes to be taken out of their comfort zone but, there are times that is better to code in another language for the sake of delivering the product with the client's specifications:
Later in life I had to use more memory and had to code in C, as many applications existed already and that issue alone was worth the not-so-friendly-conversion-to-c investment. Went and bought first CCS's compiler and then moved to Microchip's.
I'm still new to this C programming, even have Stephen Prata's book (C PRIMER), still learning.
I also agree with the person that made the argument about the propeller not being for him:
I had to learn the basics of AVRs for one project and bought a NERDKIT (kinda of an evaluation kit for AVRs) and was amazed with the capabilities of Atmel's µicros compared to Microchip's PICs...... but made everything with a 18F PIC instead. The learning experience with AVRs is invaluable, as I have now more information on which device to use.
One person wrote about the costs/benefit ratio:
It might sound "bad" but I wouldn't use an 8 dollar Propeller µicro for a job that an Atiny or a 12F 0.50 dollar chip can do. And please, do not get me wrong, there are some process that only need that much processing power with an integrated AD converter (at least in my job).
After keeping with the spirit of the thread (everybody speaks their mind), and after seeing the webminars on the possible features on the new Propeller2 chip, I hope the propeller does not come any time soon, because, as CHIP says in that seminar, one should re-write their Propeller1 code for a new Propeller2. The same code might not take advantage of the new architecture.
My two cents, as you USA people say.
PS: looking forward to assembly and Spin programming with this new (old-4-years) µicrocontroller.
PS#2: Aren't NXP processors better because of their architecture?............ depends on the application I guess, as it seems to be for the C vs Spin discussion here.
PS#3: Nice, 127 posts in two days with three hours.
PS#4: I've used all of my english. Please forgive my english, it's very rusty.
The new ARM Cortex-M0 chips like the NXP LPC1111 have a very nice architecture, ideal for C programming, and cost as little as 65c in quantity. Operation is deterministic, BTW.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Weeeell ... pretty good but the Prop trumps it easy. The Prop is built to be a bunch of fully programmable I/O controllers. ARMs and the like have dedicated controllers. Bit bashing is not quite what one does with an ARM.
Roy said...
The main thing I miss when working on PASM code is being able to debug the code by stepping through instructions and reading memory and state. Like I do in Visual Studio at work. This would probably not be a very easy thing to support in the Prop/cog architecture without a lot of extra stuff being added to make all the cogs and hub run in lockstep when single stepping. Of course, we can get his when simulating things in a Prop emulator, but that doesn't let you debug things in circuit with all your sensors and such hooked up.
Which raises the question, of will the Propeller 2, Include a USB-Debug / HW breakpoint pathway ?
Even the 55c and 65c Microcontrollers now have quite good on-chip debug support, and usually low cost
USB connection to a PC debugger.
Some of these have ROMs to help the debug, but most operate with almost no user patches, or add-ins needed.
The better ones, also include a Communication back-channel, for run-time, that allow a Print style output,
to appear in a PC Window.
The Propeller 2 should, of course, also include support for the new Quad-SPI devices - these are small, cheap and fast.
- and an option to allow slower Execute-in-place - ie from a small-cached read of the QuadSPI.
Critical code would be loaded and locked into other Cogs.
jmg said...
The Propeller 2 should, of course, also include support for the new Quad-SPI devices - these are small, cheap and fast.
Sounds like SD card interface. Not a problem for the Prop, except for maybe royalties on patents.
The rest of your post is ho-hum. There is plenty of debug tools for the Prop already. And, since most confusion comes from badly documented libraries and hardware, this results in Prop having strong advantage over many others. To suggest the Propeller is lacking for debug is not being fair, imho. If you have a clue then you don't need to call yourself a Jones.
No amount of software debugging can solve a poorly laid-out PCB.
It will really need something like JTAG, though, if it is to be accepted by professional users. The lack of decent on-chip debugging is one reason why the Propeller is mainly used by hobbyists.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Leon: "The lack of decent on-chip debugging is one reason why you the Propeller is mainly used by hobbyists."
I love that statement. It kind of implies that professionals are so incompetent that they need debuggers to get by. Whereas hobbyists are smart enough to do without[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
It's more to do with hobbyists having no time pressures, whereas professionals will have managers breathing down their necks constantly asking when the application will be working.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Leon said...
It's more to do with hobbyists having no time pressures, whereas professionals will have managers breathing down their necks constantly asking when the application will be working.
In the large corporate environment it's called "de-risking." Large volume, huge money investment developments do not want unnecessary risks. Unnecessary risks include: lack of tools, lack of qualified people to work on a platform with non-standard tools, the size and stability of a single source supplier, etc.... This is not an attack on Parallax; it just illustrates their up-hill battle in corporate solution competitiveness.
Fortunately, Parallax seems to primarily exist not to compete for corporate sugar daddy capital, but to serve a niche which they essentially created 20 years ago in the micro-controller system module hobbyist market. Hobbyists should be proud of Parallax's achievements and desire to serve, but should also have a clue why other customers may not choose Parallax products in some cases.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
potatoehead said...
You won't need it [noparse]:)[/noparse]
I need it. [noparse]:)[/noparse]
I am in a situation using the prop where a debugger would be invaluable. I would pay dollars more per chip to have this feature available. While viewport works, it is not a hardware debugger replacement. I have an obscure alignment problem, and with a debugger it would be much, much simpler to locate when things go awry.
I find "de-risking" a very interesting dynamic. On one hand, keeping things structured in a low risk way, means, methods, processes being largely people / supplier independent. This is good! It's good because nobody wants to suffer a delay, inability to bring a feature to market, or an excessive cost due to a shortage, or lack of some necessary element of the product.
Fair enough.
It's also bad. It's bad because, if the enterprise is truly operating in this fashion, it's not actually INNOVATING anything, and because of that, must seek to profit through exploitation. That exploitation can be done with people, or business deals, the law, etc...
IMHO, value produced through, save, low risk, non-innovation, isn't really all that much value. Most of it is artificial value, and too much of that in a given industry stagnates it, rendering it vulnerable to others, willing to take a risk and actually innovate!
No risk, no reward then.
I've also noted, the larger the enterprise, the more these kinds of things are seen as necessary, largely for the thing to scale and move as the people that own it see fit. If the interests of the corporation are your primary priority, then de-risking is likely a good, regular thing to do. If actually innovating, then it's flat out toxic.
Perhaps the up and coming niche for propeller isn't major league commercial, but small to mid sized businesses, who don't have the size, nor the clout to get away with non-innovative, artificial value, and who depend on their people, means, methods, and processes to actually innovate, and potentially produce disruptive technology.
Comments
A typical controller chip is very much performing this job, it is running a defined parallel process that is split off from the main CPU. When someone runs a Cog as an I/O processor then you've just found something that can be run in parallel. [noparse]:)[/noparse]
If there is no room for splitting the process up into smaller chunks for simultaneous processing then multiprocessor support can't help you.
It would be fair to say that there is a self-reinforcing feedback going on in that world. Where the more bloat there is the better a deeper prefetch works. And the deeper the prefetchers become the more coders will bloat their code.
None of which is in the Propeller mandate of deterministic timing, ie: Stalls are not an option.
Here is my take (no inside info)...
So when in cycle 2 the fetch I of intruction#2 will take place, and when in cycle 3 fetch S+D of instruction #2 & fetch I of instruction#3 will take place. This will mean 3 cycles being executed concurrently with a 3 cycle instruction = 1 cycle per instruction. Chip has said there the cog memory is quad access which translates to 3 read and 1 write.
Providing in cycle 3 the writeback can also be gated to the fetch I of instruction#3 if required, this will work.
Bill, while we expect 6 instructions to execute between hub reads/writes, don't forget we can read 4 x longs per read/write. Together with auto-increment, this will make an excellent LMM machine. We also have a repeat instruction which may also help.
My take on the longer term PropIII would be the need for 16+ cogs, 96-104 I/O. The cogs would be in a group of 4 where 1 cog could 'steal' by configuration the adjacent cog's cog-memory to be used in·a bank scheme. Banked cog memory (128 long banks)·may also be feasible.
Anyway, whatever the PropII brings, we will once again take it beyond what Chip expects it to do :-) Heaven forbid if this thread turns out to be "Why won't it run Windoze"... or even worse, "Why does Windoze run so slow" on PropII.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Windoze on the Prop??? Wash you mouth out!!!
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Ok, I'm new to all this Propeller chip; got the official book on programming the chip (form Amazon this year); will get a DIP chip and buy all the hardware elsewhere unless I get paid a loan I made, in which case I'll buy a the demo board.
I have to say I spent about two hours (not one after the other) reading this thread, and everyone has very good arguments defending and opposing whatever the point of discussion may be.
I have to agree with CHIP (parallax person) on the fact that C is somewhat difficult to learn:
My initial "µicro-encounter" was with PICs. I program PICs (10F, 12F, 16F and 18F, now moving to 24H and maybe dsPICs). Started with assembler and later bought PicBasic PRO and my life got easier, the development time was reduced significantly.
I agree with the person stating that C is more "standard" and almost no programmer likes to be taken out of their comfort zone but, there are times that is better to code in another language for the sake of delivering the product with the client's specifications:
Later in life I had to use more memory and had to code in C, as many applications existed already and that issue alone was worth the not-so-friendly-conversion-to-c investment. Went and bought first CCS's compiler and then moved to Microchip's.
I'm still new to this C programming, even have Stephen Prata's book (C PRIMER), still learning.
I also agree with the person that made the argument about the propeller not being for him:
I had to learn the basics of AVRs for one project and bought a NERDKIT (kinda of an evaluation kit for AVRs) and was amazed with the capabilities of Atmel's µicros compared to Microchip's PICs...... but made everything with a 18F PIC instead. The learning experience with AVRs is invaluable, as I have now more information on which device to use.
One person wrote about the costs/benefit ratio:
It might sound "bad" but I wouldn't use an 8 dollar Propeller µicro for a job that an Atiny or a 12F 0.50 dollar chip can do. And please, do not get me wrong, there are some process that only need that much processing power with an integrated AD converter (at least in my job).
After keeping with the spirit of the thread (everybody speaks their mind), and after seeing the webminars on the possible features on the new Propeller2 chip, I hope the propeller does not come any time soon, because, as CHIP says in that seminar, one should re-write their Propeller1 code for a new Propeller2. The same code might not take advantage of the new architecture.
My two cents, as you USA people say.
PS: looking forward to assembly and Spin programming with this new (old-4-years) µicrocontroller.
PS#2: Aren't NXP processors better because of their architecture?............ depends on the application I guess, as it seems to be for the C vs Spin discussion here.
PS#3: Nice, 127 posts in two days with three hours.
PS#4: I've used all of my english. Please forgive my english, it's very rusty.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 2/28/2010 12:48:17 PM GMT
Which raises the question, of will the Propeller 2, Include a USB-Debug / HW breakpoint pathway ?
Even the 55c and 65c Microcontrollers now have quite good on-chip debug support, and usually low cost
USB connection to a PC debugger.
Some of these have ROMs to help the debug, but most operate with almost no user patches, or add-ins needed.
The better ones, also include a Communication back-channel, for run-time, that allow a Print style output,
to appear in a PC Window.
The Propeller 2 should, of course, also include support for the new Quad-SPI devices - these are small, cheap and fast.
- and an option to allow slower Execute-in-place - ie from a small-cached read of the QuadSPI.
Critical code would be loaded and locked into other Cogs.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
The rest of your post is ho-hum. There is plenty of debug tools for the Prop already. And, since most confusion comes from badly documented libraries and hardware, this results in Prop having strong advantage over many others. To suggest the Propeller is lacking for debug is not being fair, imho. If you have a clue then you don't need to call yourself a Jones.
No amount of software debugging can solve a poorly laid-out PCB.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Post Edited (Leon) : 3/11/2010 4:19:52 PM GMT
I love that statement. It kind of implies that professionals are so incompetent that they need debuggers to get by. Whereas hobbyists are smart enough to do without[noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
Fortunately, Parallax seems to primarily exist not to compete for corporate sugar daddy capital, but to serve a niche which they essentially created 20 years ago in the micro-controller system module hobbyist market. Hobbyists should be proud of Parallax's achievements and desire to serve, but should also have a clue why other customers may not choose Parallax products in some cases.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Short answers? Not available at this time since I think you deserve more information than you requested.
I need it. [noparse]:)[/noparse]
I am in a situation using the prop where a debugger would be invaluable. I would pay dollars more per chip to have this feature available. While viewport works, it is not a hardware debugger replacement. I have an obscure alignment problem, and with a debugger it would be much, much simpler to locate when things go awry.
Fair enough.
It's also bad. It's bad because, if the enterprise is truly operating in this fashion, it's not actually INNOVATING anything, and because of that, must seek to profit through exploitation. That exploitation can be done with people, or business deals, the law, etc...
IMHO, value produced through, save, low risk, non-innovation, isn't really all that much value. Most of it is artificial value, and too much of that in a given industry stagnates it, rendering it vulnerable to others, willing to take a risk and actually innovate!
No risk, no reward then.
I've also noted, the larger the enterprise, the more these kinds of things are seen as necessary, largely for the thing to scale and move as the people that own it see fit. If the interests of the corporation are your primary priority, then de-risking is likely a good, regular thing to do. If actually innovating, then it's flat out toxic.
Perhaps the up and coming niche for propeller isn't major league commercial, but small to mid sized businesses, who don't have the size, nor the clout to get away with non-innovative, artificial value, and who depend on their people, means, methods, and processes to actually innovate, and potentially produce disruptive technology.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 3/13/2010 2:38:12 AM GMT