It is not disappointable that SPIN is "slow"!
It is great that SPIN is making compact code that executes quite fast. Keep in mind, that the Propeller is a µC and what you can achieve with it is damned *GREAT*. If you think the SPIN is still too slow, spread sub-tasks onto different cogs (running in SPIN) and parallel your tasks.
Did you forget to sing the Propeller-mantra this moring?
sing with me:
Propeller has 8 cogs!
Propeller has 8 cogs!
Propeller has 8 cogs!
...
Use them and you are getting fast.
Don't sing the bad-vibe-matra of yesterday that was "I have one CPU, 8 registers, 16 INTs, 2 timers, 1 UART and I'm lost nesting time-critical loops"
That please say that the propeller offer 32k memory of which the use thus implies a loss of 2000%. Thus the computing speed for the large one of work is about 8 mips (1 MIPS per cog). And for speed, ( 160 MIPS/ 20 MIPS per cog ) the propeller offer only 8 X 1 Kbyte for assembler.
I understand that An interpreter is not a compiler. In my mind, the principal defect of a interpreter, comes in fact that it converts the code during the accomplishment of this code. And worse, it as many reconverts each line of a loop time as the loop accomplish. In a "real time" environment, that seems to be more than wasting.
Using a controller (Name not used to protect the innocent), I wrote a program that used the SPI interrupt to·log a circular buffer with·measurements from a Converter. The main loop checked the buffer for a certain condition. The controller running faster than the Propeller was doing all it could.
Same App on the Propeller ran the SPI engine, The buffer checker, Plus a data validation routine, each in a separate cog(in assembly). The remaining 5 Cogs ran the Ever so slow Spin code to maintain a LCD screen, SD card, a debug connection, and still had two cogs free for Bells and whistles!
Interpreted, compiled, spread on a stick, The propeller has done for me what 120·160Mhz plus interrupts, and DMA to ram could not!
dro, to make Spin a compiled program would defeat much of the purpose of using it. Think of interpreted Spin as highly subroutined code, each operation is a subroutine and all instances of each operation uses the same piece of code to perform the task. A compiled Spin would loose this benefit, it would be like explicitly coding the same instructions inline each time they are used. Considering each cog has room for 496 assembly instructions and each spin operation takes quite a few assembly instructions to execute, you would have room for maybe 50-100 instructions and each line may contain multiple instructions (x + y) / (x - y) * 12 for instance has 4 instructions on a single line. To compensate for this would require a paging scheme which would slow down the overall execution rate by a considerable amount (see ImageCraft's discussion of the large memory model and how he optimistically hoping for a 30% execution rate).
This is not meant as any sort of a slight, but the Propeller was designed as an advanced microcontroller with the assumption that anyone who needed it's full computational power would be able to write assembly.
Fortunately, because of the object-like nature you can rely on the assembly code written by others and include it into your programs without understanding how that assembly code does what it does.
Gotta love that! (It sure made me chuckle this morning!)
What's the task that is demanding such speed? Can it be done in parallel? Is it huge and or complex? This tradeoff discussion might be more meaningful, put into context. (And likely on another thread too, but I'm not complaining!)
I think the prop is one of those few tech things that makes you work for it, but it pays off big. Most tech things leverage a lot of work already done. This is good in that barrier to use is low, but so is the return generally.
Re: Programming in assembler.
I gotta say I've had a tough time getting started. The power of the design is fairly obvious, but wrapping your head around how best to use it does require some loosening of many preconceptions. At least, that's been my experience so far. (and that's just not a bad thing, it just is) Now that some lights have come on in this regard, this assembly language is proving to be as extremely useful as it looked at first glance --and then some. Long for long, it does more per instruction, on average, than just about any chip I've dealt with. To be fair, that's older 8bitters (6502, some Z80, 6809) and bigger (6800x, i386, MIPS).
Miss the stack, but can easily make one, so no biggie. Don't miss having to shuffle registers, deal with instructions that want specific ones, interrups and all that hassle, etc... It's deterministic too. That makes viewing things from a timing and I/O perspective necessary to really get the thing humming for you. (I personally struggle with this, but it's coming together now.) IMHO, this is a very good thing as the techniques are repeatable across COG's, once learned. So you scale with the prop, essentially. No other CPU, that I've seen, does this!
This means, when we see the next prop generation, our skills will largely, if not almost completely still apply, but the scope of possible tasks will scale in both directions, instead of just the one linear one where raw instruction streaming speed gains, typical of other CPUs, scale.
At the end of the day, if you are gonna learn an assembler, (and you really should, if your tasks really indicate it) then this one is gonna pay off huge. The beauty of this design is that you can mix and match SPIN and assembly language across the COGS as you see fit as well. Dealing with that is tough too, but again, once the lights come on, IMHO there is no going back.
Post Edited (potatohead) : 4/9/2007 6:38:09 PM GMT
I started learning it, in any form, with the Prop last year. Now, I find myself having a more difficult time coding in Spin due to all the options. My point, even assembly isn't that difficult to learn. But, if you're trying to solve your problem in one semester, you're gonna have issues starting fresh in assembler. But, as a long term hobby, or occupation, I agree with those above that assembler will win in the end. Can't compare PASM with any other assembly though... never learned another one.
Paul, that is the first time I have heard is said that the Prop was designed with the "assumption that anyone who needed it's full computational power would be able to write assembly". I guess it seems obvious now, but never heard it said that way before.
Well one last point and I'll shut up. On the other Micro I tried writting it with a C compiler, But to get the timing of the interrupts right and the 100K· 12 Bit Sample rate I wanted it too ended up haveing to be written in assembly.
I do understand the assembly woes, and if I had not some grasp of the assembly concept I would have given up and settled for the BS2 funtions rate of around 11K samples and that would not have passed for my app. But as some have said once you learn assembly you may never go back, specially when you consider the speed and self modifing code options it delivers!
At any rate I do understand the comfort of clinging to old ways, My other half wants me to get a coffee maker because she's tired of cleaning my old Kettle.
But coffee just doesn't taste the same without it.
potatohead, you ask "What's the task that is demanding such speed?" Simply all that must be written out of assembler !
What mean "Spread on a Stick!" ? ( i do not understand the English very well )
You also ask if this subject is in the right thread ? many people answer the questions, but to write prose, it is not the good thread !
You should read the others answers (especially that of Paul BAKER) to have an idea of what the users await from this forum.
Please continue to chuckle but alone !
inservi,
There are very few tasks that must be written in the native Propeller instruction set. Spin can handle half duplex serial I/O to at least 19200 Baud and even SPI to an SD card with a FAT file system fast enough for many user interface tasks (limited by interactivity with a user). Much of the faster I/O tasks are already provided as assembly routines with a Spin interface as object. For the faster tasks, there are few that can be written in a high level language since very few compilers if any are capable of adequately optimizing for the simultaneous constraints of space (< 512 instructions and local data) and time needed for the task, particularly where there are strict timing constraints for sections of the code (like for video generation or high-speed serial I/O). I think the proposal for a C compiler to produce "large model" code is excellent. The space constraints are very much eased and the best execution speed (which won't really be anywhere near 20-30% of native code due to coding inefficiencies in the compiler) should be very good.
By the way, I have a lot of experience in compiler writing, particularly for small computers. I know what it takes to do a really good optimizing compiler. It's a very expensive proposition and you need to have a large enough projected market to pay for the work involved. The Propeller's market can't pay for that kind of effort. I'm sure the C compiler will produce good code, but there will still be routines where there will be significant benefit to having them hand-coded in "large model" code, let alone in pure native code.
Now, I better understands the problem. I continue to find the Propeller fantastic. I thus will learn the assembler because it does not seem so difficult and I prefer to give solutions rather than to be depend on the other programmer.
Another great quality of the Propeller, is the good activity of this forum.
By spread on a stick, I was saying·(in poor english)·that no matter how you use it the Propeller has proven to me to get the job done! I am glad to hear that assembly is not so intimidating to you and am sure what time you spend learning it will pay off big time, where speed is concerned. As Mike and others have said though, most routines don't need the speed and can be written quit efficiently in Spin. It also is flexible, in that the way you write can be unique to a certain extent.
Bottom line is, The people that are wanting interrupts are really just needing cogs so thay can make their own interrupts, and complants about the Spin compiler is just a need to learn assembly. Dedicated Hardwire I love, but not on the Propeller. If I got to have it I'll use something else. And those wanting those features should look at the freedom we would lose. The propeller says "Hay you need a Uart? Go pick you out a couple pins and make it a Uart!". God I love that!
Bottom line is, The people that are wanting interrupts are really just needing cogs so thay can make their own interrupts, and complants about the Spin compiler is just a need to learn assembly. Dedicated Hardwire I love, but not on the Propeller. If I got to have it I'll use something else. And those wanting those features should look at the freedom we would lose. The propeller says "Hay you need a Uart? Go pick you out a couple pins and make it a Uart!". God I love that!
I spent a good portion of the Embedded Systems Conference explaining this concept to people. I tended a bit more on the business angle in my approach; that an unused piece of dedicated silicon is a wasted piece of silicon (and wasted money multiplied by the number of units manufactured), and to pick out "the right" chip to use in each and every project (thereby reducing wasted silicon) creates it's own expense of inventory management of N variations of a architecture.
The propeller is impressive and very capable. I just soooo wish that you had given some thought to IP protection early on [noparse]:([/noparse]
I know it's counter to the open-source ethos but I'm not a big corporate - I'm a tiny independent developer and my algorithms and techniques are my bread and butter. The propeller may be a vast technological leap over uni-core PICs, 89Cs ,etc. but they've got the flash embedded and that nifty little read-proctect fuse that protects my income [noparse]:([/noparse]
Paul, with one can of retreat, it should well be recognized that the two parts remain on their positions.
Alex, you are right, the problem of IP protection is very important for many people.
Chip Gracey (Parallax) said...
To do the 1280x1024 vga tile driver, it would take only one cog in the future chip if it had 8 cogs. If it had 16 cogs, it would require two cogs because of the relative hub bottleneck. In the current chip, it takes 3 cogs.
Bill Henning said...
Chip, I'd be curious to see how many cog's you'd need to do the tiled 1280x1024 vga mode with both approaches, compared to the current approach.
Also, I have an idea for another video mode.
4 bits per pixel
instead of passing in a long with the four six bit color lookup values, the long is used as the base address of a 16 entry color lookup table in cog memory (or dare I dream... a 256 entry LUT in hub space?) That sounds good. There might need to be a FIFO though, to overcome the conchunkulation between the hub and video timing.
Then why Would not you make 16 cogs, 2 hubs and one inter hub(that will connect two normal hubs)
BBC64,
It's not clear from your posting that you understand that there's no practical way to "just add the SRAM to the Propeller" (if you're referring to external SRAM). You can always attach additional memory, but it wouldn't be equivalent to the internal memory even though it would be very useful (as discussed for the Hydra 512KB SRAM card). The chip area and tradeoff between chip delays and power consumption needed to bring address and data off-chip would be prohibitive.
After many opinions and ideas - I am sure at this stage it has been decided - I am just woundering what has been decided ... any chance we can get a taste of whats to come ?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ 'Necessity is the mother of invention'
any idea how many io pins?
as 16 with lots of pins can make the loss of 128KB easier by having some direct sram access, and would be a better all round gain.
The Propeller's architecture is designed for up to 64 I/O pins even though the current chip is only set up for 32. If you read the long discussions on Propeller Version Two, the plan seems to be to have all 64 I/O pins available although there may be a version with only 32 bits implemented.
Sweet, 64 would be sweet, but I bet it would mean SMD only? Although I would hope you would be doing proto boards for it, so the mere mortal electronics peeps who haven't done any SMD yet, can still have a play.
also, any hint on what speed the cogs will be running at?
Comments
It is not disappointable that SPIN is "slow"!
It is great that SPIN is making compact code that executes quite fast. Keep in mind, that the Propeller is a µC and what you can achieve with it is damned *GREAT*. If you think the SPIN is still too slow, spread sub-tasks onto different cogs (running in SPIN) and parallel your tasks.
Did you forget to sing the Propeller-mantra this moring?
sing with me:
Propeller has 8 cogs!
Propeller has 8 cogs!
Propeller has 8 cogs!
...
Use them and you are getting fast.
Don't sing the bad-vibe-matra of yesterday that was "I have one CPU, 8 registers, 16 INTs, 2 timers, 1 UART and I'm lost nesting time-critical loops"
Nick (still singing)
That please say that the propeller offer 32k memory of which the use thus implies a loss of 2000%. Thus the computing speed for the large one of work is about 8 mips (1 MIPS per cog). And for speed, ( 160 MIPS/ 20 MIPS per cog ) the propeller offer only 8 X 1 Kbyte for assembler.
I understand that An interpreter is not a compiler. In my mind, the principal defect of a interpreter, comes in fact that it converts the code during the accomplishment of this code. And worse, it as many reconverts each line of a loop time as the loop accomplish. In a "real time" environment, that seems to be more than wasting.
dro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
Post Edited (inservi) : 4/9/2007 4:00:37 PM GMT
Using a controller (Name not used to protect the innocent), I wrote a program that used the SPI interrupt to·log a circular buffer with·measurements from a Converter. The main loop checked the buffer for a certain condition. The controller running faster than the Propeller was doing all it could.
Same App on the Propeller ran the SPI engine, The buffer checker, Plus a data validation routine, each in a separate cog(in assembly). The remaining 5 Cogs ran the Ever so slow Spin code to maintain a LCD screen, SD card, a debug connection, and still had two cogs free for Bells and whistles!
Interpreted, compiled, spread on a stick, The propeller has done for me what 120·160Mhz plus interrupts, and DMA to ram could not!
Post Edited (bambino) : 4/9/2007 4:31:49 PM GMT
dro
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
This is not meant as any sort of a slight, but the Propeller was designed as an advanced microcontroller with the assumption that anyone who needed it's full computational power would be able to write assembly.
Fortunately, because of the object-like nature you can rely on the assembly code written by others and include it into your programs without understanding how that assembly code does what it does.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Gotta love that! (It sure made me chuckle this morning!)
What's the task that is demanding such speed? Can it be done in parallel? Is it huge and or complex? This tradeoff discussion might be more meaningful, put into context. (And likely on another thread too, but I'm not complaining!)
I think the prop is one of those few tech things that makes you work for it, but it pays off big. Most tech things leverage a lot of work already done. This is good in that barrier to use is low, but so is the return generally.
Re: Programming in assembler.
I gotta say I've had a tough time getting started. The power of the design is fairly obvious, but wrapping your head around how best to use it does require some loosening of many preconceptions. At least, that's been my experience so far. (and that's just not a bad thing, it just is) Now that some lights have come on in this regard, this assembly language is proving to be as extremely useful as it looked at first glance --and then some. Long for long, it does more per instruction, on average, than just about any chip I've dealt with. To be fair, that's older 8bitters (6502, some Z80, 6809) and bigger (6800x, i386, MIPS).
Miss the stack, but can easily make one, so no biggie. Don't miss having to shuffle registers, deal with instructions that want specific ones, interrups and all that hassle, etc... It's deterministic too. That makes viewing things from a timing and I/O perspective necessary to really get the thing humming for you. (I personally struggle with this, but it's coming together now.) IMHO, this is a very good thing as the techniques are repeatable across COG's, once learned. So you scale with the prop, essentially. No other CPU, that I've seen, does this!
This means, when we see the next prop generation, our skills will largely, if not almost completely still apply, but the scope of possible tasks will scale in both directions, instead of just the one linear one where raw instruction streaming speed gains, typical of other CPUs, scale.
At the end of the day, if you are gonna learn an assembler, (and you really should, if your tasks really indicate it) then this one is gonna pay off huge. The beauty of this design is that you can mix and match SPIN and assembly language across the COGS as you see fit as well. Dealing with that is tough too, but again, once the lights come on, IMHO there is no going back.
Post Edited (potatohead) : 4/9/2007 6:38:09 PM GMT
I started learning it, in any form, with the Prop last year. Now, I find myself having a more difficult time coding in Spin due to all the options. My point, even assembly isn't that difficult to learn. But, if you're trying to solve your problem in one semester, you're gonna have issues starting fresh in assembler. But, as a long term hobby, or occupation, I agree with those above that assembler will win in the end. Can't compare PASM with any other assembly though... never learned another one.
Paul, that is the first time I have heard is said that the Prop was designed with the "assumption that anyone who needed it's full computational power would be able to write assembly". I guess it seems obvious now, but never heard it said that way before.
-Parsko
BTW - 16 cogs
I do understand the assembly woes, and if I had not some grasp of the assembly concept I would have given up and settled for the BS2 funtions rate of around 11K samples and that would not have passed for my app. But as some have said once you learn assembly you may never go back, specially when you consider the speed and self modifing code options it delivers!
At any rate I do understand the comfort of clinging to old ways, My other half wants me to get a coffee maker because she's tired of cleaning my old Kettle.
But coffee just doesn't taste the same without it.
potatohead, you ask "What's the task that is demanding such speed?" Simply all that must be written out of assembler !
What mean "Spread on a Stick!" ? ( i do not understand the English very well )
You also ask if this subject is in the right thread ? many people answer the questions, but to write prose, it is not the good thread !
You should read the others answers (especially that of Paul BAKER) to have an idea of what the users await from this forum.
Please continue to chuckle but alone !
Thanks to all other !
dro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
There are very few tasks that must be written in the native Propeller instruction set. Spin can handle half duplex serial I/O to at least 19200 Baud and even SPI to an SD card with a FAT file system fast enough for many user interface tasks (limited by interactivity with a user). Much of the faster I/O tasks are already provided as assembly routines with a Spin interface as object. For the faster tasks, there are few that can be written in a high level language since very few compilers if any are capable of adequately optimizing for the simultaneous constraints of space (< 512 instructions and local data) and time needed for the task, particularly where there are strict timing constraints for sections of the code (like for video generation or high-speed serial I/O). I think the proposal for a C compiler to produce "large model" code is excellent. The space constraints are very much eased and the best execution speed (which won't really be anywhere near 20-30% of native code due to coding inefficiencies in the compiler) should be very good.
By the way, I have a lot of experience in compiler writing, particularly for small computers. I know what it takes to do a really good optimizing compiler. It's a very expensive proposition and you need to have a large enough projected market to pay for the work involved. The Propeller's market can't pay for that kind of effort. I'm sure the C compiler will produce good code, but there will still be routines where there will be significant benefit to having them hand-coded in "large model" code, let alone in pure native code.
Thank-you for all your interventions.
Now, I better understands the problem. I continue to find the Propeller fantastic. I thus will learn the assembler because it does not seem so difficult and I prefer to give solutions rather than to be depend on the other programmer.
Another great quality of the Propeller, is the good activity of this forum.
Best regards,
dro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
By spread on a stick, I was saying·(in poor english)·that no matter how you use it the Propeller has proven to me to get the job done! I am glad to hear that assembly is not so intimidating to you and am sure what time you spend learning it will pay off big time, where speed is concerned. As Mike and others have said though, most routines don't need the speed and can be written quit efficiently in Spin. It also is flexible, in that the way you write can be unique to a certain extent.
Bottom line is, The people that are wanting interrupts are really just needing cogs so thay can make their own interrupts, and complants about the Spin compiler is just a need to learn assembly. Dedicated Hardwire I love, but not on the Propeller. If I got to have it I'll use something else. And those wanting those features should look at the freedom we would lose. The propeller says "Hay you need a Uart? Go pick you out a couple pins and make it a Uart!". God I love that!
Now, I understands better the message of Potatohead. I must all read again 3 times for well understanding.
dro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
inservi: no worries about the english, you come across just fine.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
I know it's counter to the open-source ethos but I'm not a big corporate - I'm a tiny independent developer and my algorithms and techniques are my bread and butter. The propeller may be a vast technological leap over uni-core PICs, 89Cs ,etc. but they've got the flash embedded and that nifty little read-proctect fuse that protects my income [noparse]:([/noparse]
Alex, you are right, the problem of IP protection is very important for many people.
dro.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
in medio virtus
It's not clear from your posting that you understand that there's no practical way to "just add the SRAM to the Propeller" (if you're referring to external SRAM). You can always attach additional memory, but it wouldn't be equivalent to the internal memory even though it would be very useful (as discussed for the Hydra 512KB SRAM card). The chip area and tradeoff between chip delays and power consumption needed to bring address and data off-chip would be prohibitive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Necessity is the mother of invention'
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
as 16 with lots of pins can make the loss of 128KB easier by having some direct sram access, and would be a better all round gain.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
also, any hint on what speed the cogs will be running at?
Baggers.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://forums.parallax.com/showthread.php?p=650217
meow, i have my own topic now? (sorta)