Aha! Thanks for letting me in on this secret. And I suppose you're right, there is tons of info- I just don't understand any of it -yet.
That's the problem we run into when starting up something this complex.
"How high is the bar"?
The OBEX and Kick Start projects are really amazing.
IF you have enough background/experience/patience/grit to dig through it and understand.
For engineers moving into the Propeller community that should be more than enough to get going.
But for newbies, and specially mothers of overly bright kids, that background experience is not yet there. This is who I picked for my target audience.
Mom and kid are at Radio Shack/Micro Center/Frys looking for something cleaver to play with.
Maybe a science project? Or just something fun and educational.
There is the Propeller QuickStart board ($39 - not too bad) and the PEK (
$hundred plus?)
with no other books, guides, really ANYthing hanging on the shelf.
Or the ARM/Arudino/Pic stuff with TONS of information right there.
Pick up a book or two and scan through it.
Does it seem to be understandable?
Or unimaginably complex?
Where is mom going to spend her hard earned bucks?
To throw another stone at the hornets nest, anyone who claims they are a "professional programmer" and balks at learning another language is not a programmer at all, they are a coder.
For the record (for those of you who don't know me), I was one of the people asked to come out to Parallax for the unveiling of the Propeller chip (I later went to work for Parallax for a couple years). That first night, only armed with what Jeff Martin and Chip Gracey told us during that first day's presentation and armed with a grand total of roughly 3 sheets of paper (1 for the spin commands, one for the assembly commands and one giving a general overview of the architecture) I wrote a digital storage scope application for the Propeller.
Sorry to say this, but anyone who can't make heads or tails given the considerable documentation now at your disposal (some of which I helped to create) and unwilling to make use of the unparalleled forums to cover whatever small gaps exist in the documentation, should probably find another profession or find a job in a big firm where you code in C and are responsible for a tiny module in a giant software package.
PS as an ex-employee my opinion in no way represents the views of Parallax.
To throw another stone at the hornets nest, anyone who claims they are a "professional programmer" and balks at learning another language is not a programmer at all, they are a coder.
For the record (for those of you who don't know me), I was one of the people asked to come out to Parallax for the unveiling of the Propeller chip (I later went to work for Parallax for a couple years). That first night, only armed with what Jeff Martin and Chip Gracey told us during that first day's presentation and armed with a grand total of roughly 3 sheets of paper (1 for the spin commands, one for the assembly commands and one giving a general overview of the architecture) I wrote a digital storage scope application for the Propeller.
Sorry to say this, but anyone who can't make heads or tails given the considerable documentation now at your disposal (some of which I helped to create) and unwilling to make use of the unparalleled forums to cover whatever small gaps exist in the documentation, should probably find another profession or find a job in a big firm where you code in C and are responsible for a tiny module in a giant software package.
PS as an ex-employee my opinion in no way represents the views of Parallax.
Paul,
Long time no hear. Good to see your post. Hope all is doing well.
I agree with what you wrote. There was not much info back at the roll out, but a lot of people made it work, with your help I might add.
To throw another stone at the hornets nest, anyone who claims they are a "professional programmer" and balks at learning another language is not a programmer at all, they are a coder.
I assume this applies to Spin/PASM programmers that are unwilling to learn C as well.
Does it mean that I'm a lowly coder if I haven't spent hours and hours learning Forth, or is there a special exemption for Forth?
I will now return back to working on my tiny C module in a giant software package.
The difference between a "lowly coder" and a "programmer" has more to do with how adaptable you are with the tools you're given and the circumstances. Why use Forth if you don't know it and there are other comparable tools at hand? On the other hand, it might be a great fit for the job and the time and effort might well be worth it. A good programmer hopefully has used enough different tools so that learning a new one is not very difficult. Also be careful if it's a consulting job that you get paid for the time involved remembering that being a professional means that you're supposed to know a lot already.
@Paul Baker: Hi Paul, Hope all is well with you! It's nice to see you on the forums, even if it is this thread.
I'm not sure what the this thread really accomplishes, but not every person who approaches the Propeller does so with the same background knowledge level or reason for doing so. It's silly to generalize everyone into a single category.
Someone who is a professional programmer or EE, there is more than plenty of resources which describe the Propeller in great detail.
Someone who is a hobbyist with "some" experience with other micro-controllers, there is about enough material now to make the transition.
Someone who is discovering the Propeller as their first experience with micro-controllers, then there is still some work to be done.
Agree'd that anyone who claims to be a professional programmer and can't learn a new language probably isn't.
To throw another stone at the hornets nest, anyone who claims they are a "professional programmer" and balks at learning another language is not a programmer at all, they are a coder.
For the record (for those of you who don't know me), I was one of the people asked to come out to Parallax for the unveiling of the Propeller chip (I later went to work for Parallax for a couple years). That first night, only armed with what Jeff Martin and Chip Gracey told us during that first day's presentation and armed with a grand total of roughly 3 sheets of paper (1 for the spin commands, one for the assembly commands and one giving a general overview of the architecture) I wrote a digital storage scope application for the Propeller.
Sorry to say this, but anyone who can't make heads or tails given the considerable documentation now at your disposal (some of which I helped to create) and unwilling to make use of the unparalleled forums to cover whatever small gaps exist in the documentation, should probably find another profession or find a job in a big firm where you code in C and are responsible for a tiny module in a giant software package.
PS as an ex-employee my opinion in no way represents the views of Parallax.
Paul,
I hope you become active on the forum.
Something to keep in mind is that not everyone here is a professional programmer or professional coder. I spent a lot of years writing machine control code but that was longer ago than I'd like to think about and I'm seriously out of "practice" and doubt I could do today what I used to do casually 20 years ago. While there things about spin that I'm not crazy about it is what it is and I do alright with it.
That said there are a lot of people looking at arduino, basic stamp, propeller that have never done any programming before. Heck it's hard to find a basic compiler/interpreter for windows or linux.
I assume this applies to Spin/PASM programmers that are unwilling to learn C as well.
Does it mean that I'm a lowly coder if I haven't spent hours and hours learning Forth, or is there a special exemption for Forth?
I will now return back to working on my tiny C module in a giant software package.
I think what Paul was trying to say (Please jump in and correct me if I'm wrong here Paul) was that a decent developer isn't so dogmatic that they won't be open to using/learning the appropriate micro/language/platform as the situation calls for. This may be mandated by employer standards or as an independent willing to look at the many micros and platforms that could all do the job.
Seems like Paul was venting on some who want to be spoon-fed everything and get bent when the documentation doesn't spell everything out in cookbook form.
Not to say you need to be proficient in everything, (Jack of all trades, master of none) after all that would be darn near impossible on the Propeller due to the OUTSTANDING user community here.
Sorry to say this, but anyone who can't make heads or tails given the considerable documentation now at your disposal (some of which I helped to create) and unwilling to make use of the unparalleled forums to cover whatever small gaps exist in the documentation, should probably find another profession or ...
I agree wholeheartedly the quoted part, not sure about the rest but just don't whine on the forums.
Paul's quote makes a great deal of sense if you contrast the Parallax/Propeller community with a comparable offering from Microchip, the Microstick and Microstick II.
To throw another stone at the hornets nest, anyone who claims they are a "professional programmer" and balks at learning another language is not a programmer at all, they are a coder.
For the record (for those of you who don't know me), I was one of the people asked to come out to Parallax for the unveiling of the Propeller chip (I later went to work for Parallax for a couple years). That first night, only armed with what Jeff Martin and Chip Gracey told us during that first day's presentation and armed with a grand total of roughly 3 sheets of paper (1 for the spin commands, one for the assembly commands and one giving a general overview of the architecture) I wrote a digital storage scope application for the Propeller.
Sorry to say this, but anyone who can't make heads or tails given the considerable documentation now at your disposal (some of which I helped to create) and unwilling to make use of the unparalleled forums to cover whatever small gaps exist in the documentation, should probably find another profession or find a job in a big firm where you code in C and are responsible for a tiny module in a giant software package.
PS as an ex-employee my opinion in no way represents the views of Parallax.
Apologies... unable to complete my above post on my xoom and ics.
I agree with Paul. Professional programmers will learn whatever language they need to get the job done. That of course doesnt mean there will not be some bias. I have never learnt C (properly at least) because I have never needed to.
Anyone using the prop today had to learn spin and/or pasm.
Documents are continually improving a,llthough some are still difficult to find. And us existing users often dont realise what has been added since we first arrived at the prop.
However, the main legitimate thrust of this thread is not by professionals, but rather by beginners who wish to be spoon fed instead of enrolling in a course or researching themselveds and asking when they get stuck or dont understand something.
I would have to say the language is VERY predictable. Give it the same line of code to run and you will get the same results. Nothing unpredictable about the language. The programmer who can't keep his indentions in order is the unpredictable variable in this equation.
I would have to say the language is VERY predictable. Give it the same line of code to run and you will get the same results. Nothing unpredictable about the language. The programmer who can't keep his indentions in order is the unpredictable variable in this equation.
You guys believe what you want.
But the bigs just aren't interested in (what THEY called) AMATUER level stuff.
As I understand the issue, it's because (as I said earlier)
remove the wrong space and you have changed the structure of the program.
Without the compiler saying a mumblin' word.
That's the major issue.
That's what J said was "unpredictable".
(actually he said quite a lot about such)
Ok when you work alone.
But, I'm told, Not so ok for a team effort.
Nor ok for a company to bet the farm on.
On the other hand, they ARE looking at the Propeller now.
Using Catalina C and Viewport.
I think I hear a lot of fragile ego on this subject - on both sides.
I try not to remain too constant in a constantly changing universe. If you go through life only accepting a few of the best, Spin should be in there regardless.
I am not a professional programmer at all. I like to write programs, and I like doing stuff, and often programming gets me to doing that stuff.
The early Propeller documents were reasonable. The best documentation there was? Code.
When I first encountered the Propeller, I was stunned at how it was designed. Heck, it's still stunning and a total romp! Digital playground as far as I am concerned. There wasn't cook book type documentation on a lot of stuff, but there were functional descriptions, and there was reference code. I think people forget about the value of reference code, looking to get text about it instead.
Truth is, parsing reference code is time very well spent! It contains in a few lines what would consume entire books! I like video related things, and found Chip's reference drivers extremely useful, and that's exactly what I still call them because they were the first real implementation of video on the chip that I saw and are shipped with the Propeller IDE. Chip is a mad genius though, so those took time. A few others since have made templates that are easier and still quite useful, each offering this capability of that, depending.
If there is anything that should come from this thread, it's that. Get the reference code and read it. Comment every single line, and if you don't know what a line does, ask, or tinker with it, or hit the functional docs or the docs on the discipline you are interested in (video, sound, I/O, etc...) and sort it out.
On that basis, I have found the Prop and it's SPIN + PASM very easy to consume on that basis, and that's by design people, just as Chip intended it to work.
Not everybody will go that route, but if you do, I think the rewards extend way past just getting your mind wrapped around this device.
To throw another stone at the hornets nest, anyone who claims they are a "professional programmer" and balks at learning another language is not a programmer at all, they are a coder.
In my opinion, this is the difference between a "professional programmer" and a "Software Engineer".
I consider myself a Software Engineer. I design algorithms to solve particular problems. The language that I write the solution in is irreverent.
Jim...
Huh? Oh, c'mon! That statement makes no sense whatsoever. I think those guys are just messing with you.
-Phil
"indented languages can be unpredictable." sort of makes sense.
A language that relies solely on white-space context, I would consider less than ideal.
A general use language should be able to $INCLUDE lines from another file, and just work, and conditional defines should also just work.
- but I will accept that Spin is not a General use language.
I think it is important to understand, when quibbling about things like the white space parsing in Spin or the lack of $INCLUDE, that Chip basically threw away the rule book when he sat down to design this microprocessor.
You know what he was thinking about when he designed the Propeller? Basic Stamps and the SX. He was not even remotely trying to design something that could run CP/M, much less Linux.
And so big RAM wasn't a high priority; the Propeller has more RAM than any previous Parallax product. Education was, and there enforcing indentation could be considered a good thing; I've seen some atrociously indented code from people who didn't quite know what they were doing. In Spin, you either indent correctly or it doesn't work.
The Windows dependency was unfortunate, but not a deal-killer since most of their market was going to be Windows based anyway. As for writing the compiler in assembly language I consider that Chip just showing off. :-)
If not for various FTDI driver problems I would consider the PropTool one of the most stable and predictable pieces of software I have ever used. Other than "No propeller chip found" it has always done exactly what I expected on every keypress, regardless of whatever else might be happening.
Some things I wish weren't there, like the way objects can't cheat and share data, are surely meant to be educational. The thing is, the CPU itself is a wonder of imaginative genius, and while it will never rival the raw power of a chip that runs at 2 GHz and can cook toast on the side, it is a singular and amazing collection of capabilities at a price point and with a convenience of use that I've never seen anywhere else. Well, I have seen something like that in one other place -- BASIC Stamps.
It's really wonderful how far the Propeller can be pushed beyond the initial vision of its design, but it's kind of silly to complain that it wasn't designed in accordance with some usual standard. Breaking free of the usual standards is the reason it exists.
I think it is important to understand, when quibbling about things like the white space parsing in Spin or the lack of $INCLUDE, that Chip basically threw away the rule book when he sat down to design this microprocessor.
You know what he was thinking about when he designed the Propeller? Basic Stamps and the SX. He was not even remotely trying to design something that could run CP/M, much less Linux.
And so big RAM wasn't a high priority; the Propeller has more RAM than any previous Parallax product. Education was, and there enforcing indentation could be considered a good thing; I've seen some atrociously indented code from people who didn't quite know what they were doing. In Spin, you either indent correctly or it doesn't work.
The Windows dependency was unfortunate, but not a deal-killer since most of their market was going to be Windows based anyway. As for writing the compiler in assembly language I consider that Chip just showing off. :-)
If not for various FTDI driver problems I would consider the PropTool one of the most stable and predictable pieces of software I have ever used. Other than "No propeller chip found" it has always done exactly what I expected on every keypress, regardless of whatever else might be happening.
Some things I wish weren't there, like the way objects can't cheat and share data, are surely meant to be educational. The thing is, the CPU itself is a wonder of imaginative genius, and while it will never rival the raw power of a chip that runs at 2 GHz and can cook toast on the side, it is a singular and amazing collection of capabilities at a price point and with a convenience of use that I've never seen anywhere else. Well, I have seen something like that in one other place -- BASIC Stamps.
It's really wonderful how far the Propeller can be pushed beyond the initial vision of its design, but it's kind of silly to complain that it wasn't designed in accordance with some usual standard. Breaking free of the usual standards is the reason it exists.
Well said localroger.
I would not go as far as being critical of Chip using pc (486etc) assembler for the compiler. After all, this should have been transferrable across all pc operating systems. He seems certainly more at home with lower level languages such as assemblers.
BUT, for 6 years ago, the Propeller micro had way more SRAM internally than any micro of the time. ANd because that could be used as code and/or data space, the prop was far more capable than most micros within reason and price) than its opposition. Six years later, a number of micros now have internal sram that can even surpass the 32KB (plus 8*2KB) this amount. In fact I have seem cheap micros (more expensive than the prop though) that have up to 96KB of sram, perhaps even higher. I only presume this 96KB can be used for code space. They do however have large flash amounts.
But Flash is nowhere near as versatile... you cannot continue to load various programs from SD cards into Flash. This is pretty much where we have taken the prop these days - and it was not its original intention.
All in all, the Prop is a great chip and a good price for what it has. It is extremely versatile meaning there are no family variants because of the soft peripherals. ANd the multi-cores means interrupts (and the inherent timing requirements) are not required. Only the prop enthusiasts seem to realise this is a great advantage, while others just complain that that is what they always did so the prop must be wrong - what nonsense.
Six years later, a number of micros now have internal sram that can even surpass the 32KB (plus 8*2KB) this amount. In fact I have seem cheap micros (more expensive than the prop though) that have up to 96KB of sram, perhaps even higher. I only presume this 96KB can be used for code space. They do however have large flash amounts.
As a recent reference point, see the recent Atmel M4, with 2MBytes FLASH, and 160K RAM, they claim $7.95/1K, in qfp100, and likely less in the 64 pin alternative. Full Speed USB and 4 uarts.
Only weak area seems to be timers, not many (3 x 16, or 2 x 3 x 16 depending on which doc you believe ), and WHY does anyone design a 32 bit, 120MHz part with only 16 bit timers ?!
Interrupts have been around forever, even the PC you used to surf the net and code for the Prop uses them and with no ill effects, not to mention devices like the Ipods to Boeing 757's all use micros with interrupts. Nor are they a mystery or hard to use, anyone who has been exposed to low level coding on conventional micros knows about them and how to use them. But there are some here who want to demonize interrupts and scare newbies about the evils of interrupts and how they rob determinism. They won't say it doesn't matter in most apps on conventional micros as long you're intelligent about using them.
The decision to not have interrupts was not made trivially. It was well thought out and deliberate. You're not going to get them. It's simply not part of the design philosophy. There's nothing evil about them. They're just not needed in a multiprocessing environment and they do mess up determinism unless you carefully turn them off some of the time. They're really a bear to handle when you've got a pipelined processor design since you either have to put them off while you empty the pipeline or you have to abort the pipeline in mid-process and undo some of the operations already performed to get things into a stable state to switch to another instruction stream with a saved state.
Comments
For the record (for those of you who don't know me), I was one of the people asked to come out to Parallax for the unveiling of the Propeller chip (I later went to work for Parallax for a couple years). That first night, only armed with what Jeff Martin and Chip Gracey told us during that first day's presentation and armed with a grand total of roughly 3 sheets of paper (1 for the spin commands, one for the assembly commands and one giving a general overview of the architecture) I wrote a digital storage scope application for the Propeller.
Sorry to say this, but anyone who can't make heads or tails given the considerable documentation now at your disposal (some of which I helped to create) and unwilling to make use of the unparalleled forums to cover whatever small gaps exist in the documentation, should probably find another profession or find a job in a big firm where you code in C and are responsible for a tiny module in a giant software package.
PS as an ex-employee my opinion in no way represents the views of Parallax.
Paul,
Long time no hear. Good to see your post. Hope all is doing well.
I agree with what you wrote. There was not much info back at the roll out, but a lot of people made it work, with your help I might add.
Jim
Does it mean that I'm a lowly coder if I haven't spent hours and hours learning Forth, or is there a special exemption for Forth?
I will now return back to working on my tiny C module in a giant software package.
I'm not sure what the this thread really accomplishes, but not every person who approaches the Propeller does so with the same background knowledge level or reason for doing so. It's silly to generalize everyone into a single category.
Agree'd that anyone who claims to be a professional programmer and can't learn a new language probably isn't.
OBC
Paul,
I hope you become active on the forum.
Something to keep in mind is that not everyone here is a professional programmer or professional coder. I spent a lot of years writing machine control code but that was longer ago than I'd like to think about and I'm seriously out of "practice" and doubt I could do today what I used to do casually 20 years ago. While there things about spin that I'm not crazy about it is what it is and I do alright with it.
That said there are a lot of people looking at arduino, basic stamp, propeller that have never done any programming before. Heck it's hard to find a basic compiler/interpreter for windows or linux.
I think what Paul was trying to say (Please jump in and correct me if I'm wrong here Paul) was that a decent developer isn't so dogmatic that they won't be open to using/learning the appropriate micro/language/platform as the situation calls for. This may be mandated by employer standards or as an independent willing to look at the many micros and platforms that could all do the job.
Seems like Paul was venting on some who want to be spoon-fed everything and get bent when the documentation doesn't spell everything out in cookbook form.
Not to say you need to be proficient in everything, (Jack of all trades, master of none) after all that would be darn near impossible on the Propeller due to the OUTSTANDING user community here.
I agree wholeheartedly the quoted part, not sure about the rest but just don't whine on the forums.
Paul's quote makes a great deal of sense if you contrast the Parallax/Propeller community with a comparable offering from Microchip, the Microstick and Microstick II.
If you think that Parallax's support/forums lacking somehow, check out this pathetic joke of a support forum for the Microsticks.
Reminds me of another poster here always saying, "well this 50 cent chip has interrupts, blah blah..."
Good points all in a strictly factual sense but technical specs alone aren't everything.
The user community means A LOT and the Propeller's is fantastic!
I agree with Paul. Professional programmers will learn whatever language they need to get the job done. That of course doesnt mean there will not be some bias. I have never learnt C (properly at least) because I have never needed to.
Anyone using the prop today had to learn spin and/or pasm.
Documents are continually improving a,llthough some are still difficult to find. And us existing users often dont realise what has been added since we first arrived at the prop.
However, the main legitimate thrust of this thread is not by professionals, but rather by beginners who wish to be spoon fed instead of enrolling in a course or researching themselveds and asking when they get stuck or dont understand something.
It's not about learning a new language.
It's just that indented languages can be unpredictable.
They (seriously) don't care for that.
It's not that they CAN'T.
The y just said, "No".
-Phil
You guys believe what you want.
But the bigs just aren't interested in (what THEY called) AMATUER level stuff.
As I understand the issue, it's because (as I said earlier)
remove the wrong space and you have changed the structure of the program.
Without the compiler saying a mumblin' word.
That's the major issue.
That's what J said was "unpredictable".
(actually he said quite a lot about such)
Ok when you work alone.
But, I'm told, Not so ok for a team effort.
Nor ok for a company to bet the farm on.
On the other hand, they ARE looking at the Propeller now.
Using Catalina C and Viewport.
I think I hear a lot of fragile ego on this subject - on both sides.
Me? I'm ok with Spin, as it does what I need.
Spent the better part of the evening playing with Chipmunk basic. It brought back a lot of fun memories!! Thanks for the pointer.
If something frustrates you, take a break.
I am not a professional programmer at all. I like to write programs, and I like doing stuff, and often programming gets me to doing that stuff.
The early Propeller documents were reasonable. The best documentation there was? Code.
When I first encountered the Propeller, I was stunned at how it was designed. Heck, it's still stunning and a total romp! Digital playground as far as I am concerned. There wasn't cook book type documentation on a lot of stuff, but there were functional descriptions, and there was reference code. I think people forget about the value of reference code, looking to get text about it instead.
Truth is, parsing reference code is time very well spent! It contains in a few lines what would consume entire books! I like video related things, and found Chip's reference drivers extremely useful, and that's exactly what I still call them because they were the first real implementation of video on the chip that I saw and are shipped with the Propeller IDE. Chip is a mad genius though, so those took time. A few others since have made templates that are easier and still quite useful, each offering this capability of that, depending.
If there is anything that should come from this thread, it's that. Get the reference code and read it. Comment every single line, and if you don't know what a line does, ask, or tinker with it, or hit the functional docs or the docs on the discipline you are interested in (video, sound, I/O, etc...) and sort it out.
On that basis, I have found the Prop and it's SPIN + PASM very easy to consume on that basis, and that's by design people, just as Chip intended it to work.
Not everybody will go that route, but if you do, I think the rewards extend way past just getting your mind wrapped around this device.
-Phil
In my opinion, this is the difference between a "professional programmer" and a "Software Engineer".
I consider myself a Software Engineer. I design algorithms to solve particular problems. The language that I write the solution in is irreverent.
Jim...
"indented languages can be unpredictable." sort of makes sense.
A language that relies solely on white-space context, I would consider less than ideal.
A general use language should be able to $INCLUDE lines from another file, and just work, and conditional defines should also just work.
- but I will accept that Spin is not a General use language.
This is a pretty easy thing to add, if you take off the NIH blinders.
CPP -- the C pre-processor handles #include #define and #ifdef, and can easily be modified to handle ' style comments.
It's open source, well tested, well documented, and well known. And also been missing from SPIN for a long time.
You know what he was thinking about when he designed the Propeller? Basic Stamps and the SX. He was not even remotely trying to design something that could run CP/M, much less Linux.
And so big RAM wasn't a high priority; the Propeller has more RAM than any previous Parallax product. Education was, and there enforcing indentation could be considered a good thing; I've seen some atrociously indented code from people who didn't quite know what they were doing. In Spin, you either indent correctly or it doesn't work.
The Windows dependency was unfortunate, but not a deal-killer since most of their market was going to be Windows based anyway. As for writing the compiler in assembly language I consider that Chip just showing off. :-)
If not for various FTDI driver problems I would consider the PropTool one of the most stable and predictable pieces of software I have ever used. Other than "No propeller chip found" it has always done exactly what I expected on every keypress, regardless of whatever else might be happening.
Some things I wish weren't there, like the way objects can't cheat and share data, are surely meant to be educational. The thing is, the CPU itself is a wonder of imaginative genius, and while it will never rival the raw power of a chip that runs at 2 GHz and can cook toast on the side, it is a singular and amazing collection of capabilities at a price point and with a convenience of use that I've never seen anywhere else. Well, I have seen something like that in one other place -- BASIC Stamps.
It's really wonderful how far the Propeller can be pushed beyond the initial vision of its design, but it's kind of silly to complain that it wasn't designed in accordance with some usual standard. Breaking free of the usual standards is the reason it exists.
Well said localroger.
I would not go as far as being critical of Chip using pc (486etc) assembler for the compiler. After all, this should have been transferrable across all pc operating systems. He seems certainly more at home with lower level languages such as assemblers.
BUT, for 6 years ago, the Propeller micro had way more SRAM internally than any micro of the time. ANd because that could be used as code and/or data space, the prop was far more capable than most micros within reason and price) than its opposition. Six years later, a number of micros now have internal sram that can even surpass the 32KB (plus 8*2KB) this amount. In fact I have seem cheap micros (more expensive than the prop though) that have up to 96KB of sram, perhaps even higher. I only presume this 96KB can be used for code space. They do however have large flash amounts.
But Flash is nowhere near as versatile... you cannot continue to load various programs from SD cards into Flash. This is pretty much where we have taken the prop these days - and it was not its original intention.
All in all, the Prop is a great chip and a good price for what it has. It is extremely versatile meaning there are no family variants because of the soft peripherals. ANd the multi-cores means interrupts (and the inherent timing requirements) are not required. Only the prop enthusiasts seem to realise this is a great advantage, while others just complain that that is what they always did so the prop must be wrong - what nonsense.
I
As a recent reference point, see the recent Atmel M4, with 2MBytes FLASH, and 160K RAM, they claim $7.95/1K, in qfp100, and likely less in the 64 pin alternative. Full Speed USB and 4 uarts.
Only weak area seems to be timers, not many (3 x 16, or 2 x 3 x 16 depending on which doc you believe ), and WHY does anyone design a 32 bit, 120MHz part with only 16 bit timers ?!
Interrupts have been around forever, even the PC you used to surf the net and code for the Prop uses them and with no ill effects, not to mention devices like the Ipods to Boeing 757's all use micros with interrupts. Nor are they a mystery or hard to use, anyone who has been exposed to low level coding on conventional micros knows about them and how to use them. But there are some here who want to demonize interrupts and scare newbies about the evils of interrupts and how they rob determinism. They won't say it doesn't matter in most apps on conventional micros as long you're intelligent about using them.
The decision to not have interrupts was not made trivially. It was well thought out and deliberate. You're not going to get them. It's simply not part of the design philosophy. There's nothing evil about them. They're just not needed in a multiprocessing environment and they do mess up determinism unless you carefully turn them off some of the time. They're really a bear to handle when you've got a pipelined processor design since you either have to put them off while you empty the pipeline or you have to abort the pipeline in mid-process and undo some of the operations already performed to get things into a stable state to switch to another instruction stream with a saved state.