dnalor said...
I am a professional c-programmer.
I tried it with spin, but my spin-lines very often ends with a ';' --> error. My comments starts with // --> also wrong. "Greater than or equal" is >= --> another error...........
Maybe I am simply too stupid, but if you code all the time in C then many things come automatically (without thinking).
These problems PMC would solve and porting c-code would be much easier.
This are my feelings too, even though I'm maybe not a "professional" C programmer.
Actually, you don't really have to call it C anyway.· Just say it has a C-like syntax.
I think if the Parallax programmers weren't Pascal programmers then·SPIN would already have a C-like syntax instead of a Pascal-like syntax and life would be better.
I have to deal with Fortran code sometimes, which is even worse than Pascal, so things could be worse, I suppose...
A Parallax version of Dave Hein's CSPIN is about what we need, I think...
How about fixing the problem at the root rather than bolting a half baked solution on top of spin?
I'm proposing a Propeller with a different ROM content. A VM for C instead of Spin.
Looks like we can do a ZPU virtual machine in one COG [noparse][[/noparse]see note] that can execute pukka C code compiled with GCC at about the same rate as Spin.
With that comes some bonuses like being able to use C++ and FORTRAN even Java etc as supported by GCC.
Anyone wanting to use C on the Prop is not much going to want Spin hanging around anyway.
Note: Requires a dispatch table in HUB but that could be in ROM also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
The thing I like about Spin vs. C is that it facilitates rapid prototyping, without a lot of crufty declarations and squiggly syntactic silliness (i.e. braces and semicolons). Which is easier to read, write, and understand, after all: repeat i from 1 to 5 or for (i = 1; i <= 5; i++) { ? This can be a huge selling point for commercial developers, for whom time is money, and a quick time-to-market can make the difference between success and failure. Rather than bowing to C, it might be better for Parallax to exploit and promote the distinct commercial advantages of Spin.
I still don't understand why there's a need for another implementation of C on the Propeller - we already have two that run direct on the "iron" (ICC and Catalina).
This would be a lot easier if the Propeller tool supported #include/#define/#ifdef etc., and if Spin had struct/union/typedef and multi-dimensional arrays of all data types.
Phil Pilgrim (PhiPi) said...
The thing I like about Spin vs. C is that it facilitates rapid prototyping, without a lot of crufty declarations and squiggly syntactic silliness (i.e. braces and semicolons). Which is easier to read, write, and understand, after all: repeat i from 1 to 5 or for (i = 1; i <= 5; i++) { ? This can be a huge selling point for commercial developers, for whom time is money, and a quick time-to-market can make the difference between success and failure. Rather than bowing to C, it might be better for Parallax to exploit and promote the distinct commercial advantages of Spin.
Phil Pilgrim (PhiPi) said...
The thing I like about Spin vs. C is that it facilitates rapid prototyping, without a lot of crufty declarations and squiggly syntactic silliness (i.e. braces and semicolons). Which is easier to read, write, and understand, after all: repeat i from 1 to 5 or for (i = 1; i <= 5; i++) { ? This can be a huge selling point for commercial developers, for whom time is money, and a quick time-to-market can make the difference between success and failure. Rather than bowing to C, it might be better for Parallax to exploit and promote the distinct commercial advantages of Spin.
-Phil
If that is the sole determinant for "easier to read, write, and understand," you would see Modula 2 and Pascal programmers being in high demand.
Think about this, in 2010, 20% of programmers still use C professionally. This is despite C++, Java, PHP, Python, Perl, FORTRAN, Ada, COBOL, BASIC, etc, etc.
Non-Standard C no longer has a place in the industry. Rabbit Semiconductor tried that tack 10 years ago with Dynamic C and that is always one of its Achilles Heels. It is seldom seen as an advantage.
simonl said...
I still don't understand why there's a need for another implementation of C on the Propeller - we already have two that run direct on the "iron" (ICC and Catalina).
Well, I am very impressed by ICC and Catalina, even though I still haven't dived into them despite meaning to for a very long time...
But, I think the main advantage of this thing is that it used the ROM Spin interpreter (if I'm understanding it right).
So, just like CSPIN, you program in something like C and that get translated into SPIN byte codes.
This has the advantage of being able to make the most efficient use of RAM, even though it's probably slower and more limited that ICC or Catalina.
Being able to use the SPIN and assembly drivers AS IS, is a huge benefit too...
Mentioning Modula 2 in this context is a bit off-base. I've programmed in Modula 2 for commercial apps. It hardly meets the same standard for "rapid prototyping" that Spin does. You spend half your programming effort just defining stuff, then defining it again. (Every module requires two files: one for the "definition" and one for the program.)
I have had my hands on a Propeller chip even before the Parallax announced the chip because of the Hydra project, and I applaud Parallax for this decision. SPIN is a relatively simple language and the SPIN byte code interpreter runs code pretty quick. But since then I have worked on other projects using other micros which have native C and ASM support built into the tools. Since then it has been hard (for me) to come back to the Propeller chip because of the SPIN language. Now I don't think there is anything wrong with SPIN, but after being able to program with C on other micros it is hard to go back to a specialized language that I have to refresh my memory with. Now with that said I still love the Propeller, and for someone like me who uses it to make video games, it is a very capable micro. There are other C options like Image Craft C and Catalina C (the later of which I would like to check out if I get some time), but a built in version of C that in the Propeller tools will be awesome!
The process I have for making games on a micro is create a similar environment on the PC using SDL to mimic the functions of the audio and video drivers that run on the micro. This way I can program 95% of a game on the PC, then switch a few lines of code to have it compile on the micro. Even if the Propeller C is not 100% compliant, I believe I could make a similar setup, but with SPIN I cannot do this.
I also think Parallax is very smart for introducing this application this side of the Propeller life cycle because they test it and perfect it on the first Propeller micro and by the time the Propeller 2 was ready to ship, the application would be stable and ready to go. I also think that this will open the door for people who don't want to learn SPIN to take advantage of this chip, or for people like me who has to program on multiple platforms and doesn't use SPIN full time.
Rayman said...
...But, I think the main advantage of this thing is that it used the ROM Spin interpreter (if I'm understanding it right).
So, just like CSPIN, you program in something like C and that get translated into SPIN byte codes.
This has the advantage of being able to make the most efficient use of RAM, even though it's probably slower and more limited that ICC or Catalina.
Ah, right, I get it now. But why do we need another CSPIN then!?
Rayman said...
Being able to use the SPIN and assembly drivers AS IS, is a huge benefit too...
I'll second that I've been giving PropBASIC a workout recently, and not having direct* access to Spin objects is a major pain! I believe that's also the case with ICC and Catalina too?
* I know Terry's demonstrated a dispatcher "thingy", but I've not got my head around that yet.
When I first read this thread I thought PMC sounded like a good idea.
I thought that finally Parallax was going to support C on the prop in a big way.
But I changed my mind along the way. As I said before, I say again, why not
just use, support and improve Catalina. There is no reason to create something
internally, don't reinvent the wheel... using Catalina is the easy way to go, and the fast way.
Atmel has no problem mentioning in their ads that free WinAVR is available. They put
support right into their IDE.
Align Parallax support behind both Catalina and PropBasic and create good beginners manuals
for using both. Build support into your own IDE for both of them. And start advertising that
the Propeller comes with both C and Basic ready to go for free!
Sorry to say all this the second time in this thread but I just feel this is the right thing to
do!
There is nothing wrong with supporting a gpl C for the Propeller. Nothing says you can't pay
some great C coders to jump in and improve it. Gpl doesn't mean all the work on the project must be gratis.
There are probably several people right here on the forum that would start work immediately if
you gave the word. Anyway, since Catalina is aimed only at the propeller no competitor could make
any use of it at all, so why care if it is open source. Spend some $ to perfect it.
I would not make it a closed source proprietary Catalina owned by Parallax. Having the company supported
compilers be open source is a plus not a minus... the users will be jumping in offering bug fixes and
improvements. The sort of people that program controllers just have to be 100% in favor of all technical
info being out in the open where they know they can get at it if they ever need to. I'd make the IDE open
source as well, that way complainers can spruce it up as they see fit and you can incorporate the
best improvements into the 'official' version. You guys made the coolest and strangest controller there
is so adopt the coolest official software package and have it all open source.
People willing to jump in and help write some code or documentation could speak up in this thread.
I'm proposing a Propeller with a different ROM content. A VM for C instead of Spin.
Wouldn't that mean two different chips? Which would mean you need to know what language you want to use when you order your Propeller - and once you've chosen, you're stuck with it. Sounds like you would be splintering your own market.
Or are you proposing that Parallax dump SPIN altogether? If so, I would strongly countenance against this. SPIN is a great language for many purposes - it is just not suitable for all purposes.
heater said...
Looks like we can do a ZPU virtual machine in one COG [noparse][[/noparse]see note] that can execute pukka C code compiled with GCC at about the same rate as Spin.
I can't see the point of going to all this effort - either PMC, (with all due respect to Dave Hein and heater!) CSPIN or ZPU - just to end up with C that executes at the same rate as SPIN. Personally, I doubt that such an implementation of C could even approach SPIN speeds when implementing the full C language - but for arguments sake I'll accept that with enough engineering effort it might be possible (and if it is possible, someone in these forums will do it!).
C has many drawbacks. By any standards it is an old language, encourages poor programming practice, is difficult to use, error-prone and hard to understand. However, there are two main reasons why it has retained its popularity, with over 50% of the embedded market still using it 40 years after its initial creation:
There is only one C. This was not always true, but is true now (ok - pedants will point out that there is C89 and C99 - but in the embedded space C89 unquestionably rules the roost). History has shown that anything that pretends to be C but is not really C will not get used.
C is the fastest high-level language around (again, pedants will point out cases where language X on architecture Y executes faster than C - but in general, C is many times faster than any other language on the same architecture). An implementation of C that is not substantially faster than SPIN will not get used - especially when there are already alternatives that are.
If PMC can't achieve BOTH of these things, then all it is is a language that has all the inherent drawbacks of C but without any of the advantages. At best, such a product will remain a curiosity that will not get used. At worst, it could damage Parallax's credibility and reputation, and (disaster!) consign the Propeller to an obscurity it doesn't deserve.
By all means invent a new language (or improve SPIN) to make it more suitable for educational purposes. But don't fool yourself that it's C, or that it will capture any professional C programmers or new market share.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
PhiPi said...
The thing I like about Spin vs. C is that it facilitates rapid prototyping, without a lot of crufty declarations and squiggly syntactic silliness (i.e. braces and semicolons). Which is easier to read, write, and understand, after all: repeat i from 1 to 5 or for (i = 1; i <= 5; i++) { ? This can be a huge selling point for commercial developers, for whom time is money, and a quick time-to-market can make the difference between success and failure. Rather than bowing to C, it might be better for Parallax to exploit and promote the distinct commercial advantages of Spin.
I disagree. I think the C version is much more clear and precise. With the Spin repeat, I am constantly wondering if the end bound is inclusive or not. "to" means what? Also, there have been instances where I want to step by a non constant value, which IIRC I couldn't do with the repeat structure.
In any case, I would like to see improvements to the IDE. I'll add a new suggestion to the list. How about incorporating Andy's PASD debugger and the serial terminal directly into the tool? I really like both programs, but switching between the three things that use the same serial port gets old quick. It's alot of window switching and port closing. If they were integrated into the IDE then a single F key press could automatically start PASD or the terminal.
JT Cook said...
The process I have for making games on a micro is create a similar environment on the PC using SDL to mimic the functions of the audio and video drivers that run on the micro. This way I can program 95% of a game on the PC, then switch a few lines of code to have it compile on the micro. Even if the Propeller C is not 100% compliant, I believe I could make a similar setup, but with SPIN I cannot do this.
@JT, would you use a PC based Spin/PASM virtual machine development and run-time environment?
@RossH, I think a smaller binary image C is likely more useful than a faster C for today's Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Yes, I agree there is a difficult time/space tradeoff to be made on the Prop I (the Prop II will not have this problem - roll on the PropII!).
Obviously everyone would like to have C that occupies the space of SPIN but executes at the speed of PASM. Unfortunately this is not possible.
The only realistic choices are:
- C that occupies four times the space of SPIN but executes at four times the speed (of course, these are approximations).
- C that occupies the space of SPIN but executes only at the speed of SPIN (again, this is an approximation).
Catalina (and ICC) are the former. PMC (and CSPIN and ZPU) are the latter.
The former is already catered for. The crux of this discussion is whether there is a real call for the latter - obviously (from the interest in this thread alone!) there is some interest, but is there enough to justify the diversion of scarce Parallax resources to making it happen?
The answer to that is a definite "maybe".
But actually my argument is not about that at all - my arguments is that whether Parallax does it or not will not make one whit of difference to professional C programmers adopting the Propeller, or improve the penetration of the Propeller in industrial or embedded markets.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
RossH: I agree, and I would add that doing something that is only C like and has a lot of weird differences (special operators or whatever) would be a pretty bad thing to do to new programmers and students which it seems is the primary target of this effort.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
C is the fastest high-level language around (again, pedants will point out cases where language X on architecture Y executes faster than C - but in general, C is many times faster than any other language on the same architecture). An implementation of C that is not substantially faster than SPIN will not get used - especially when there are already alternatives that are.
I agree with this. To me, the advantage I see in C is the compiled assembly approach, not necessarily the syntax.
Seems to me, short assembly programs could be in C, as well as longer ones compiled to byte codes.
Clearly you get it, and it's a good idea; however, we may never see such an implementation [noparse]:)[/noparse]
RossH said...
But actually my argument is not about that at all - my arguments is that whether Parallax does it or not will not make one whit of difference to professional C programmers adopting the Propeller, or improve the penetration of the Propeller in industrial or embedded markets.
I agree with that core argument %100. If all you want to do is flash LEDs or do other introductory micro-controller class work, the tool really doesn't matter that much. There are more appropriate alternatives for professional development for processor choice and language variant.
What I can't stand is being %80 done with a Propeller project and there is no memory left to finish. I don't use Catalina or ICC because I know there will usually not be enough room in the propeller to finish regardless of how optimized the compiler is - of course this is my fault for trying to fit a big project into one Propeller in the first place.
If one needs speed on the Propeller PASM is the best choice. If one needs compact code, something that emits spin byte code (Spin today) is the best choice. Everything else is somewhere in between.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
I also find it very interesting how C just doesn't map to the prop in a clean way. The chip is really different, and there are trade-offs for that, and serious advantages too!
IMHO, pro C programmers faced with a Prop, that had a C environment that would do byte codes, or PASM, would find ways to map their projects to the Prop where there is overlap in general capability. This is a damn good thing!
Why?
Because they naturally are going to push the chip a little, and if they can do so in C, then the prop advantages shine, and suddenly all those other libraries and such they depend on get marginalized rather quickly. It also seems to me that really getting the most out the other chips is a delicate balance of kernel code, interrupts, and such all woven together to just work. On a Prop, that stuff is more or less automatic for a whole bunch of stuff. Some of that will map over with Prop specific library functions, but some of it just won't. When they try it the Prop way, a bunch of systems level programming and timing stuff goes away, and that's the magic right there!
What's not to like?
Do it. Have a directive for C=>PASM, and that builds code that goes on a COG, just like a DAT PASM block does. The rest of the code is byte code, making the most of the on-chip interpreter, and let the programmers sort it out like programmers will. Don't forget a full on assembly environment too, just like you would find in any other C environment. Let them figure out how to best apply those things. That's what C is about. The programmer gets to do really stupid things, and really powerful things. SPIN + PASM is managed to keep people outta trouble, and look at all the stuff done to circumvent that. This is the chance to put all that to bed, not devaluing the SPIN + PASM at all!
C=>SPIN is more of a curio than anything else, from where I stand. And I don't get that at all. If one knows C, they can sure as hell grok SPIN. And if they don't know either, what's the point in having the SPIN layer??
I honestly would love to give that C, with byte code and PASM directives a go. I've written in C. Not a whole lot, but some. Frankly, SPIN + PASM is way more lean, fun, and flat out easy to do stuff with. However, being able to do more complex things, without losing that SPIN+PASM advantage, would be worth it. Going LMM costs too much.
C=>SPIN seems a headache to me. Not that I won't endure a head ache to do some stuff, but it's actually gotta do some stuff, and what exactly will a C=>SPIN dev path really do?
JT Cook said...
The process I have for making games on a micro is create a similar environment on the PC using SDL to mimic the functions of the audio and video drivers that run on the micro. This way I can program 95% of a game on the PC, then switch a few lines of code to have it compile on the micro. Even if the Propeller C is not 100% compliant, I believe I could make a similar setup, but with SPIN I cannot do this.
@JT, would you use a PC based Spin/PASM virtual machine development and run-time environment?
Probably not unless it emulated the video rendering functions, which it probably wouldn't, at least not anytime soon [noparse]:)[/noparse]
There are also questions about speed using Propeller C vs SPIN and I couldn't imagine there would be much of a speed difference. I am sure the Propeller C will compile into SPIN byte code and code that is similarly written between the two should also compile similarly.
And I don't think we will ever see (at least from Parallax) a Propeller C or SPIN compiler that will compile small programs into assembly since the COG code space is so small.
I think the Parallax C or C-like will be a good way to get people into the door of the Propeller. Even if it isn't 100% C, new people won't have to feel like they have to learn a brand new. And since it will be built into the Prop tool they won't have to sacrifice the many drivers already written in SPIN/ASM.
RossH said...
...
I can't see the point of going to all this effort - either PMC, (with all due respect to Dave Hein and heater!) CSPIN or ZPU - just to end up with C that executes at the same rate as SPIN. Personally, I doubt that such an implementation of C could even approach SPIN speeds when implementing the full C language - but for arguments sake I'll accept that with enough engineering effort it might be possible (and if it is possible, someone in these forums will do it!).
...
Ross
There are a few useful features from converting C to Spin bytecodes -- It is a very compact code, and it would be compatible with the existing Spin code in the OBEX.· A C compiler of this type would be useful to hobbyist who want to develop applications that work at the same level as current Spin programs.
I believe that an ANSI standard C compiler could generate Spin bytecodes that would be as efficient as a Spin compiler for many applications.· Of course, there will be cases where strict compliance to C will cause extra operations to be performed.· A simple example would be the use of char versus unsigned char.··Accessing a char would require·a sign extension operation, whereas the unsigned char would not need the sign extension.
I think the Prop I could get by with a cspin-like implementation.· However, I believe that the Prop II will need real C development tools, such the Catalina C compiler.· Parallax would have to officially support those type of develop tools to be taken seriously by development teams looking for the right processor for their project.
So, the real question for Parallax is whether it is worth the effort to provide a C-to-Spin development tool for the short term knowing that they will need a full-blown C development system for the long term.
Dave
Has the "need for a C=>SPIN environment" been qualified -vs- C=>byte code and C=>PASM?
There is a big difference between "interested", and "need". Given the Prop tool is free, "need" must be very seriously qualified, or it's not only a failed value add, but one that is a cost in and of itself, not just an opportunity cost, like one would see with a non-free dev tool.
Interested fills a check box, or gets somebody curious. That's good, they might look at a prop. If the value isn't properly presented, or is seriously misaligned with the expectations, then it's bad. They put the prop away [noparse]:([/noparse]
I'm reading a conflict here between some educational goal, with the question of it being realistic. Not a lot of consensus on that yet. And the other element of "attracting pros".
The pros are gonna want a C environment that lets them get on the chip hard. There is no getting around this. And Prop II will scale such that an environment like that will totally make sense. Why not build that out now, perhaps leveraging it big on the next chip? That kind of double dip on value add is very tough to ignore, for me at least. Prop II could support real systems level stuff too, meaning an advanced LMM kernel, and scheduling system to run COGs and bodies of PASM, is on the table. That's the kind of ugly Smile people do with C. Again, why not get started down that road, for those who are gonna want it?
So, which is it? Might I suggest it can't be both? And might I also suggest that the idea of the educational approach isn't all that well qualified? It might be, but I've not seen it.
Any discussion at Parallax really needs to work through those things, or it's a potential time and energy sink that makes a lean company less lean.
Edit: It just hit me! Would a C environment like that compete with SPIN + PASM? Is that the perception? If so, I think that discussion needs to be had, and soon. I don't think it will, but it could. Maybe another thread...
SRLM said...
I think the C version is much more clear and precise. With the Spin repeat, I am constantly wondering if the end bound is inclusive or not. "to" means what?
Apparently, you're constantly not reading the manual, either. At your young age, once or twice should be enough to remember it!
Frankly, I'm annoyed by the repeat loop, but I've gotten used to it.
"for(n = 0; n < 10; n++) ;" and "repeat n from 0 to 10" do the same thing.
The for loop for me is exceptionally clear at first glance. The repeat loop is not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Comments
Actually, you don't really have to call it C anyway.· Just say it has a C-like syntax.
I think if the Parallax programmers weren't Pascal programmers then·SPIN would already have a C-like syntax instead of a Pascal-like syntax and life would be better.
I have to deal with Fortran code sometimes, which is even worse than Pascal, so things could be worse, I suppose...
A Parallax version of Dave Hein's CSPIN is about what we need, I think...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
Post Edited (Rayman) : 4/17/2010 10:22:10 PM GMT
I like it! I does look like a Parallax version of CSPIN...
I'm thinking it must be close to finished too, if they're doing documentation already...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
I'm proposing a Propeller with a different ROM content. A VM for C instead of Spin.
Looks like we can do a ZPU virtual machine in one COG [noparse][[/noparse]see note] that can execute pukka C code compiled with GCC at about the same rate as Spin.
With that comes some bonuses like being able to use C++ and FORTRAN even Java etc as supported by GCC.
Anyone wanting to use C on the Prop is not much going to want Spin hanging around anyway.
Note: Requires a dispatch table in HUB but that could be in ROM also.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
If that is the sole determinant for "easier to read, write, and understand," you would see Modula 2 and Pascal programmers being in high demand.
Think about this, in 2010, 20% of programmers still use C professionally. This is despite C++, Java, PHP, Python, Perl, FORTRAN, Ada, COBOL, BASIC, etc, etc.
Non-Standard C no longer has a place in the industry. Rabbit Semiconductor tried that tack 10 years ago with Dynamic C and that is always one of its Achilles Heels. It is seldom seen as an advantage.
But, I think the main advantage of this thing is that it used the ROM Spin interpreter (if I'm understanding it right).
So, just like CSPIN, you program in something like C and that get translated into SPIN byte codes.
This has the advantage of being able to make the most efficient use of RAM, even though it's probably slower and more limited that ICC or Catalina.
Being able to use the SPIN and assembly drivers AS IS, is a huge benefit too...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm
My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
-Phil
The process I have for making games on a micro is create a similar environment on the PC using SDL to mimic the functions of the audio and video drivers that run on the micro. This way I can program 95% of a game on the PC, then switch a few lines of code to have it compile on the micro. Even if the Propeller C is not 100% compliant, I believe I could make a similar setup, but with SPIN I cannot do this.
I also think Parallax is very smart for introducing this application this side of the Propeller life cycle because they test it and perfect it on the first Propeller micro and by the time the Propeller 2 was ready to ship, the application would be stable and ready to go. I also think that this will open the door for people who don't want to learn SPIN to take advantage of this chip, or for people like me who has to program on multiple platforms and doesn't use SPIN full time.
I'll second that
* I know Terry's demonstrated a dispatcher "thingy", but I've not got my head around that yet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheers,
Simon
www.norfolkhelicopterclub.com
Announcement: To cut costs in the current economic climate, we have switched-off the light at the end of the tunnel.
I thought that finally Parallax was going to support C on the prop in a big way.
But I changed my mind along the way. As I said before, I say again, why not
just use, support and improve Catalina. There is no reason to create something
internally, don't reinvent the wheel... using Catalina is the easy way to go, and the fast way.
Atmel has no problem mentioning in their ads that free WinAVR is available. They put
support right into their IDE.
Align Parallax support behind both Catalina and PropBasic and create good beginners manuals
for using both. Build support into your own IDE for both of them. And start advertising that
the Propeller comes with both C and Basic ready to go for free!
Sorry to say all this the second time in this thread but I just feel this is the right thing to
do!
There is nothing wrong with supporting a gpl C for the Propeller. Nothing says you can't pay
some great C coders to jump in and improve it. Gpl doesn't mean all the work on the project must be gratis.
There are probably several people right here on the forum that would start work immediately if
you gave the word. Anyway, since Catalina is aimed only at the propeller no competitor could make
any use of it at all, so why care if it is open source. Spend some $ to perfect it.
I would not make it a closed source proprietary Catalina owned by Parallax. Having the company supported
compilers be open source is a plus not a minus... the users will be jumping in offering bug fixes and
improvements. The sort of people that program controllers just have to be 100% in favor of all technical
info being out in the open where they know they can get at it if they ever need to. I'd make the IDE open
source as well, that way complainers can spruce it up as they see fit and you can incorporate the
best improvements into the 'official' version. You guys made the coolest and strangest controller there
is so adopt the coolest official software package and have it all open source.
People willing to jump in and help write some code or documentation could speak up in this thread.
Or are you proposing that Parallax dump SPIN altogether? If so, I would strongly countenance against this. SPIN is a great language for many purposes - it is just not suitable for all purposes.
I can't see the point of going to all this effort - either PMC, (with all due respect to Dave Hein and heater!) CSPIN or ZPU - just to end up with C that executes at the same rate as SPIN. Personally, I doubt that such an implementation of C could even approach SPIN speeds when implementing the full C language - but for arguments sake I'll accept that with enough engineering effort it might be possible (and if it is possible, someone in these forums will do it!).
C has many drawbacks. By any standards it is an old language, encourages poor programming practice, is difficult to use, error-prone and hard to understand. However, there are two main reasons why it has retained its popularity, with over 50% of the embedded market still using it 40 years after its initial creation:
- There is only one C. This was not always true, but is true now (ok - pedants will point out that there is C89 and C99 - but in the embedded space C89 unquestionably rules the roost). History has shown that anything that pretends to be C but is not really C will not get used.
- C is the fastest high-level language around (again, pedants will point out cases where language X on architecture Y executes faster than C - but in general, C is many times faster than any other language on the same architecture). An implementation of C that is not substantially faster than SPIN will not get used - especially when there are already alternatives that are.
If PMC can't achieve BOTH of these things, then all it is is a language that has all the inherent drawbacks of C but without any of the advantages. At best, such a product will remain a curiosity that will not get used. At worst, it could damage Parallax's credibility and reputation, and (disaster!) consign the Propeller to an obscurity it doesn't deserve.By all means invent a new language (or improve SPIN) to make it more suitable for educational purposes. But don't fool yourself that it's C, or that it will capture any professional C programmers or new market share.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
I disagree. I think the C version is much more clear and precise. With the Spin repeat, I am constantly wondering if the end bound is inclusive or not. "to" means what? Also, there have been instances where I want to step by a non constant value, which IIRC I couldn't do with the repeat structure.
In any case, I would like to see improvements to the IDE. I'll add a new suggestion to the list. How about incorporating Andy's PASD debugger and the serial terminal directly into the tool? I really like both programs, but switching between the three things that use the same serial port gets old quick. It's alot of window switching and port closing. If they were integrated into the IDE then a single F key press could automatically start PASD or the terminal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Powered by enthusiasm
@RossH, I think a smaller binary image C is likely more useful than a faster C for today's Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
Yes, I agree there is a difficult time/space tradeoff to be made on the Prop I (the Prop II will not have this problem - roll on the PropII!).
Obviously everyone would like to have C that occupies the space of SPIN but executes at the speed of PASM. Unfortunately this is not possible.
The only realistic choices are:
- C that occupies four times the space of SPIN but executes at four times the speed (of course, these are approximations).
- C that occupies the space of SPIN but executes only at the speed of SPIN (again, this is an approximation).
Catalina (and ICC) are the former. PMC (and CSPIN and ZPU) are the latter.
The former is already catered for. The crux of this discussion is whether there is a real call for the latter - obviously (from the interest in this thread alone!) there is some interest, but is there enough to justify the diversion of scarce Parallax resources to making it happen?
The answer to that is a definite "maybe".
But actually my argument is not about that at all - my arguments is that whether Parallax does it or not will not make one whit of difference to professional C programmers adopting the Propeller, or improve the penetration of the Propeller in industrial or embedded markets.
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Check out the Propeller Wiki·and contribute if you can.
I agree with this. To me, the advantage I see in C is the compiled assembly approach, not necessarily the syntax.
Seems to me, short assembly programs could be in C, as well as longer ones compiled to byte codes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
I agree with that core argument %100. If all you want to do is flash LEDs or do other introductory micro-controller class work, the tool really doesn't matter that much. There are more appropriate alternatives for professional development for processor choice and language variant.
What I can't stand is being %80 done with a Propeller project and there is no memory left to finish. I don't use Catalina or ICC because I know there will usually not be enough room in the propeller to finish regardless of how optimized the compiler is - of course this is my fault for trying to fit a big project into one Propeller in the first place.
If one needs speed on the Propeller PASM is the best choice. If one needs compact code, something that emits spin byte code (Spin today) is the best choice. Everything else is somewhere in between.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
IMHO, pro C programmers faced with a Prop, that had a C environment that would do byte codes, or PASM, would find ways to map their projects to the Prop where there is overlap in general capability. This is a damn good thing!
Why?
Because they naturally are going to push the chip a little, and if they can do so in C, then the prop advantages shine, and suddenly all those other libraries and such they depend on get marginalized rather quickly. It also seems to me that really getting the most out the other chips is a delicate balance of kernel code, interrupts, and such all woven together to just work. On a Prop, that stuff is more or less automatic for a whole bunch of stuff. Some of that will map over with Prop specific library functions, but some of it just won't. When they try it the Prop way, a bunch of systems level programming and timing stuff goes away, and that's the magic right there!
What's not to like?
Do it. Have a directive for C=>PASM, and that builds code that goes on a COG, just like a DAT PASM block does. The rest of the code is byte code, making the most of the on-chip interpreter, and let the programmers sort it out like programmers will. Don't forget a full on assembly environment too, just like you would find in any other C environment. Let them figure out how to best apply those things. That's what C is about. The programmer gets to do really stupid things, and really powerful things. SPIN + PASM is managed to keep people outta trouble, and look at all the stuff done to circumvent that. This is the chance to put all that to bed, not devaluing the SPIN + PASM at all!
C=>SPIN is more of a curio than anything else, from where I stand. And I don't get that at all. If one knows C, they can sure as hell grok SPIN. And if they don't know either, what's the point in having the SPIN layer??
I honestly would love to give that C, with byte code and PASM directives a go. I've written in C. Not a whole lot, but some. Frankly, SPIN + PASM is way more lean, fun, and flat out easy to do stuff with. However, being able to do more complex things, without losing that SPIN+PASM advantage, would be worth it. Going LMM costs too much.
C=>SPIN seems a headache to me. Not that I won't endure a head ache to do some stuff, but it's actually gotta do some stuff, and what exactly will a C=>SPIN dev path really do?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 4/18/2010 3:55:16 AM GMT
Probably not unless it emulated the video rendering functions, which it probably wouldn't, at least not anytime soon [noparse]:)[/noparse]
There are also questions about speed using Propeller C vs SPIN and I couldn't imagine there would be much of a speed difference. I am sure the Propeller C will compile into SPIN byte code and code that is similarly written between the two should also compile similarly.
And I don't think we will ever see (at least from Parallax) a Propeller C or SPIN compiler that will compile small programs into assembly since the COG code space is so small.
I think the Parallax C or C-like will be a good way to get people into the door of the Propeller. Even if it isn't 100% C, new people won't have to feel like they have to learn a brand new. And since it will be built into the Prop tool they won't have to sacrifice the many drivers already written in SPIN/ASM.
There are a few useful features from converting C to Spin bytecodes -- It is a very compact code, and it would be compatible with the existing Spin code in the OBEX.· A C compiler of this type would be useful to hobbyist who want to develop applications that work at the same level as current Spin programs.
I believe that an ANSI standard C compiler could generate Spin bytecodes that would be as efficient as a Spin compiler for many applications.· Of course, there will be cases where strict compliance to C will cause extra operations to be performed.· A simple example would be the use of char versus unsigned char.··Accessing a char would require·a sign extension operation, whereas the unsigned char would not need the sign extension.
I think the Prop I could get by with a cspin-like implementation.· However, I believe that the Prop II will need real C development tools, such the Catalina C compiler.· Parallax would have to officially support those type of develop tools to be taken seriously by development teams looking for the right processor for their project.
So, the real question for Parallax is whether it is worth the effort to provide a C-to-Spin development tool for the short term knowing that they will need a full-blown C development system for the long term.
Dave
There is a big difference between "interested", and "need". Given the Prop tool is free, "need" must be very seriously qualified, or it's not only a failed value add, but one that is a cost in and of itself, not just an opportunity cost, like one would see with a non-free dev tool.
Interested fills a check box, or gets somebody curious. That's good, they might look at a prop. If the value isn't properly presented, or is seriously misaligned with the expectations, then it's bad. They put the prop away [noparse]:([/noparse]
I'm reading a conflict here between some educational goal, with the question of it being realistic. Not a lot of consensus on that yet. And the other element of "attracting pros".
The pros are gonna want a C environment that lets them get on the chip hard. There is no getting around this. And Prop II will scale such that an environment like that will totally make sense. Why not build that out now, perhaps leveraging it big on the next chip? That kind of double dip on value add is very tough to ignore, for me at least. Prop II could support real systems level stuff too, meaning an advanced LMM kernel, and scheduling system to run COGs and bodies of PASM, is on the table. That's the kind of ugly Smile people do with C. Again, why not get started down that road, for those who are gonna want it?
So, which is it? Might I suggest it can't be both? And might I also suggest that the idea of the educational approach isn't all that well qualified? It might be, but I've not seen it.
Any discussion at Parallax really needs to work through those things, or it's a potential time and energy sink that makes a lean company less lean.
Edit: It just hit me! Would a C environment like that compete with SPIN + PASM? Is that the perception? If so, I think that discussion needs to be had, and soon. I don't think it will, but it could. Maybe another thread...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 4/18/2010 4:10:59 AM GMT
-Phil
"for(n = 0; n < 10; n++) ;" and "repeat n from 0 to 10" do the same thing.
The for loop for me is exceptionally clear at first glance. The repeat loop is not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
May the road rise to meet you; may the sun shine on your back.
May you create something useful, even if it's just a hack.
-Phil