ICC Development is on hold. As a commercial company, we need to pay bills with income from sales of our products. For the time being, Prop I C compilers are not entirely commercially viable, mainly due to factors beyond our control.
When Prop II is released, we will revisit the decision.
And I dispute greatly that a GCC port will help in any way. ZOG is all you need to move in their direction. So is ZOG a success for commercial development? If so, then yes, GCC is what people want.
A Prop 1.5 with 64 IO pins will greatly help in creating a usable fast expanded SRAM solution. However, that is unlikely to come from Parallax. So we will wait for Prop II, hopefully no like Godot :-)
May I put this in contrast to quotes from ImageCrafts home page?
"You are not buying a compiler, you are buying unparalleled support."
"Richard is maniacal in support." -- Jack P.
"Support from Imagecraft is second to none." -- Andrew
Until now, not even the included help files match those on the ICC web-site.
After more than a year.
And: "optimizations"
I do not think a compiler site does optimizations when he links an unreferenced library (float) and emits useless opcodes. The linker only links complete compilation units, even unused functions.
Richard, if you don't fix those things (you got my list), "Prop I C compilers are not entirely commercially viable". No wonder.
Zog is very pleased to get so many mentions in a discussion between such esteemed participants. He will now get back to sleep contentedly in his iceberg.
Richard,
....mainly due to factors beyond our control.
I still maintain that:
1) We love the Prop and it's "out of the box" architecture.
2) Us hard core C heads love to have C on the Prop.
3) C is not actually practically useful on the Prop.
The thing that frustrates us is that 3) is due to 1).
C on the Prop is like a dog doing tricks, as they say, the wonder is not that it does it well but that it does it at all.
C on the Prop lacks the native speed that C users are used to whilst at the same time being rather wasteful of space. It's rather a hard sell when up against Spin and PASM.
The lack of a Prop I with 64 IO's and hence easy program space expansion is heartbreaking but I suspect it's time has well and truly passed.
We look forward to Catalina and ICC on the Prop II where C can breath more easily.
Unfortunately, even with Prop II, it seems that C will still be challenged on the Propeller. Yes, we will have more hub RAM and more I/O to connect external RAMs. However, how fast will C code running from either run compared with C code running native on any other 32 bit or even 16 bit microcontroller. It may be that C is still not a viable language for the Propeller even with Prop II. I'd still like to see an architecture more like the Cell where the COGs are used for what they are good for, virtual peripherals, and a more standard CPU core (ARM maybe) is also available to run the main loop.
May I put this in contrast to quotes from ImageCrafts home page?
"You are not buying a compiler, you are buying unparalleled support."
"Richard is maniacal in support." -- Jack P.
"Support from Imagecraft is second to none." -- Andrew
Until now, not even the included help files match those on the ICC web-site.
After more than a year.
And: "optimizations"
I do not think a compiler site does optimizations when he links an unreferenced library (float) and emits useless opcodes. The linker only links complete compilation units, even unused functions.
Richard, if you don't fix those things (you got my list), "Prop I C compilers are not entirely commercially viable". No wonder.
Nick
Nick, when you throw in real development budget and not get a reasonable return, then we can talk. We can do all those but it's throwing more money at a problem not by us.
And if anyone thinks LMM is the problem, they can feel free to hack small C or LCC to target COG.
C can shine on Prop 1.5 or Prop II. Until then.
Notice no one is making real money on software tools for the Prop, as far as I know. I might very well be wrong of course. Give me proof please.
We knew the risks coming in. We got burned. Not a problem. We win some, we lose some. Live and learn.
Anyone else who think they can solve the C for Prop problem for a commercially viable product, feel free. Go for it!
However, how fast will C code running from either run compared with C code running native on any other 32 bit or even 16 bit microcontroller. It may be that C is still not a viable language for the Propeller even with Prop II.
I don't think so, but I do like C.
ICC-code runs quite fast, compared to Spin. But of course, slower than ASM. If your code has a good balance between C and ASM you do have all advantages of both worlds. Extremely fast code in ASM that does some sub-tasks that are time-critical, yet small enough to be coded in ASM and on the other hand better abstraction with C.
C on the Prop is a failure like any other language. :smilewinkgrin:
homespun.exe doesn't want to run:
OS: XP-pro, current patches.
homespun is 2009.10.05, size 144KB (from Catalina_2.6_Win.zip), patch 2.7 applied, but no newer version.
The message is (translated) something like "Application could not be properly initialized (0xc0000135)"
I'm sorry for such a low-lever question.
Nick
Hi Nick,
No worries about the question. It's exactly things like this that I need to find out. In this case (as jazzed already pointed out) it's because you don't have .NET installed. You need to install the Microsoft .NET Framework Version 2.0 Redistributable Package (x86) (here). Note that you need 2.0 even if you have a later version installed.
It never occured to me that someone might not have this installed under Windows. I'll add a note to the Catalina documentation.
I don't think so, but I do like C.
ICC-code runs quite fast, compared to Spin. But of course, slower than ASM. If your code has a good balance between C and ASM you do have all advantages of both worlds. Extremely fast code in ASM that does some sub-tasks that are time-critical, yet small enough to be coded in ASM and on the other hand better abstraction with C.
C on the Prop is a failure like any other language. :smilewinkgrin:
Nick
Well, not a failure, just not always the best choice I suppose. You have to match the language with the problem I guess. Spin and PASM will certainly be the best languages for the Propeller and probably also the Propeller II. It's just that sometimes you want to port something that was written in a more traditional language like C and then it helps to have that option available as well.
Unfortunately, even with Prop II, it seems that C will still be challenged on the Propeller. Yes, we will have more hub RAM and more I/O to connect external RAMs. However, how fast will C code running from either run compared with C code running native on any other 32 bit or even 16 bit microcontroller. It may be that C is still not a viable language for the Propeller even with Prop II. I'd still like to see an architecture more like the Cell where the COGs are used for what they are good for, virtual peripherals, and a more standard CPU core (ARM maybe) is also available to run the main loop.
Hi David,
As you might guess, I disagree with this view :smilewinkgrin: (and also with Heater's comment that "C is not actually practically useful on the Prop").
I think C is quite functional on the Prop I for what the Prop was originally intended for - i.e. small embedded applications that need a very flexible microcontroller. The problem is that many of us (including me!) are trying to run operating systems and other large applications that are more suited to a microprocessor. And when the results are mediocre (compared to what is possible on other microprocessors) we tend to blame either the tools or the architecture of the Propeller - very few of us will acknowledge that we were probably being a bit dumb to attempt such things in the first place (including me, naturally!).
This is the point I was trying to make earlier about a GNU port to the Propeller - the first thing some of us would try to do is download the Linux sources and attempt to compile the Linux Kernel - and when this turns out to be impractical we will either blame the quality of the port or (worse!) blame the Propeller itself. The Propeller is not a general purpose microprocessor, and it is not a transputer. If what you really needed was one of those, then the Propeller is always going to be a second-best solution.
If you wonder why Parallax has not rushed off to do a GNU port then it may be because they knew this already, and also that they would be on a hiding to nothing.
I maintain that C is fine on the Prop I if used where it is appropriate to do so - and also that it will be even better on the Prop II!
Of course, I realize I am usually in a minority of one here - I'm used to that .
A lot of us either can't install .NET (WinXP SP1) or simply refuse acquiescence to the bloat that it entails.
-Phil
Hi Phil,
I can certainly understand this! Unfortunately, there's not much I can do about it right now. I have plans to also support bst as an alternative assembler to Homespun, but it's a matter of finding the time.
I maintain that C is fine on the Prop I if used where it is appropriate to do so - and also that it will be even better on the Prop II!
Of course, I realize I am usually in a minority of one here - I'm used to that .
Ross.
I agree that C is fine on the Propeller for certain applications. It's just that the Propeller is not likely to be the best microcontroller for running C programs where very high performance is necessary.
If you wonder why Parallax has not rushed off to do a GNU port then it may be because ....
1) Parallax is primarily a BASIC/Delphi shop (core competency).
2) Propeller is only serious for small things regardless of what we do (right-sizing).
3) There are lots of alternatives that already do industry standard GNU (staying in the niche).
4) Basic stamp customers don't want to learn C (repeat customers)
5) Chip and others would have less creative outlet (happy staff).
6) Ross and Richard would have less opportunities to compete (vendor relationships).
I guess all of this talk has been hyphothetical. It would be nice to hear from people who are using C on the Propeller for something other than running benchmarks. What has your experience been like? Has it worked well for you? How could the various C compiler options be improved?
I haven't tried ICC but I have used Catalina and have been playing with GCC/ZOG and I've had a lot of fun with both. I have successfully built and run a simple Basic bytecode compiler under ZOG (had to split it into three phases to get it to fit in 64k of SPI SRAM). I'd love to try it under Catalina as well but I have to setup a system with a big external RAM before I'll be able to do that.
I simply use the tool that is required to accomplish the task at hand.
With the Prop, that usually means Spin+PASM, however I did play a bit with both Catalina and Gcc for Zog - and like both.
Right now, I am concentrating on hardware and consulting, so I have put PropellerBasic on hold - and frankly, I don't think there is a market for a commercial optimizing LMM Basic compiler yet.
As soon as I am done with the boards I showed at UPEW, I will resume work on a large VMCOG - which will support a mix of SPI ram/flash for a really big VM.
I guess all of this talk has been hyphothetical. It would be nice to hear from people who are using C on the Propeller for something other than running benchmarks. What has your experience been like? Has it worked well for you? How could the various C compiler options be improved?
I haven't tried ICC but I have used Catalina and have been playing with GCC/ZOG and I've had a lot of fun with both. I have successfully built and run a simple Basic bytecode compiler under ZOG (had to split it into three phases to get it to fit in 64k of SPI SRAM). I'd love to try it under Catalina as well but I have to setup a system with a big external RAM before I'll be able to do that.
I guess all of this talk has been hyphothetical. It would be nice to hear from people who are using C on the Propeller for something other than running benchmarks. What has your experience been like? Has it worked well for you? How could the various C compiler options be improved?
I haven't tried ICC but I have used Catalina and have been playing with GCC/ZOG and I've had a lot of fun with both. I have successfully built and run a simple Basic bytecode compiler under ZOG (had to split it into three phases to get it to fit in 64k of SPI SRAM). I'd love to try it under Catalina as well but I have to setup a system with a big external RAM before I'll be able to do that.
As soon as I am done with the boards I showed at UPEW, I will resume work on a large VMCOG - which will support a mix of SPI ram/flash for a really big VM.
Cool! That is just what I need to be able to merge my three phase compiler along with its VM and an editor back into a single executable that can live in flash. I'm looking forward to porting your large memory VMCOG to the C3!
Everything I've done for Propeller was in Spin/PASM except for porting some drivers for C. The problem is I constantly run out of memory ... LMM C can not compete with SPIN for compactness. Period. External memory platforms so far have horrible economics. So I slog on trying to find better solutions. Sorry I'm so hard to please.
This thread like many others on C can be entertaining, but they usually don't achieve anything good. So now my first comments on this thread can be taken in full perspective
What new things have we learned?
1) Catalina has made some progress with making more memory available.
2) ImageCraft states that ICC for Propeller is not a viable product.
3) Not everyone likes .net
4) Apparently there are very few people writing Propeller applications in C.
Everything I've done for Propeller was in Spin/PASM except for porting some drivers for C. The problem is I constantly run out of memory ... LMM C can not compete with SPIN for compactness. Period. External memory platforms so far have horrible economics. So I slog on trying to find better solutions. Sorry I'm so hard to please.
This thread like many others on C can be entertaining, but they usually don't achieve anything good. So now my first comments on this thread can be taken in full perspective
What new things have we learned?
1) Catalina has made some progress with making more memory available.
2) ImageCraft states that ICC for Propeller is not a viable product.
3) Not everyone likes .net
4) Apparently there are very few people writing Propeller applications in C.
5. Lots of people want to use C on the Propeller (I and II)
6. Catalina will continue to innovate on the Prop I
6. Catalina will be the logical choice of language for the Prop II
It would be nice to hear from people who are using C on the Propeller for something other than running benchmarks.
I have implemented a Modbus-client. This Modbus-interface does most of the digital IO for my MAHO 700C mill. 3.1 tons, not a toy! The original control was broken, so I replaced it with EMC2. Right now, I designed a different Modbus-interface (more compact, with LCD) that will go into the hand wheel (= remote handle with a jog wheel, some push buttons, rotary switches and LEDs).
Response time is critical in this application, so SPIN was no option for me (it isn't an option for me anyhow).
Extending the Prop with external RAM for code is -in my eyes- useless. It's a crutch. It works, but is not well integrated. It simply is beyond the capabilities of the Prop. Yes, some got this working. But that doesn't mean it's an elegant solution.
I have implemented a Modbus-client. This Modbus-interface does most of the digital IO for my MAHO 700C mill. 3.1 tons, not a toy! The original control was broken, so I replaced it with EMC2. Right now, I designed a different Modbus-interface (more compact, with LCD) that will go into the hand wheel (= remote handle with a jog wheel, some push buttons, rotary switches and LEDs).
Response time is critical in this application, so SPIN was no option for me (it isn't an option for me anyhow).
Extending the Prop with external RAM for code is -in my eyes- useless. It's a crutch. It works, but is not well integrated. It simply is beyond the capabilities of the Prop. Yes, some got this working. But that doesn't mean it's an elegant solution.
Nick
Which compiler did you use? I'm assuming you used ICC based on your earlier posts. I kind of agree that a compiler is less likely to be adopted if it puts constraints on the platforms it runs on. Requiring lots of external RAM probably eliminates a large part of the target audience. That's one reason I've been playing with GCC/ZOG. Even though I'm currently using 64k of external SPI SRAM, I have been able to write programs that run entirely in hub RAM. I guess internal memory space will improve with Propeller 2.
I guess internal memory space will improve with Propeller 2.
a) when will Prop II happen?
b) after a), how long will it take for the RAM to be insufficient again?
@Ross:
Puliiiiize! I want binary constants. '0b0010' for example. The compiler says: "Is a preprocessing constant (so does recognize it?) but invalid integer constant".
They are very handy when programming µC, albeit not part of the standard (C99, C89).
Comments
When Prop II is released, we will revisit the decision.
And I dispute greatly that a GCC port will help in any way. ZOG is all you need to move in their direction. So is ZOG a success for commercial development? If so, then yes, GCC is what people want.
A Prop 1.5 with 64 IO pins will greatly help in creating a usable fast expanded SRAM solution. However, that is unlikely to come from Parallax. So we will wait for Prop II, hopefully no like Godot :-)
// richard
No! It`s because of the LMM.
May I put this in contrast to quotes from ImageCrafts home page?
"You are not buying a compiler, you are buying unparalleled support."
"Richard is maniacal in support." -- Jack P.
"Support from Imagecraft is second to none." -- Andrew
Until now, not even the included help files match those on the ICC web-site.
After more than a year.
And:
"optimizations"
I do not think a compiler site does optimizations when he links an unreferenced library (float) and emits useless opcodes. The linker only links complete compilation units, even unused functions.
Richard, if you don't fix those things (you got my list), "Prop I C compilers are not entirely commercially viable". No wonder.
Nick
@dnalor, can you explain what you mean?
Richard,
I still maintain that:
1) We love the Prop and it's "out of the box" architecture.
2) Us hard core C heads love to have C on the Prop.
3) C is not actually practically useful on the Prop.
The thing that frustrates us is that 3) is due to 1).
C on the Prop is like a dog doing tricks, as they say, the wonder is not that it does it well but that it does it at all.
C on the Prop lacks the native speed that C users are used to whilst at the same time being rather wasteful of space. It's rather a hard sell when up against Spin and PASM.
The lack of a Prop I with 64 IO's and hence easy program space expansion is heartbreaking but I suspect it's time has well and truly passed.
We look forward to Catalina and ICC on the Prop II where C can breath more easily.
But watch out, Zog will be there watching you:)
Nick, when you throw in real development budget and not get a reasonable return, then we can talk. We can do all those but it's throwing more money at a problem not by us.
And if anyone thinks LMM is the problem, they can feel free to hack small C or LCC to target COG.
C can shine on Prop 1.5 or Prop II. Until then.
Notice no one is making real money on software tools for the Prop, as far as I know. I might very well be wrong of course. Give me proof please.
We knew the risks coming in. We got burned. Not a problem. We win some, we lose some. Live and learn.
Anyone else who think they can solve the C for Prop problem for a commercially viable product, feel free. Go for it!
Jazzed, you do have a perfect crystal ball!
It worx.
Nick
Then you simply should stop selling ICC Prop. 272.51 waisted.
Also very simple: Lesson learned, no ImageCraft products.
Nick
I don't think so, but I do like C.
ICC-code runs quite fast, compared to Spin. But of course, slower than ASM. If your code has a good balance between C and ASM you do have all advantages of both worlds. Extremely fast code in ASM that does some sub-tasks that are time-critical, yet small enough to be coded in ASM and on the other hand better abstraction with C.
C on the Prop is a failure like any other language. :smilewinkgrin:
Nick
I will refund your money. Email me.
No thanks. I bought it, that's it. Lesson already learned.
Nick
Hi Nick,
No worries about the question. It's exactly things like this that I need to find out. In this case (as jazzed already pointed out) it's because you don't have .NET installed. You need to install the Microsoft .NET Framework Version 2.0 Redistributable Package (x86) (here). Note that you need 2.0 even if you have a later version installed.
It never occured to me that someone might not have this installed under Windows. I'll add a note to the Catalina documentation.
Ross.
-Phil
Well, not a failure, just not always the best choice I suppose. You have to match the language with the problem I guess. Spin and PASM will certainly be the best languages for the Propeller and probably also the Propeller II. It's just that sometimes you want to port something that was written in a more traditional language like C and then it helps to have that option available as well.
Hi David,
As you might guess, I disagree with this view :smilewinkgrin: (and also with Heater's comment that "C is not actually practically useful on the Prop").
I think C is quite functional on the Prop I for what the Prop was originally intended for - i.e. small embedded applications that need a very flexible microcontroller. The problem is that many of us (including me!) are trying to run operating systems and other large applications that are more suited to a microprocessor. And when the results are mediocre (compared to what is possible on other microprocessors) we tend to blame either the tools or the architecture of the Propeller - very few of us will acknowledge that we were probably being a bit dumb to attempt such things in the first place (including me, naturally!).
This is the point I was trying to make earlier about a GNU port to the Propeller - the first thing some of us would try to do is download the Linux sources and attempt to compile the Linux Kernel - and when this turns out to be impractical we will either blame the quality of the port or (worse!) blame the Propeller itself. The Propeller is not a general purpose microprocessor, and it is not a transputer. If what you really needed was one of those, then the Propeller is always going to be a second-best solution.
If you wonder why Parallax has not rushed off to do a GNU port then it may be because they knew this already, and also that they would be on a hiding to nothing.
I maintain that C is fine on the Prop I if used where it is appropriate to do so - and also that it will be even better on the Prop II!
Of course, I realize I am usually in a minority of one here - I'm used to that
Ross.
Hi Phil,
I can certainly understand this! Unfortunately, there's not much I can do about it right now. I have plans to also support bst as an alternative assembler to Homespun, but it's a matter of finding the time.
Ross.
I think a C compiler will be a lot more important for Prop2.
I can assure you that we learned our lessons much more with the money we spent on developing and support the Prop. If we have only lost $249.00....
2) Propeller is only serious for small things regardless of what we do (right-sizing).
3) There are lots of alternatives that already do industry standard GNU (staying in the niche).
4) Basic stamp customers don't want to learn C (repeat customers)
5) Chip and others would have less creative outlet (happy staff).
6) Ross and Richard would have less opportunities to compete (vendor relationships).
I haven't tried ICC but I have used Catalina and have been playing with GCC/ZOG and I've had a lot of fun with both. I have successfully built and run a simple Basic bytecode compiler under ZOG (had to split it into three phases to get it to fit in 64k of SPI SRAM). I'd love to try it under Catalina as well but I have to setup a system with a big external RAM before I'll be able to do that.
What projects have others done?
With the Prop, that usually means Spin+PASM, however I did play a bit with both Catalina and Gcc for Zog - and like both.
Right now, I am concentrating on hardware and consulting, so I have put PropellerBasic on hold - and frankly, I don't think there is a market for a commercial optimizing LMM Basic compiler yet.
As soon as I am done with the boards I showed at UPEW, I will resume work on a large VMCOG - which will support a mix of SPI ram/flash for a really big VM.
... and suddenly was heard the sound of one hand clapping ...
This thread like many others on C can be entertaining, but they usually don't achieve anything good. So now my first comments on this thread can be taken in full perspective
What new things have we learned?
1) Catalina has made some progress with making more memory available.
2) ImageCraft states that ICC for Propeller is not a viable product.
3) Not everyone likes .net
4) Apparently there are very few people writing Propeller applications in C.
5. Lots of people want to use C on the Propeller (I and II)
6. Catalina will continue to innovate on the Prop I
6. Catalina will be the logical choice of language for the Prop II
I have implemented a Modbus-client. This Modbus-interface does most of the digital IO for my MAHO 700C mill. 3.1 tons, not a toy! The original control was broken, so I replaced it with EMC2. Right now, I designed a different Modbus-interface (more compact, with LCD) that will go into the hand wheel (= remote handle with a jog wheel, some push buttons, rotary switches and LEDs).
Response time is critical in this application, so SPIN was no option for me (it isn't an option for me anyhow).
Extending the Prop with external RAM for code is -in my eyes- useless. It's a crutch. It works, but is not well integrated. It simply is beyond the capabilities of the Prop. Yes, some got this working. But that doesn't mean it's an elegant solution.
Nick
a) when will Prop II happen?
b) after a), how long will it take for the RAM to be insufficient again?
@Ross:
Puliiiiize! I want binary constants. '0b0010' for example. The compiler says: "Is a preprocessing constant (so does recognize it?) but invalid integer constant".
They are very handy when programming µC, albeit not part of the standard (C99, C89).
Nick