I don't know what your real complaint is, but C is a must have for the P1/P2 if Parallax wants to have a shot at the industrial/commercial market. Look every MCU that comes out comes with a GCC compiler and debugger today. The days of putting out a new micro with a assembler and a BASIC(or Spin) interpreter are long gone. C is the language of choice for commercial embedded systems for all intents. Even on the hobbyist side it's going that way, AVR/PICs/ARM's boards all have C compilers.
Even FPGA based micros have GCC suites. Not having it available IMO for a new MCU is a black mark on any vendor.
And yes, even with C it will be a tough market for Parallax to get any sort of market share, but at least they'll have a fighting chance compared to putting a stall at ESC and showing their latest wares sans a C development suite.
Now for the Spin fans, none of this matters, you'll have Spin for the P2 and it will continue to be supported. For the for those who use C on a regular basis, there will C for the Prop which is a good thing.
I don't know what your real complaint is, but C is a must have for the P1/P2 if Parallax wants to have a shot at the industrial/commercial market.
How does this address, much less negate, the following statement: "C language support may be necessary, but is not likely sufficient to dramatically change the market landscape for the Prop." It seems we're talking past each other, or rather in circles, now.
Look every MCU that comes out comes with a GCC compiler and debugger today.
8051 relies on SDCC, not GCC (in addition to commercial tools, like Keil). Doesn't seem to have hurt it much. Probably there are others without GCC support as well.
Moreover, in commercial applications having GCC as an only option (for C) isn't always going to get your foot in the door anyway. Many many commercial concerns still do not want GPL tools and/or code anywhere near their products (and they find things like LGPL little or no consolation). They simply do not want the worry. We could get into the weeds on the legal details, but no matter, right or wrong that is how it is.
The days of putting out a new micro with a assembler and a BASIC(or Spin) interpreter are long gone. C is the language of choice for commercial embedded systems for all intents.
True in the main, yet in the long run, the trend will likely in fact be the opposite: HHLs a generation or so up from C. And there is still a huge demand for BASIC and similar "archaic" tools. Additionally, educators continue moving their interest away from C and C++ (eg, Python and the Raspberry Pi). And again, when you get down to it, quite often these are commercial tools being used in commercial products anyway.
Even on the hobbyist side it's going that way, AVR/PICs/ARM's boards all have C compilers.
They also have Pascal, BASIC, watered-down C++ (Arduino), and, in the case of ARM, many many other tools.
Even FPGA based micros have GCC suites. Not having it available IMO for a new MCU is a black mark on any vendor.
Not having good, free C tools... yes, a possible black mark. But who here said that wasn't the case?
And yes, even with C it will be a tough market for Parallax to get any sort of market share, but at least they'll have a fighting chance...
This does not in and of itself, and certainly not without other more fundamental issues being addressed, make for a fighting chance. To wit, the point some of us were making. That is all.
I'm still completely unclear as to why this is an issue. Granted, there may be other features of the P1 and P2 that will make it difficult for some people to adopt but why does that mean we shouldn't spend the effort to attempt to resolve at least one thing that gets in their way. Since it's been stated over and over that providing C/C++ does not mean there won't also be Spin, the fact that Parallax is working on a C/C++ compiler shouldn't be an issue. The resources that are being used to do that can't solve any of the other problems anyway. We can't add more memory to the P2 at this point or interrupts or any of the other Propeller features that some think drive people away from it. Or are you just saying that it's hopeless to get anyone else beyond the current Spin fans interested so we may as well not bother?
I'm still completely unclear as to why this is an issue. Granted, there may be other features of the P1 and P2 that will make it difficult for some people to adopt but why does that mean we shouldn't spend the effort to attempt to resolve at least one thing that gets in their way.
I guess I'm not completely clear as to why this particular point keeps coming up. Anyway, I'll repeat again: no one has said that the attempt is useless and futile. On the other hand, it (GCC) is not the answer to all the Propeller's marketing problems, and it is indeed possible to place too much emphasis on it, thinking that it is (or mostly is). Moreover, Spin will likely continue to play an important role in the Propeller's perceived ease-of-use and low cost of entry; that is, if it's allowed to do so.
Since it's been stated over and over that providing C/C++ does not mean there won't also be Spin, the fact that Parallax is working on a C/C++ compiler shouldn't be an issue.
Unless it detracts/distracts from other things; being that resources are generally limited, that is indeed possible.
The resources that are being used to do that can't solve any of the other problems anyway. We can't add more memory to the P2 at this point or interrupts or any of the other Propeller features that some think drive people away from it.
Do we truly know this? And are all other tools and documentation 100% perfect, in need of nothing further? Is Spin being relegated to second-class status (intentionally or not)? These (and others) seem to me valid questions. Maybe you're privy to the answers. I on the other hand am not, and it would appear that I'm not alone.
Or are you just saying that it's hopeless to get anyone else beyond the current Spin fans interested so we may as well not bother?
Again, no; not at all. But I will say this much. Unless the issues brought up in, for instance, this discussion are addressed, having a GCC toolchain for the Propeller will not make a substantial difference one way or the other (re the Propeller's market success or no). Whether fictional or real, they are issues that must be addressed somehow (ie, through either information and marketing, or actual revisions/improvements to tools, documentation and hardware). You'll notice, too, that the issues are in the main the same ones mentioned earlier. It's a fairly long thread, and while I could be wrong, C/C++ tools aren't mentioned once, and Spin only once or twice. (That's not to say I haven't seen C/C++ tools mentioned in this context, but they are not generally considered a foundational objection, such as unit cost vs features/advantages provided etc.)
Ok, what IS the answer then? The negative statements are dubious for reasons already given. You've as much as said they aren't futile, so great! We are in agreement, right? Let's get killer C on the Prop.
Ok, what IS the answer then? The negative statements are dubious for reasons already given. You've as much as said they aren't futile, so great! We are in agreement, right? Let's get killer C on the Prop.
Next.
And your answer is?
It's been given to you above, all you have to do is bother yourself enough to read and understand it. And not one bit of what I've said has been shown to be dubious, for any reasons, period. Repetition of points already handily dealt with, several times over, misunderstanding and misrepresenting what was said, do not consitute "reasons" given. Geez.
It's not so complicated: Don't put all eggs in the GCC basket. Don't throw the towel in on Spin (meaning not just the language/interpreter itself but tools, code, and documentation), either intentionally or merely through neglect. MOST OF ALL, for the Propeller to be a market success (meaning not ARM or AVR or PIC sales numbers but something Parallax can make a living from), the issues mentioned and linked to above likely must be somehow addressed.
Let's do it this way. Name one issue in that discussion, and I find it notable that an Internet discussion is being cited, and what your answer to it would be. It is really easy to make the kinds of statements you are. It's quite another to cite positive actionable things and show the merit of those.
So let's take one you mentioned right now: Don't throw the towel in on SPIN.
Have you seen that done? Can you cite a policy where SPIN is being tossed by the wayside? Neglect is mentioned here too. I can't comment to that, but I can very easily see resources prioritized in ways they believe make good sense. Perhaps you disagree?
Given those things, which are in fact dubious, let's clarify them. If you can cite a policy where SPIN is being given up on, great! Otherwise, how would you allocate those resources differently, and or what would you add to the mix that isn't there now and how does that balance with the P2 development, etc...?
Let's do it this way. Name one issue in that discussion, and I find it notable that an Internet discussion is being cited, and what your answer to it would be. It is really easy to make the kinds of statements you are. It's quite another to cite positive actionable things and show the merit of those.
This has grown tiring, and more than a bit absurd now. So let's do it this way: You go back and read and understand what has been written. Actionable specifics have been mentioned, more than once now, and more than enough for the context of this thread. It's simply boorish to continue harping, over and over, about things that are 1) either not an issue in the first place in this context or b) have been more than adequately addressed, several times over. All for the simple sake of saving face and keeping an already shopworn debate going.
Now for what I hope will be the one last piece of silliness ...
Given those things, which are in fact dubious, let's clarify them. If you can cite a policy where SPIN is being given up on, great!
A policy! Do you know what Parallax's policies are? Have they all been clearly spelled out to the nth degree so that each and every one of us here would know? Can you tell me what percentage, exactly, of resources is being given right now to Spin development/support? To upgrading the Propeller Tool (you know, so that maybe it can at least work seamlessly with an external editor, as most decent tools nowadays are able to do)? Expanding/improving Spin support under Linux/Unix?
And now the kicker, the very topic of this thread, how it all started. Did you bother to notice the OP's initial questions? I wonder where he got the impression that everything *might* be going GCC? Prop Tool might be deprecated? Etc... Look around the forums, maybe the answer is there. Just a crazy idea.
See, that's a lot harder.
Indeed, it seems with each pointless go 'round it gets more that way -- for you.
Frankly, when I wonder about something I just ask Parallax. It's a lot easier than complaining here.
Oh, and yes I DO have a rough idea of those things, just so you know. It's not hard. In fact, the few real concerns I've had, I very quickly learned to take them right to Parallax. And that's what I've done since. Let's just say I have no SPIN worries at this time. Try it. Ken is a nice guy. Seriously.
This debate seems to have degenerated into a meaningless ramble. So let me add some ramblings:)
potatohead,
3. Multi-core vs multi-processor or the word "cog".
I think the term "cog" needs to go away.
Away from Parallaxia back in the normal world these things are called "cores" or "processors". Anywone quickly scannning the Propeller data brief coming across "cog" is immediatly thrown sideways. If we want to remove barriers to acceptance we have to fix that.
Of course that means "cog" would have to be expunged from all marketing blurb and documentation and software. "cognew" world have to become "corestart" or some such.
XMOS goofed here. They have chips with 4 cores each of which can run 8 real-time (deterministic) threads. They have chips with one core only. At some point, to make things look better, some marketting type decided to advertise they have 8 or 1 "tiles" each of which has 8 "cores" (They wiggle out by saying "logical cores"). So "cores" became "tiles" and "thread" became "cores". This is not ony underhanded but confusing as all their documentation still uses the old nomenclature.
KC_Rob,
8051 relies on SDCC, not GCC (in addition to commercial tools, like Keil). Doesn't seem to have hurt it much. Probably there are others without GCC support as well.
It matters not. They have C. That is vital. Many would prefer GCC but many don't care.
Moreover, in commercial applications having GCC as an only option (for C) isn't always going to get your foot in the door anyway. Many many commercial concerns still do not want GPL tools and/or code anywhere near their products (and they find things like LGPL little or no consolation). They simply do not want the worry. We could get into the weeds on the legal details, but no matter, right or
wrong that is how it is.
My observation is very different. Pretty much every embedded system I have worked on or had first hand experience of has been done in GCC and using a lot of of open source / free software since the late 1990's. Cell tower microwave links, traffic light controllers, electronic bus ticket readers and on and on.
...in the long run, the trend will likely in fact be the opposite: HHLs a generation or so up from C....They also have Pascal, BASIC, watered-down C++ (Arduino), and, in the case of ARM, many many other tools.
I do believe you are right. (But since when was Pascal or BASIC a higher level language than C?) My prediction is that before long embedded systems will be programmed in JavaScript (You heard it here first and yes I'm serious. In fact I'm working on one already). By the way GCC provides C++ for the Propeller.
Here are some of the objections to the propeller from that thread KC_Rob linked to. Some are technical, some are not. Some are tackled by PII some are not. Some just show a miss-understanding of the Props design principles.
...it's not very fast and it's not very cheap (compared with a CortexM4 clocked at 150MHz or more)
...Then there is all the pain of programming and synching multiple cores which is (I think) worse than the pain of managing DMA on a typical M4 based micro-controller
...suffers from a less than first rank supplier which would worry most of my customers.
...small memories
...While the spin language is usable, there is nothing people like less then learning new weird languages.
...copy protection
...8 cores/threads is far too few to be able to dedicate a core to each task in non-trivial real world applications. And when
you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system.
...the 8 32-bit cores thing sounds nice, but no interrupts was a deal killer for me.
It's not so complicated: Don't put all eggs in the GCC basket. Don't throw the towel in on Spin (meaning not just the language/interpreter itself but tools, code, and documentation), either intentionally or merely through neglect. MOST OF ALL, for the Propeller to be a market success (meaning not ARM or AVR or PIC sales numbers but something Parallax can make a living from), the issues mentioned and linked to above likely must be somehow addressed.
Dubious enough?
Parallax is not putting all of the eggs in the GCC basket (an appropriate metaphor today since it's Easter!). It probably seems like that because the people working on GCC are far more active in these forums than the people inside of Parallax who are likely working on other important aspects of the P2 launch. I think the reason you don't see more activity on Spin for P2 is that Spin is Chip's baby and he is busy with hardware related details at this point. Chip will be the one to produce Spin for the P2 and it will get done when he has the time to work on it. Some of us have offered to help but Spin has always been Chip's project and it's likely to remain that way. However, we all know that Chip is very fond of Spin and we can be absolutely certain that he will have a new version available at P2 launch. I'm not speaking with any inside knowledge. I'm not a Parallax employee and have no inside knowledge. I'm just expressing my personal opinions.
It's been given to you above, all you have to do is bother yourself enough to read and understand it. And not one bit of what I've said has been shown to be dubious, for any reasons, period. Repetition of points already handily dealt with, several times over, misunderstanding and misrepresenting what was said, do not consitute "reasons" given. Geez.
I must have missed the reasons. Could someone repeat them for me? I understand the issue with C/C++ support but as of now the GCC port is going reasonably well and while the documentation is a little lacking but adequate for those that know C/C++.
The lack of interrupts is what it is and I don't see any chips coming from parallax having interrupts ever. Chip has more than once made his opinion about them known.
potatohead says: "Frankly, when I wonder about something I just ask Parallax. It's a lot easier than complaining here."
That's not what the forums here are for? To talk about - complain or no - Parallax tools and products? No Parallax staff should ever be expected to read any of this? Yeah, makes sense to me.
heater says: "This debate seems to have degenerated into a meaningless ramble."
Don't they all? It would help, however, if people wouldn't take stuff out of context and gloss everything with a simple binary meaning ("either yer for it or again' it").
heater says:
"KC_Rob
8051 relies on SDCC, not GCC (in addition to commercial tools, like Keil). Doesn't seem to have hurt it much. Probably there are others without GCC support as well.
It matters not. They have C. That is vital. Many would prefer GCC but many don't care."
It does matter when responding to this specific statement: " Look every MCU that comes out comes with a GCC compiler and debugger today."
And you are, in fact, making my point for me, in a roundabout way.
heater says:
"My observation is very different. Pretty much every embedded system I have worked on or had first hand experience of has been done in GCC and using a lot of of open source / free software since the late 1990's. Cell tower microwave links, traffic light controllers, electronic bus ticket readers and on and on."
Well, our "observations" do indeed differ by a fair amount then. This is a concern for many commercial outfits, though perhaps diminishing with time, especially for small- to medium-sized firms that do not have a gaggle of lawyers on hand to analyze and fret over such things and to leap into action if needed. It is indeed a legitimate concern and far be it from me to tell a client that it absolutely isn't, especially since I am not a lawyer.
IAR et al. still sell compilers (often for fairly big $$$) for good reason, and not only because their tools are often seen as being more polished etc.
heater says: "I do believe you are right. (But since when was Pascal or BASIC a higher level language than C?)"
Did I say they were? (Read what I wrote again.)
heater says: "My prediction is that before long embedded systems will be programmed in JavaScript (You heard it here first and yes I'm serious. In fact I'm working on one already). "
I wouldn't be too surprised. In general, we agree: the trend will be, in the long-run, away from C/C++ for embedded work.
heater says: "Here are some of the objections to the propeller from that thread KC_Rob linked to. ...
...8 cores/threads is far too few to be able to dedicate a core to each task in non-trivial real world applications. And when
you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system."
This one is, I think, particularly important (not to dismiss all the others). It is my belief that people would feel much more comfortable with the Propeller concept (no interrupts,
soft peripherals, etc.) if they could be sure that eight cores are truly enough for real-world applications. More cores would of course then go a long way to putting to rest such worries.
Thank you for copying some of the reasons given to here.
David Betz says: "Parallax is not putting all of the eggs in the GCC basket (an appropriate metaphor today since it's Easter!). It probably seems like that because the people working on GCC are far more active in these forums than the people inside of Parallax who are likely working on other important aspects of the P2 launch..."
You at least see cause, then, for the OP and its questions, and in turn for my reply. Also, you like my little bit-o' Easter word-play... so we're good, right?
And from out in left field...
I am actually looking forward to exploring the Propeller 2 via Forth in real-time. There is a place for an interpreted language in getting started with Propellers 1 & 2.
Well, Spin is certainly not a higher level language than C/C++ either so if people are moving away from C/C++, I doubt they will move towards Spin.
Compared to C? You sure about that? And regardless of the particular merits of Spin, the essential point still stands: GCC isn't the ultimate answer in and of itself. Further, it would be, in my view, careless to throw out or badly neglect Spin for its sake alone. Others seem to agree with me, probably for the reasons given by the OP.
Compared to C? You sure about that? And regardless of the particular merits of Spin, the essential point still stands: GCC isn't the ultimate answer in and of itself. Further, it would be, in my view, careless to throw out or badly neglect Spin for its sake alone. Others seem to agree with me, probably for the reasons given by the OP.
No, Spin is not higher level that C. It has no structures. You can't pass objects by reference. It has no type system. It's "object system" is minimal (although useful). I would definitely consider C to be a more capable language than Spin. However, I certainly think Spin is a useful and necessary language for the P1 and P2 and would be happy to help build a P2 version if Parallax was interested in my help but they are not.
And from out in left field...
I am actually looking forward to exploring the Propeller 2 via Forth in real-time. There is a place for an interpreted language in getting started with Propellers 1 & 2.
Not so far out. Forth support for the Propeller is amazing... and only getting better. I've played with TACHYON and PropForth, both are impressive. If Forth is your thing, or if you're just curious about it, Propeller is the way to go. Little question in my mind about that -- unless, that is, you have money to burn for SwiftX or MPE.
No, Spin is not higher level that C. It has no structures. You can't pass objects by reference. It has no type system. It's "object system" is minimal (although useful). I would definitely consider C to be a more capable language than Spin. However, I certainly think Spin is a useful and necessary language for the P1 and P2 and would be happy to help build a P2 version if Parallax was interested in my help but they are not.
We're talking running on the Propeller, not in general, since Spin is not a general purpose language. So, on the Prop itself, I would disagree - at least at this stage. Spin, a language newer than C and designed specifically for the Propeller, is indeed quite well-suited for its intended purpose.
We're talking running on the Propeller, not in general, since Spin is not a general purpose language. So, on the Prop itself, I would disagree - at least at this stage. Spin, a language newer than C and designed specifically for the Propeller, is indeed quite well-suited for its intended purpose.
Those statements are all quite true but I still don't consider it "higher level" than C even on the Propeller. It is, as you say, very well suited the Propeller though.
Can we move idealogy discussions elsewhere? This forum is intended for people who are using PropellerGCC.
"Ideology discussions"... LOL! One man's ideology discussion is another man's... oh, never mind. Anyway, the thread seems to be winding down regardless; so yeah, sure.
After people have tried their best at programming in Spin for a while and moved on to some more complex ideas you will find them here asking questions as to how to proceed. Those questions would be better answered if they were using C/C++ or in the extreme Lisp, Scheme or even JavaScript.
KC_Rob,
After people have tried their best at programming in Spin for a while and moved on to some more complex ideas you will find them here asking questions as to how to proceed...
Methinks you have, at the minimum, overstated this, considering the quantity and quality of Spin/PASM code on the OBEX. No matter, the whole issue of Spin vs C - re "high level" languages - is in the main one more tangent at this point.
Now quiet! Did you not see that there are to be no more "ideological discussions" on this forum?!
He, he. There is no doubt you can write quality code in petty much any Turing complete system. In fact, looked at that way all programming languages are equivalent. Just for fun, check out http://catb.org/jargon/html/story-of-mel.html to see what can be done.
Comments
I don't know what your real complaint is, but C is a must have for the P1/P2 if Parallax wants to have a shot at the industrial/commercial market. Look every MCU that comes out comes with a GCC compiler and debugger today. The days of putting out a new micro with a assembler and a BASIC(or Spin) interpreter are long gone. C is the language of choice for commercial embedded systems for all intents. Even on the hobbyist side it's going that way, AVR/PICs/ARM's boards all have C compilers.
Even FPGA based micros have GCC suites. Not having it available IMO for a new MCU is a black mark on any vendor.
And yes, even with C it will be a tough market for Parallax to get any sort of market share, but at least they'll have a fighting chance compared to putting a stall at ESC and showing their latest wares sans a C development suite.
Now for the Spin fans, none of this matters, you'll have Spin for the P2 and it will continue to be supported. For the for those who use C on a regular basis, there will C for the Prop which is a good thing.
It's a win for all.
8051 relies on SDCC, not GCC (in addition to commercial tools, like Keil). Doesn't seem to have hurt it much. Probably there are others without GCC support as well.
Moreover, in commercial applications having GCC as an only option (for C) isn't always going to get your foot in the door anyway. Many many commercial concerns still do not want GPL tools and/or code anywhere near their products (and they find things like LGPL little or no consolation). They simply do not want the worry. We could get into the weeds on the legal details, but no matter, right or wrong that is how it is.
True in the main, yet in the long run, the trend will likely in fact be the opposite: HHLs a generation or so up from C. And there is still a huge demand for BASIC and similar "archaic" tools. Additionally, educators continue moving their interest away from C and C++ (eg, Python and the Raspberry Pi). And again, when you get down to it, quite often these are commercial tools being used in commercial products anyway.
They also have Pascal, BASIC, watered-down C++ (Arduino), and, in the case of ARM, many many other tools.
Not having good, free C tools... yes, a possible black mark. But who here said that wasn't the case?
This does not in and of itself, and certainly not without other more fundamental issues being addressed, make for a fighting chance. To wit, the point some of us were making. That is all.
Unless it detracts/distracts from other things; being that resources are generally limited, that is indeed possible.
Do we truly know this? And are all other tools and documentation 100% perfect, in need of nothing further? Is Spin being relegated to second-class status (intentionally or not)? These (and others) seem to me valid questions. Maybe you're privy to the answers. I on the other hand am not, and it would appear that I'm not alone.
Again, no; not at all. But I will say this much. Unless the issues brought up in, for instance, this discussion are addressed, having a GCC toolchain for the Propeller will not make a substantial difference one way or the other (re the Propeller's market success or no). Whether fictional or real, they are issues that must be addressed somehow (ie, through either information and marketing, or actual revisions/improvements to tools, documentation and hardware). You'll notice, too, that the issues are in the main the same ones mentioned earlier. It's a fairly long thread, and while I could be wrong, C/C++ tools aren't mentioned once, and Spin only once or twice. (That's not to say I haven't seen C/C++ tools mentioned in this context, but they are not generally considered a foundational objection, such as unit cost vs features/advantages provided etc.)
Next.
And your answer is?
Go ahead. One positive statement that will make an impact will do.
Dubious enough?
Let's do it this way. Name one issue in that discussion, and I find it notable that an Internet discussion is being cited, and what your answer to it would be. It is really easy to make the kinds of statements you are. It's quite another to cite positive actionable things and show the merit of those.
So let's take one you mentioned right now: Don't throw the towel in on SPIN.
Have you seen that done? Can you cite a policy where SPIN is being tossed by the wayside? Neglect is mentioned here too. I can't comment to that, but I can very easily see resources prioritized in ways they believe make good sense. Perhaps you disagree?
Given those things, which are in fact dubious, let's clarify them. If you can cite a policy where SPIN is being given up on, great! Otherwise, how would you allocate those resources differently, and or what would you add to the mix that isn't there now and how does that balance with the P2 development, etc...?
See, that's a lot harder. Now, your answers are?
This has grown tiring, and more than a bit absurd now. So let's do it this way: You go back and read and understand what has been written. Actionable specifics have been mentioned, more than once now, and more than enough for the context of this thread. It's simply boorish to continue harping, over and over, about things that are 1) either not an issue in the first place in this context or b) have been more than adequately addressed, several times over. All for the simple sake of saving face and keeping an already shopworn debate going.
Now for what I hope will be the one last piece of silliness ...
A policy! Do you know what Parallax's policies are? Have they all been clearly spelled out to the nth degree so that each and every one of us here would know? Can you tell me what percentage, exactly, of resources is being given right now to Spin development/support? To upgrading the Propeller Tool (you know, so that maybe it can at least work seamlessly with an external editor, as most decent tools nowadays are able to do)? Expanding/improving Spin support under Linux/Unix?
And now the kicker, the very topic of this thread, how it all started. Did you bother to notice the OP's initial questions? I wonder where he got the impression that everything *might* be going GCC? Prop Tool might be deprecated? Etc... Look around the forums, maybe the answer is there. Just a crazy idea.
Indeed, it seems with each pointless go 'round it gets more that way -- for you.
Frankly, when I wonder about something I just ask Parallax. It's a lot easier than complaining here.
Oh, and yes I DO have a rough idea of those things, just so you know. It's not hard. In fact, the few real concerns I've had, I very quickly learned to take them right to Parallax. And that's what I've done since. Let's just say I have no SPIN worries at this time. Try it. Ken is a nice guy. Seriously.
potatohead, I think the term "cog" needs to go away.
Away from Parallaxia back in the normal world these things are called "cores" or "processors". Anywone quickly scannning the Propeller data brief coming across "cog" is immediatly thrown sideways. If we want to remove barriers to acceptance we have to fix that.
Of course that means "cog" would have to be expunged from all marketing blurb and documentation and software. "cognew" world have to become "corestart" or some such.
XMOS goofed here. They have chips with 4 cores each of which can run 8 real-time (deterministic) threads. They have chips with one core only. At some point, to make things look better, some marketting type decided to advertise they have 8 or 1 "tiles" each of which has 8 "cores" (They wiggle out by saying "logical cores"). So "cores" became "tiles" and "thread" became "cores". This is not ony underhanded but confusing as all their documentation still uses the old nomenclature.
KC_Rob, It matters not. They have C. That is vital. Many would prefer GCC but many don't care. My observation is very different. Pretty much every embedded system I have worked on or had first hand experience of has been done in GCC and using a lot of of open source / free software since the late 1990's. Cell tower microwave links, traffic light controllers, electronic bus ticket readers and on and on. I do believe you are right. (But since when was Pascal or BASIC a higher level language than C?) My prediction is that before long embedded systems will be programmed in JavaScript (You heard it here first and yes I'm serious. In fact I'm working on one already). By the way GCC provides C++ for the Propeller.
...it's not very fast and it's not very cheap (compared with a CortexM4 clocked at 150MHz or more)
...Then there is all the pain of programming and synching multiple cores which is (I think) worse than the pain of managing DMA on a typical M4 based micro-controller
...suffers from a less than first rank supplier which would worry most of my customers.
...small memories
...While the spin language is usable, there is nothing people like less then learning new weird languages.
...copy protection
...8 cores/threads is far too few to be able to dedicate a core to each task in non-trivial real world applications. And when
you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system.
...the 8 32-bit cores thing sounds nice, but no interrupts was a deal killer for me.
I must have missed the reasons. Could someone repeat them for me? I understand the issue with C/C++ support but as of now the GCC port is going reasonably well and while the documentation is a little lacking but adequate for those that know C/C++.
The lack of interrupts is what it is and I don't see any chips coming from parallax having interrupts ever. Chip has more than once made his opinion about them known.
That's not what the forums here are for? To talk about - complain or no - Parallax tools and products? No Parallax staff should ever be expected to read any of this? Yeah, makes sense to me.
heater says: "This debate seems to have degenerated into a meaningless ramble."
Don't they all?
heater says:
"KC_Rob
8051 relies on SDCC, not GCC (in addition to commercial tools, like Keil). Doesn't seem to have hurt it much. Probably there are others without GCC support as well.
It matters not. They have C. That is vital. Many would prefer GCC but many don't care."
It does matter when responding to this specific statement: " Look every MCU that comes out comes with a GCC compiler and debugger today."
And you are, in fact, making my point for me, in a roundabout way.
heater says:
"My observation is very different. Pretty much every embedded system I have worked on or had first hand experience of has been done in GCC and using a lot of of open source / free software since the late 1990's. Cell tower microwave links, traffic light controllers, electronic bus ticket readers and on and on."
Well, our "observations" do indeed differ by a fair amount then. This is a concern for many commercial outfits, though perhaps diminishing with time, especially for small- to medium-sized firms that do not have a gaggle of lawyers on hand to analyze and fret over such things and to leap into action if needed. It is indeed a legitimate concern and far be it from me to tell a client that it absolutely isn't, especially since I am not a lawyer.
IAR et al. still sell compilers (often for fairly big $$$) for good reason, and not only because their tools are often seen as being more polished etc.
heater says: "I do believe you are right. (But since when was Pascal or BASIC a higher level language than C?)"
Did I say they were? (Read what I wrote again.)
heater says: "My prediction is that before long embedded systems will be programmed in JavaScript (You heard it here first and yes I'm serious. In fact I'm working on one already). "
I wouldn't be too surprised. In general, we agree: the trend will be, in the long-run, away from C/C++ for embedded work.
heater says: "Here are some of the objections to the propeller from that thread KC_Rob linked to. ...
...8 cores/threads is far too few to be able to dedicate a core to each task in non-trivial real world applications. And when
you have to multiplex tasks within each core/thread, you have lost much of the elegance that you had by using the multi-core system."
This one is, I think, particularly important (not to dismiss all the others). It is my belief that people would feel much more comfortable with the Propeller concept (no interrupts,
soft peripherals, etc.) if they could be sure that eight cores are truly enough for real-world applications. More cores would of course then go a long way to putting to rest such worries.
Thank you for copying some of the reasons given to here.
David Betz says: "Parallax is not putting all of the eggs in the GCC basket (an appropriate metaphor today since it's Easter!). It probably seems like that because the people working on GCC are far more active in these forums than the people inside of Parallax who are likely working on other important aspects of the P2 launch..."
You at least see cause, then, for the OP and its questions, and in turn for my reply. Also, you like my little bit-o' Easter word-play... so we're good, right?
I am actually looking forward to exploring the Propeller 2 via Forth in real-time. There is a place for an interpreted language in getting started with Propellers 1 & 2.
Yes.
After people have tried their best at programming in Spin for a while and moved on to some more complex ideas you will find them here asking questions as to how to proceed. Those questions would be better answered if they were using C/C++ or in the extreme Lisp, Scheme or even JavaScript.
Now quiet! Did you not see that there are to be no more "ideological discussions" on this forum?!
He, he. There is no doubt you can write quality code in petty much any Turing complete system. In fact, looked at that way all programming languages are equivalent. Just for fun, check out http://catb.org/jargon/html/story-of-mel.html to see what can be done.
What? Me? "Ideological" no, never.