This is not about C verses Spin or ASM. Propeller is different. The Parallax leadership thinks differently.
ImageCraft is offering commercial developers an opportunity to use C, an industrial standard development platform.
Parallax is the big winner ATM, it will be interesting to see if the two organizations can get together and sort something out that will be benefit everybody including the non commercial programmer.
Unfortunately price is an issue for many. For those who can, learning C is worth the effort.
The more objects in the Object Exchange and the more support from Third Parties the better. It doesn't matter if it's a new demo or a compiler, the more stuff out there the better it is for all.
That said, I'm not opposed to learning a new language to get the job done. I prefer to program in C when possible, but I'm an asm programmer at heart, and Spin is just so much quicker. Look at all of the new "faces" in the forum and the way the object exchange has really grown. This is great for people new to the prop, and people that have been tinkering for a bit (like me). It's quite easy to grab a handful of objects and put together some really nifty stuff - for example, my tank robot project is using objects for: oled128, fullserial, clock, compass, sd, ping, PIR, IR, and more. I can spend time building instead of coding, and being Spin/PASM based isn't an issue at this point.
Will I purchase a C compiler, probably not. However, since I don't know what project I'll get into next it might be just what I need in the future.
@ bambino : That's a good point about end users needing the time to understand and experiment with new ideas like LMM let alone embrace them and use them efficiently. Anyone up against a deadline will chose whatever they have experience with and understand already - the best argument for why C is useful, even necessary, to have for those familiar with it.
There's also no well documented reference designs, whitepapers, tutorials and guides so one really has to want to do LMM to get into it rather than it being an option among others. On top of that there are numerous LMM variants.
Even I have to admit that coding LMM is tortuous at best because the PropTool doesn't have macros or #defines and other abilities which would make it easy ( try using a label of a 16-bit word which isn't long aligned in a DAT section ), and people naturally want to use the PropTool, especially when working with Spin, PASM and LMM.
Now Propellent has arrived it should be easier to write tools which can accept Spin, PASM and LMM together and that will certainly help.
I suppose LMM will take off when people don't have to really think about it, where instead of writing their code in a DAT section, they put it in an LMM section just as they would normal PASM and the compiler simply sorts everything out for them.
I suppose LMM will take off when people don't have to really think about it, where instead of writing their code in a DAT section, they put it in an LMM section just as they would normal PASM and the compiler simply sorts everything out for them.
You mean, like in ImageCraft C The LMM is totally transparent to the C programmers...
StefanL38 said...
So all you superprofessional C-programmers: i call you by your honor: how long does it take for YOU to learn SPIN ?
Not very long at all, in 2 days I had the core of the Logic Analyzer coded. There were subsequent optimizations, but I had the basic core working only two days after receiving the Demo Board Rev A in my hands, and this was before there was a datasheet or manual. All we had to go off of was PropellerGuts.pdf and some other internal doc outlining the commands (barest detail, no example code). For those of you who don't know my history with Parallax, this was when I was a customer.
The C vs. Spin debate is 6 one way half a dozen the other. I personally have no love for C, I understand it well and did professional coding while in college, but I see it as a means to an end, not something to marry yourself to with an intransigent additude. I am definitely of the "best tool for the job" school, which is proabably why I can read about a dozen languages and can program in half a dozen. When it comes to the Propeller, since Spin was developed in tandem with the hardware I see Spin as the best tool for the job (plus it is much more elegant, "easier to read", than C).
But this isn't the case when it comes to the industry. Team managers want to have unified language for development which ussually means the LCD (lowest common denominator) is typically chosen (ie C). So we fully support Richard's efforts to bring a C compiler for the Propeller to market. Since this is a 3rd party tool, he is at liberty to choose the packages and pricing.
Last note, we have no plans to come out with our own gcc or other type of c compiler. Beyond the major point of not having the resources to dedicate, it would be very rude for us to come out with a free compiler which would undercut all the effort Richard put into his product.
Any software engineering professional with a good working knowledge of a few languages taught in most post-secondary schools should be able to have a good %90 working knowledge of spin in less than a week; it's the last %10 that takes time depending on motivation and digging via ready access to Q&A or searching the Propeller Forum. Getting outside the box is valuable, and being polyglot helps greatly. Of course the opposite is true: being software fascist helps very little unless that is the expectation of your customer or employer.
Large companies able to make smaller companies/owners wealthy by embracing their products tend to have mainstream industry expectations. Paul explained these expectations nicely. Managers care mostly about achieving goals that are in line with director and VP expectations, and that tends to require a set of standards especially when the company has a market cap of > $10 Billion and aging products with some exceptions. Most management misses opportunities because of large corporate culture and often paint themselves into a corner unwittingly.
I applaud Parallax's great attitude of enabling new products from 3rd party "partners". As far as being able to serve as many customers as possible given their size, they are fairly well positioned and have a good track record with this generous "free market" approach. The only way for them to do better financially would be to go public, but that does not seem likely, and it would probably spoil the "partner" business model among other things.
I have to agree with jazzed. In almost no time at all, I could do most of Spin. There are, however, a few things that I don't readily remember because I haven't been coding in it for years. However, given the choice (and it looks like I'll soon have it [noparse]:)[/noparse] I'd be coding for the Prop in C.
There are 3 things missing from Spin that I find invaluable in several other languages, including C:
1) Structures, particularly structures with bitfields. Take, for instance, the various LCD drivers. It would be really nice to have a coordinate structure that you could pass from place to place. Instead, you have to pass x and y as two seperate variables. Also, I'd love to be able to create bitfields to describe parameters being passed to, say, the Dallas RTC. Instead, I'm manually masking and shifting.
2) A preprocessor. This is mostly from C. Being able to put common code sequences in without retyping them everywhere is great. It would be really nice to be able to turn my debug code on and off, and when I turn it off, have it go away completely. Instead, I ususally end up having to comment it in and out as I go. Now, I'd just add a stage to run through CPP (the C PreProcessor, not C++), but you can't really do that from inside the IDE.
3) The ability to pass objects around. This is a really nice thing about object oriented programming that I can't get with C. Problem is, I can't get it with Spin either. Even worse, I can't even simulate it using function pointers (ugly as they are, they at least *exist* in C). I've been thinking about writing a file I/O layer that has a filesystem layer and a block I/O layer. That will be a major PITA (and go much slower than it needs to) due to the lack of object pointers.
There are a number of other annoyances I have with Spin, but those are more because it's just not what I'm used to or because I have an extremely strong preference for a non-Windows (MacOS X or Linux) development environment. These three above, however, are limitations I can't seem to work around and seem like structural deficiencies in the language itself (especially #1 and #3). One of the ways I would work around the lack of structures, BTW, is with a preprocessor...
I'm not sure if Parallax is considering a "Spin 2.0", but if you are, consider those my top 3 suggestions for it.
One other item is that it's not documented anywhere that I've been able to find (maybe I'm just missing it) what optimizations the Spin compiler is capable of.
For instance, I feel very comfortable that if I write this:
if (0) printf("Some debug output\n");
in C, the code for that if() will not be in the final output. I have no idea if Spin will do the same thing. I assume it does constant math, though, again, I'm not 100% sure...
Besides being a professional software engineer (desktop and mainframe applications), I teach rocket engineering for high school students and had a chance to use the Propeller chip as a CPU for and on-board flight/payload computer inside a sounding rocket. It was a fairly involved project, the payload collected atmospheric data (pressure, humidity, temperature), location data (GPS) and pollen samples in a multi-chamber Rotorod-like collector. All eight cogs were utilized, each either tending to one of the sensors or driving mechanical collector components or reducing/saving data (EEPROM). All of the code was written in SPIN and we did not hit any major roadblocks (but the sampling frequency was only 100Hz). Some lessons regarding the SPIN language learned from this real project:
1) The division of code into objects is a really powerful feature. Having code for each component encapsulated in an object allows for easy parallelization and also for easy component testing and re-configuration of the whole system. I don't think this would be easily possible with C (even with structures). SPIN encourages good code organization and modularization and that's a big plus.
2) The absence of a preprocessor is quite a bother even though the workarounds are possible (but not very elegant). I do not care that much about macros, but conditional compilation and file inclusion would be very welcomed features.
3) The absence of a debugger causes a lot of slowdowns in application/system development. If I'd had to decide between having a debugger or C-language, I'd go for a debugger without any hesitation.
4) SPIN syntax for floating point operations leads to low code readability. It's not a minor problem for what I do, as there's a lot of floating point calculations involved in rocket flight control and since there's no debugger either, it may take a lot of print statements to figure out where's the problem. We also do real-time flight trajectory predictions, which involves numerical integration and 32-bit floats are quite often just barely enough to keep the cumulative rounding errors under control.
Forest Godfrey said...
One other item is that it's not documented anywhere that I've been able to find (maybe I'm just missing it) what optimizations the Spin compiler is capable of.
There's no optimisation done I can see; "x := 0+0+0+0+0+0" does five additions, "if (0) ..." includes the then clause code. Put any number of 'return' statements at the end of a method, and they'll all generate code, then you get one which gets inserted anyway. Uncalled methods and other 'dead code' will generate code.
The only place there is code size reduction is when the same object is included multiple times; the code is only included for that object once.
1) Structures, particularly structures with bitfields.
Not a particular concern for me, but I appreciate their usefulness.
2) A preprocessor.
Desperately needed, especially conditional compilation and #define.
Comparing notes here ... following the 1) struct, 2) preprocessor, 3) objects outline with some other categories.
1) I use C data structures as "framers" with data packets for performance especially if bit fields are available and required.
(I tried using bitfields with ImageCraft C early on and found they were not supported ... maybe this has changed).
Using data structures are also a very convenient way of passing context from one function to another (which most likely impacts performance), but is necessary mostly because an encapsulating object definition is not available in C. I'm a fan of using arrays of data structures for static lists, etc... and miss that in spin.
In spin, "data structures" are defined with variables. Unfortunately there is no public qualifier that could make objects play the same role as C data structures as in java, javascript, C++ or php.
2) Preprocessors are nice for many things and would be useful for simple customizations like conditionally including test code, but using #ifdef for choosing one or more many features is horrible [noparse]:)[/noparse] just look at the linux kernel - yuck. This problem is solved by OOP.
Some of the nice preprocessor things that can be done like #include can be done with spin using FILE. The #define macro constants are replaced with the CON section; CON symbols are also public. Spin also has a form of enumeration in CON.
3) I like spin objects much better than C modules written with data structures mainly because of organization. C data structures can be coerced into being OOP-like objects with function pointers similar to javascript classes, but that is a great way to obscure code [noparse]:)[/noparse]
Spin objects provide encapsulation and scope localization. Unfortunately polymorphism is not available, and object instances are not passable by reference, but global DAT variables can at least be shared. Of course you can't redefine an object pointer in run time depending on some data driven configuration.
Other items of interest ....
4) GNU C error and warnings reporting and controls are informative and flexible. ImageCraft's
errors and warnings are also helpful. Some C warnings are of little value, but they can be suppressed.
Spin does not generate warnings.
5) Spin's operator set is rich, but I can't stand ":=" ... to me it means "is defined as" and is more appropriate for CON defines rather than a variable assignment operator, but complaining about that is just being petty.
6) Some AOS rules are a little different between spin and C especially with respect to shift, so watch out.
7) Spin "repeat while" and variants are lisp like. I much prefer for, while, do ... while, etc....
8) I prefer bracy languages over indents mainly because the beginnings and ends are easy to find with any editor or sed script for example. The spin editor indent marker is helpful, but can be mis-leading.
9) I really appreciate spin's abort exception feature. C's only possible equivalents are setjmp, longjmp, and goto. Of course try-catch and throw in other languages are superior to both.
jazzed said...
2) Preprocessors are nice for many things and would be useful for simple customizations like conditionally including test code, but using #ifdef for choosing one or more many features is horrible [noparse]:)[/noparse] just look at the linux kernel - yuck. This problem is solved by OOP.
For Spin programming you are right ( although few like the object image bloat and added execution time of unnecessary and unused code ) but for PASM coding, where Cog memory is a precious resource, not having conditional compilation and #defines can make a project very difficult to work with.
It may be my obsession with LMM's and VM's which regularly makes this more painfully obvious to me than to others but I am sure I'm not alone in wishing there were pre-processor support.
There are ways round not having pre-processing but it makes the development processes far harder, more error prone, and in truth does hold back progress and delivery of solutions. In my case both for delivering LMM kernels and for any user who wants to use LMM.
I'd go as far as saying lack of pre-processor support has undermined some Propeller developments there could have been and that end-users are consequently not getting all they could have had. There are alternative toolchains, but for mainstream adoption of 'some clever stuff' people want to be working in the PropTool. ImageCraft C succeeds because they were able to create a credible toolchain and development suite. Most of us don't have the resources to do that, do not necessarily want to, and it seems silly to me having to do that when it's such a small but significant lack of a facility which makes that necessary.
I'm certainly not against having a preprocessor [noparse]:)[/noparse] I've just had to deal with abuses that could have been avoided given the situations and expectations that products <added> with #ifdef in many files over years with continuous new feature additions </added> should be easily expanded. Such situations were not memory constrained.
Comments
ImageCraft is offering commercial developers an opportunity to use C, an industrial standard development platform.
Parallax is the big winner ATM, it will be interesting to see if the two organizations can get together and sort something out that will be benefit everybody including the non commercial programmer.
Unfortunately price is an issue for many. For those who can, learning C is worth the effort.
Ron
That said, I'm not opposed to learning a new language to get the job done. I prefer to program in C when possible, but I'm an asm programmer at heart, and Spin is just so much quicker. Look at all of the new "faces" in the forum and the way the object exchange has really grown. This is great for people new to the prop, and people that have been tinkering for a bit (like me). It's quite easy to grab a handful of objects and put together some really nifty stuff - for example, my tank robot project is using objects for: oled128, fullserial, clock, compass, sd, ping, PIR, IR, and more. I can spend time building instead of coding, and being Spin/PASM based isn't an issue at this point.
Will I purchase a C compiler, probably not. However, since I don't know what project I'll get into next it might be just what I need in the future.
Tom.
There's also no well documented reference designs, whitepapers, tutorials and guides so one really has to want to do LMM to get into it rather than it being an option among others. On top of that there are numerous LMM variants.
Even I have to admit that coding LMM is tortuous at best because the PropTool doesn't have macros or #defines and other abilities which would make it easy ( try using a label of a 16-bit word which isn't long aligned in a DAT section ), and people naturally want to use the PropTool, especially when working with Spin, PASM and LMM.
Now Propellent has arrived it should be easier to write tools which can accept Spin, PASM and LMM together and that will certainly help.
I suppose LMM will take off when people don't have to really think about it, where instead of writing their code in a DAT section, they put it in an LMM section just as they would normal PASM and the compiler simply sorts everything out for them.
You mean, like in ImageCraft C
The C vs. Spin debate is 6 one way half a dozen the other. I personally have no love for C, I understand it well and did professional coding while in college, but I see it as a means to an end, not something to marry yourself to with an intransigent additude. I am definitely of the "best tool for the job" school, which is proabably why I can read about a dozen languages and can program in half a dozen. When it comes to the Propeller, since Spin was developed in tandem with the hardware I see Spin as the best tool for the job (plus it is much more elegant, "easier to read", than C).
But this isn't the case when it comes to the industry. Team managers want to have unified language for development which ussually means the LCD (lowest common denominator) is typically chosen (ie C). So we fully support Richard's efforts to bring a C compiler for the Propeller to market. Since this is a 3rd party tool, he is at liberty to choose the packages and pricing.
Last note, we have no plans to come out with our own gcc or other type of c compiler. Beyond the major point of not having the resources to dedicate, it would be very rude for us to come out with a free compiler which would undercut all the effort Richard put into his product.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
Large companies able to make smaller companies/owners wealthy by embracing their products tend to have mainstream industry expectations. Paul explained these expectations nicely. Managers care mostly about achieving goals that are in line with director and VP expectations, and that tends to require a set of standards especially when the company has a market cap of > $10 Billion and aging products with some exceptions. Most management misses opportunities because of large corporate culture and often paint themselves into a corner unwittingly.
I applaud Parallax's great attitude of enabling new products from 3rd party "partners". As far as being able to serve as many customers as possible given their size, they are fairly well positioned and have a good track record with this generous "free market" approach. The only way for them to do better financially would be to go public, but that does not seem likely, and it would probably spoil the "partner" business model among other things.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 6/16/2008 8:37:45 PM GMT
There are 3 things missing from Spin that I find invaluable in several other languages, including C:
1) Structures, particularly structures with bitfields. Take, for instance, the various LCD drivers. It would be really nice to have a coordinate structure that you could pass from place to place. Instead, you have to pass x and y as two seperate variables. Also, I'd love to be able to create bitfields to describe parameters being passed to, say, the Dallas RTC. Instead, I'm manually masking and shifting.
2) A preprocessor. This is mostly from C. Being able to put common code sequences in without retyping them everywhere is great. It would be really nice to be able to turn my debug code on and off, and when I turn it off, have it go away completely. Instead, I ususally end up having to comment it in and out as I go. Now, I'd just add a stage to run through CPP (the C PreProcessor, not C++), but you can't really do that from inside the IDE.
3) The ability to pass objects around. This is a really nice thing about object oriented programming that I can't get with C. Problem is, I can't get it with Spin either. Even worse, I can't even simulate it using function pointers (ugly as they are, they at least *exist* in C). I've been thinking about writing a file I/O layer that has a filesystem layer and a block I/O layer. That will be a major PITA (and go much slower than it needs to) due to the lack of object pointers.
There are a number of other annoyances I have with Spin, but those are more because it's just not what I'm used to or because I have an extremely strong preference for a non-Windows (MacOS X or Linux) development environment. These three above, however, are limitations I can't seem to work around and seem like structural deficiencies in the language itself (especially #1 and #3). One of the ways I would work around the lack of structures, BTW, is with a preprocessor...
I'm not sure if Parallax is considering a "Spin 2.0", but if you are, consider those my top 3 suggestions for it.
One other item is that it's not documented anywhere that I've been able to find (maybe I'm just missing it) what optimizations the Spin compiler is capable of.
For instance, I feel very comfortable that if I write this:
if (0) printf("Some debug output\n");
in C, the code for that if() will not be in the final output. I have no idea if Spin will do the same thing. I assume it does constant math, though, again, I'm not 100% sure...
1) The division of code into objects is a really powerful feature. Having code for each component encapsulated in an object allows for easy parallelization and also for easy component testing and re-configuration of the whole system. I don't think this would be easily possible with C (even with structures). SPIN encourages good code organization and modularization and that's a big plus.
2) The absence of a preprocessor is quite a bother even though the workarounds are possible (but not very elegant). I do not care that much about macros, but conditional compilation and file inclusion would be very welcomed features.
3) The absence of a debugger causes a lot of slowdowns in application/system development. If I'd had to decide between having a debugger or C-language, I'd go for a debugger without any hesitation.
4) SPIN syntax for floating point operations leads to low code readability. It's not a minor problem for what I do, as there's a lot of floating point calculations involved in rocket flight control and since there's no debugger either, it may take a lot of print statements to figure out where's the problem. We also do real-time flight trajectory predictions, which involves numerical integration and 32-bit floats are quite often just barely enough to keep the cumulative rounding errors under control.
Post Edited (Pavel) : 6/17/2008 12:47:17 AM GMT
There's no optimisation done I can see; "x := 0+0+0+0+0+0" does five additions, "if (0) ..." includes the then clause code. Put any number of 'return' statements at the end of a method, and they'll all generate code, then you get one which gets inserted anyway. Uncalled methods and other 'dead code' will generate code.
The only place there is code size reduction is when the same object is included multiple times; the code is only included for that object once.
1) Structures, particularly structures with bitfields.
Not a particular concern for me, but I appreciate their usefulness.
2) A preprocessor.
Desperately needed, especially conditional compilation and #define.
3) The ability to pass objects around.
Would certainly make a lot of things easier.
1) I use C data structures as "framers" with data packets for performance especially if bit fields are available and required.
(I tried using bitfields with ImageCraft C early on and found they were not supported ... maybe this has changed).
Using data structures are also a very convenient way of passing context from one function to another (which most likely impacts performance), but is necessary mostly because an encapsulating object definition is not available in C. I'm a fan of using arrays of data structures for static lists, etc... and miss that in spin.
In spin, "data structures" are defined with variables. Unfortunately there is no public qualifier that could make objects play the same role as C data structures as in java, javascript, C++ or php.
2) Preprocessors are nice for many things and would be useful for simple customizations like conditionally including test code, but using #ifdef for choosing one or more many features is horrible [noparse]:)[/noparse] just look at the linux kernel - yuck. This problem is solved by OOP.
Some of the nice preprocessor things that can be done like #include can be done with spin using FILE. The #define macro constants are replaced with the CON section; CON symbols are also public. Spin also has a form of enumeration in CON.
3) I like spin objects much better than C modules written with data structures mainly because of organization. C data structures can be coerced into being OOP-like objects with function pointers similar to javascript classes, but that is a great way to obscure code [noparse]:)[/noparse]
Spin objects provide encapsulation and scope localization. Unfortunately polymorphism is not available, and object instances are not passable by reference, but global DAT variables can at least be shared. Of course you can't redefine an object pointer in run time depending on some data driven configuration.
Other items of interest ....
4) GNU C error and warnings reporting and controls are informative and flexible. ImageCraft's
errors and warnings are also helpful. Some C warnings are of little value, but they can be suppressed.
Spin does not generate warnings.
5) Spin's operator set is rich, but I can't stand ":=" ... to me it means "is defined as" and is more appropriate for CON defines rather than a variable assignment operator, but complaining about that is just being petty.
6) Some AOS rules are a little different between spin and C especially with respect to shift, so watch out.
7) Spin "repeat while" and variants are lisp like. I much prefer for, while, do ... while, etc....
8) I prefer bracy languages over indents mainly because the beginnings and ends are easy to find with any editor or sed script for example. The spin editor indent marker is helpful, but can be mis-leading.
9) I really appreciate spin's abort exception feature. C's only possible equivalents are setjmp, longjmp, and goto. Of course try-catch and throw in other languages are superior to both.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For Spin programming you are right ( although few like the object image bloat and added execution time of unnecessary and unused code ) but for PASM coding, where Cog memory is a precious resource, not having conditional compilation and #defines can make a project very difficult to work with.
It may be my obsession with LMM's and VM's which regularly makes this more painfully obvious to me than to others but I am sure I'm not alone in wishing there were pre-processor support.
There are ways round not having pre-processing but it makes the development processes far harder, more error prone, and in truth does hold back progress and delivery of solutions. In my case both for delivering LMM kernels and for any user who wants to use LMM.
I'd go as far as saying lack of pre-processor support has undermined some Propeller developments there could have been and that end-users are consequently not getting all they could have had. There are alternative toolchains, but for mainstream adoption of 'some clever stuff' people want to be working in the PropTool. ImageCraft C succeeds because they were able to create a credible toolchain and development suite. Most of us don't have the resources to do that, do not necessarily want to, and it seems silly to me having to do that when it's such a small but significant lack of a facility which makes that necessary.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Post Edited (jazzed) : 6/17/2008 4:00:03 PM GMT