Only to know about C program ( using Propeller)
markuster
Posts: 184
Hi
Only to understand why I have to pay if I want to use
C with the Propeller and if I use an other microcontroller
the C is free.
Sorry, but I don't understand.
Do you know?
Thanks, Mark.
Only to understand why I have to pay if I want to use
C with the Propeller and if I use an other microcontroller
the C is free.
Sorry, but I don't understand.
Do you know?
Thanks, Mark.
Comments
There is a *free* (as in both beer and the other one) version of C for the Propeller in addition to the commercial compiler.
The reason you get a free compiler for the other microcontroller is someone has written one (or modified one) and given it away gratis.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?
Leon
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Amateur radio callsign: G1HSM
Suzuki SV1000S motorcycle
BradC is basically correct. Because of the open-source movement and Linux, there are a number of toolchains for building compilers, particularly C compilers, available for people to use. These have been applied to many different processors. Even with the toolchains, it's very difficult to make a good compiler (one that produces compact, efficient code) for a microcontroller. Some companies (like ImageCraft) have done this and done it well and expect to be paid reasonably for their efforts. In other cases, a large manufacturer has done the work in-house like Microchip and distribute their compilers for free or inexpensively as a way to get people to use their chips. Keep in mind that C is not the best language for most microcontrollers although it's not bad and is the "Lingua Franca" of the computing world.
Parallax is a small company that has developed a unique microcontroller. In the process of developing the hardware, they also developed their own programming language (Spin), well matched to the hardware. Among other things, it enables an efficient interpreter to be wholy contained in the local memory of any of the processors on the chip. The IDE also includes an assembler integrated into the compiler. It might have been possible to develop a C compiler for this interpretive code, but it would need non-standard extensions to efficiently make use of a lot of the features of the hardware and it would have been a problem to give up some of this efficiency in trying to keep to the C standard for the initial development system.
Parallax itself does not have the resources to support a 2nd language and development system. ImageCraft, which has commercial compilers for other platforms, took a chance and, using their toolchain and expertise, produced a C development system for the Propeller that's available inexpensively. Since then, one of the forum members took an open-source C compiler toolchain and developed a code generator and basic library that's now available for free (Catalina). It doesn't generate as efficient code as ImageCraft's, but it does have some unique features like multiple code interpreters including one for large external RAM. Both ImageCraft's compiler and Catalina produce interpretive code that's mostly the same as the Propeller's instructions (called LMM - Large Memory Model) and can be interpreted several times faster than Spin, but take several times the amount of memory for the same functionality.
Parallax is a private company that relies on others' contributions, thus Catalina (free) and ImageCraft C.
Imagecraft has a fully functional 45 day version of their C compiler for free, after that there is code size is limited to non-commercial use.
Can't go wrong with using their product.
The Propeller also has an onboard SPIN interpreter. The SPIN language was developed for the Propeller, so it is a good fit for the hardware.
So while C compilers have been created for the Propeller, there are significant advantages to using the "native" SPIN and assembly languages.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
There is a free C compiler for the Propeller - called Catalina. It is not supported, sponsored or endorsed by Parallax in any way, but it works quite happily nonetheless
Both compilers significantly outperform SPIN in terms of program execution speed, but both generate much larger executables than the SPIN equivalent.
Whether you would be better of with Catalina or with Imagecraft depends both on your needs and your budget. Imagecraft is a reasonable deal for hobbyists if you don't mind code size limits - both the code size limits imposed of the the "free" version of Imagecraft, as well as the code size limits inherent in a compiler that must fit its code and data entirely within the 32k available internally on the Propeller. Catalina can run programs with code and data size up to 16Mb by using external RAM (several hardware platforms with external RAM are currently supported, more are being added). Catalina outperforms Imagecraft on some benchmarks, but generally doesn't do as well as it in both speed and code size (but it's improving all the time).
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
SPIN is great but not super speedy compared to PASM.
If you are going to use the propeller for serious work
then you absolutely must become comfortable in PASM.
An hour a day for a few weeks will get you well into PASM.
The unique qualities of the propeller are worth spending the
time to learn PASM, trust me on this
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Where am I? Where am I going? Why am I in a handbasket?"
I'm not sure why Parallax chose to create the SPIN language with it's unique syntax elements and its arbitrary indentation requirement.· Much of the SPIN syntax is similar to C, but it requires the programmer to memorize a whole new set of language quirks that are specific only to SPIN.· There is an incredible amount of open source code written in C.· It would be much easier to port open source C code than convert it to the SPIN language.
The only reason that I can see for inventing a SPIN language was to control what could be done in the language so an interpeter would fit in a COG's memory.· However, I think the LMM C compilers will eventually eliminate the requirement to write programs in SPIN.
Dave
SPIN has less "baggage", which makes it "easier".
These things make the Propeller really accessable, without a huge investment in time, tools and such. The unique design of the chip more or less warranted an environment for it. Let's say C was the default, as shipped, programming environment. A quick look back through the pioneering times would have shown quite a few new comers, myself included, not having quite the good time of it they did otherwise. That's SPIN + PASM in play here, and that's a strong differentiator for the Propeller. The cost, is having to learn a thing or two, but the pay off is a nice, simple, rapid dev environment.
For seasoned pros, or those with limited experience outside of C (and do those people exist?), it's a bit of a burden for the learning. I see that. But I really can't warrant "easier" because of it. IMHO, too many factors in play.
**And I like C and have some moderate skill with it. SPIN + PASM is cake by comparison, in a whole lot of ways. The primary one being it's just so low overhead. That comes with no structures and such, but it also means just more or less writing something, and that product being close to what is really needed to run it. Where C does require a bit more investment to accomplish the same thing.
One final thing, given the limited memory available, not having SPIN would be a huge disadvantage. SPIN runs at about the same speed as older chips run assembly. (I'm talking 8 bit computer assembly) That's plenty fast to organize and control things at higher levels, leaving PASM / LMM to do the grunt work. With that in play, a whole lot can be done in the 32K. I guess that can stand as to why it was done. Best use case for the chip resources kind of thing.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 10/19/2009 3:46:29 PM GMT
> The cost, is having to learn a thing or two, but the pay off is a nice, simple, rapid dev environment
Yes, this is well said. IMO, if you can program in C, you can do SPIN. There's only a few odd things at first: the indentation requirement - but if you write clean C code, then you'll be indenting anyway. Just think of all the time you'll save having to write matching braces {} :-} The other things ... minor syntactical stuff ... some new keywords. The new language elements don't seem like a big deal to me. Consider how much you have to learn and keep track of when you're using a C library - or, worse, GUI stuff...
document.items("FooWidget").Object.("Object").Hello(); anyone?
SPIN is easy if you get a few references, study some of the code others have done here.
@Mark (OP) - Ross's Catalina compiler is very nice ... why not try it ... and do some SPIN on the side? Could broaden your horizons... not that SPIN would be killer to have on your resume. On the otherhand Propeller Assembler (PASM) might be - "Assembler" is often thought of as one of those "hard things to do". "And Propeller Assembler" justs sounds too cool not to take advantage of [noparse]:)[/noparse])
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I'm not sure why Spin proponents always bring up the curly braces thing. I've been coding in C for a year now (for school), and I've never had any problems with curly braces. Any editor worth it's salt should automatically highlight the matching brace, and most editors will autoformat your code. If the error makes it past there, then the compiler will probably catch it. If you are still having problems, then I think you have too many nested structures and need to break some out into functions.
Likewise with the function calls. It simply translates to a sentence: "Get the FooWidget from the document, then the Object from FooWidget, and call it's Hello function." Personally, I wish spin had more OOP support so that it is a full OOP language.
Still, Spin and C are like a hawk and a falcon: they both look different, and there are some internal differences, but for the most part they use the exact same principles. I don't see what all the fuss is about when somebody doesn't want to learn a new language. Fundamentally, most languages are very similar in the implementation of algorithms. Some are faster and some take more memory, but they all have the same properties.
Compiling from C to native Propeller assembler is a no-no because the instructions set does not directly support stacks or indexed addressing etc but mostly because of the restriction of the 496 instruction space within a COG. Hardly worth all the effort of creating a compiler.
That would leave compiling to some byte code system as in some Pascal systems, Java, C# or indeed Spin itself. But then the byte code interpreter would ideally fit in a COG (496 LONGS) which probably has repercussions on the capability of the byte codes available. Which again may not be suitable for a C compiler.
Question: Why has no one stepped up and created a C compiler that produces Spin bytes code for execution by the built in interpreter ?
Enter Spin and it's bytes codes and the built in interpreter. All in all an impressive piece of work.
Now also don't forget what I believe to be in the back of Parallax's mind, they have a target market of beginners, hobbyists, educational institutions etc. The C language is one sure way to put all those people off. That would naturally lead us back to BASIC as in the STAMPS but Parallax bravely went ahead with Spin and produced a gloriously simple development environment. Almost "type and go" like the good old BASIC on C64 days. Very attractive to anyone who does not want to get bogged down in compilers, linkers, header files and all that other C junk.
At the beginning of this post I said "convince most". But there are some crazy people who have created C compilers for the Prop. Based on the idea of LMM. Basically have a PASM program running in a COG that runs PASM from HUB by fetching it on instruction at a time, executing it, fetching the next, etc etc. Something that can be done very easily with the Prop and perhaps not many other micros.
If I understand correctly not even Parallax realized this was a possibility until Bill Henning pointed it out.
The trade off here is that the C compilers produce faster code than Spin but use a lot more space in HUB.
Anyway if you want to use C on the Prop I recommend using the worlds first working C compiler for the Prop. BDS C running under CP/M under the ZiCog Z80 emulator. Slow but compact. Comes with a complete dev environment that runs on the Prop as well.
Sorry just had to get that in [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Anyhow, I know I will be doing more Spin programming as time goes on, so I'm cetainly willing to master the Spin language.· The Propeller object exchange is a really useful aspect to using the processor, and I hope to contribute to it in the future.
Dave
I came up with LMM when trying to figure out how to get C onto the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Please use mikronauts _at_ gmail _dot_ com to contact me off-forum, my PM is almost totally full
Morpheus & Mem+dual Prop SBC w/ 512KB kit $119.95, 2MB memory IO board kit $89.95, both kits $189.95
www.mikronauts.com - my site 6.250MHz custom Crystals for running Propellers at 100MHz
Las - Large model assembler for the Propeller Largos - a feature full nano operating system for the Propeller
Everything that @heater said is truly what I feel on the subject ... except one paragraph [noparse];)[/noparse].
As far as a Spin byte-code C variant goes, I agree that this has merit and something was started with Small C by Peter Verkaik in 2007 here ... wish it was finished. I've seen one quote today where even Bill Henning thought something similar was a good idea [noparse]:)[/noparse] ... before the "advent" of LMM on P8X32A.
I had not heard of Peter Verkaik efforts. So at least someone thought it was worth a shot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum
SRML,
funny thing about the {} ... didn't know others had mentioned that!
It's not so much having to match them as it is having to type them at all ! [noparse]:)[/noparse]· And I haven't met an IDE yet that could autocomplete·the trailing " } "· ... how could it know?·
> I've been coding in C for a year now (for school)
wait until you hit 30 + years like me (and C will probably still be in use then [noparse]:)[/noparse])
Hmmm... let's see ... " {·" times say 100 lines of code a day, maybe 30 of which have a·{ or }, times·six days a week,·times 32 years, with two weeks off for bad behavior...
Yikes! - that's 288,000·squiggly bracket's! No wonder my keyboards ESC, space bar, enter, and { } keys break first.
Yes, but how do you know to call the object's object? Why not simply: document.items("FooWidget").Hello(); ?· Because you have to memorize this, or look it up. (And may the Code Gods have mercy on you if you ever have to traverse Outlook's object model! {Foo.Folder.Folders("name1").Folders.Folder("name2").NuggingFuts();} )· The point was simply that you have to memorize or reference·many things when coding - this should not be a hinderence to using SPIN, PASM --- or any language for that matter.
Cheers!
{//Howard();}
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Since you mention it, my right-brace IS more shiny than my left-brace. I often use it to reformat blocks of code in some IDEs ... beats the heck out of running a beautifier utility. Of course that would be a terrible habit in old code bases that get branched and resync'd all the time. Reinvestment can be a wonderful cure don't you think? ... It seems "IP depreciation" should be allowed in accounting rules.
This has been discussed in previous threads. I originally though about making Catalina emit SPIN byte codes, but I decided it was not really a good idea. SPIN is missing too many fundamental operations required for an efficient implementation of C.
SPIN and C are not really very much alike. Those who claim the languages are similar are really just pointing out that both languages are procedural, share some syntactic "sugar", and that both are "turing complete". But this doesn't necessarily mean it would be efficient to use one to implement the other. For example, SPIN byte codes have no support for either floating point or structures - parts of the C language that would be difficult and inefficient to implement using the existing byte codes.
Another option (and I considered this as well) would be to come up with an "extended" set of SPIN byte codes. But this would not really be SPIN compatible, would not run in a single cog (there's no space left!) and in any case would make C execute as slowly (probably even more slowly) than SPIN does - whereas both Catalina and Imagecraft C currently execute between 3 to 8 times faster than SPIN (depending on which benchmark you use). In any case, I finally decided that if you didn't like SPIN and really wanted a byte-coded language on the Propeller then Java would a better bet than C - but Java is both big and slow when compared to C, and would probably be even slower than SPIN.
A "SPIN to C" preprocessor would be a good solution, and fairly easy to build. Any volunteers?
Ross.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina
1) Spin bytecode
2) Own bytecode
3) LMM-style PASM
Ross gives some reasons for not doing C to Spin bytecode, another is that a C program generating Spin bytecode would unlikely be quicker than Spin. For those who are 'language neutral' ( "you can do it in Spin, you don't need C" ), it can be seen as re-inventing the wheel for little gain, it doesn't bring anything extra for programmers ( eg allow huge memories ).
You therefore need someone motivated enough to do it, can see a valuable purpose in doing it, can 'create' a compiler, and understands Spin bytecode enough to produce the object code.
An alternative is to generate Spin source code from C, again, easy enough to do. With a few mods to Homespun, goto and function pointer calls could be presented as 'native Spin' which would simplify things. Even without, it can still be done.