Seeking C compiler for Propeller
Joel Rosenzweig
Posts: 52
I'm totally new to the Propeller scene as of this week.· I've been using PIC processors for several years in some production devices that I make.· They work great.· But an 8 core SMP device really caught my attention.· So I had to have one to play with.· My Propeller stick arrived this week, so·I started to port an application of mine as a test bed.· I figured that if it could handle my test workload, then the Propeller would be adequate for my future development purposes.· I spent a few hours porting the application over and had great success with that.· Debugging over a television monitor was a riot and reminded me of debugging software on my Atari 800.· There's a certain cool factor to that.·
At any rate, I'm checking in to see if anyone knows of either an existing C compiler, or plans to create a C compiler for the Propellor?· The Spin language is workable, but a C compiler would make my time even more efficient.·· I paid $150 to CCS for a PIC C compiler.· I'd be happy to purchase a tool in a similar price range for the Propellor if it were available.
Thanks,
Joel-
At any rate, I'm checking in to see if anyone knows of either an existing C compiler, or plans to create a C compiler for the Propellor?· The Spin language is workable, but a C compiler would make my time even more efficient.·· I paid $150 to CCS for a PIC C compiler.· I'd be happy to purchase a tool in a similar price range for the Propellor if it were available.
Thanks,
Joel-
Comments
The world just isn't quite like that.
The halcyon days of C are fading.
Why pay $150 for an IDE when you can have SPIN for nothing? It is just about the easiest language that one can hope for. And, you really need to have something that is quite close to the hardware as the Propeller is unlike any other hardware.
Most of the advantages of C were for the development of UNIX and those advantages don't seem to apply so well to the world of microcontrollers. C allowed for unifying a network of many different mainframes. These days, the mainframe industry has shrunk and standarized. Java has taken over cross platform migration. And Microsoft's Basic is really a huge object oriented program that has little relationship to the Dartmouth origins.
I wanted Parallax to provide C for the SXes and they still may. Initially I thought that one needed to learn C to be a good programer, but now I see it as mostly a convience when reading other people's code. One might even consider it a bit passe'. C# and darn near everything else has taken on a object oriented approach.
You really might do best to spend your $150 on learning to program the SX-28 in Assembly. Parallax's kit and Guenther's text made learning Assembly a joy.· That knowledge would be transferable to the PICs and the speed would be lickety-split. C may just be keeping you from really writing better code and most of microcontroller code is about interfacing and driving hardware in a tight space.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
Post Edited (Kramer) : 8/27/2006 7:37:49 PM GMT
You might see a C compiler to interpretive code. Someone would have to write their own interpreter or decipher the SPIN interpreter's instruction set which is currently proprietary to Parallax. Again, given the free availability of the SPIN IDE, I'm not sure where there would be enough of a market. Someone might do it as a hobby project or university project.
Another hobby or university project might be a C to SPIN compiler.
For any CPU with a stack and heap in the same memory space, C (and it's descendants) has numerous advantages over other languages; not the least being elegance.
But, most microcontrollers don't have such an architecture (notable exceptions are the AVR and PIC 18); and wedging it on (i.e., emulation in the ABI) gets to be a stretch.
Also, C-and-friends are useful for more than UNIX - IIRC, much of the Windows kernel is written in it.
>> C allowed for unifying a network of many different mainframes.
Yeah... but it's a darn good language, too...
>> Java has taken over cross platform migration.
Only for some stuff... hardcore apps like Apache or MySQL are written in C/C++ for speed...
>>And Microsoft's Basic is really a huge object oriented program
I really must disagree with you there... VB ain't real OOP. Some would argue that C++ isn't real OOP either, but I think that's a little bit extreme... In my book, C++, Object-Pascal, Objective-C, and Java are all OOP. VB, AppleScript, Spin, and languages like them, aren't.
>> Initially I thought that one needed to learn C to be a good programer
Yes, actually you do; along with Pascal, a few assemblers, a shell language or two, a high-level scripting language (like HyperTalk, AppleScript, Lingo - or some of their descendants), and a smattering of Basic, Fortran, and Cobol for perspective -- the idea being to learn how to think in that space; and to know when what you are doing is because of a peculiarity of your language, or a peculiarity of your problem.
>> One might even consider it a bit passe'.
No, C itself is the foundation upon which the great languages of our time have been laid. To not know C, but try to understand C++, Objective-C, or Java is like trying to understand calculus without understanding algebra.
>> C# and darn near everything else has taken on a object oriented approach.
OOP is nice. OOP is great for many things. I love OOP. I wouldn't dream of trying to write a desktop app without it. BUT --- not all problems are composed of complex objects interacting; indeed, most MCU stuff isn't - and layering OOP constructs upon the problem space does not always improve matters. There is still a place for non-OOP languages in the world.
>> You may be hoping to find for penguins at the North Pole.
Hmm... well, I guess it looks like a penguin... kinda, sorta. Um, it's a little bit small, but it does have flippers, a beak, and likes to hang out in the freezer - oh, and it's got this funny birthmark on it's belly, looks kinda' like the letters "mcc". And, uh... ya' know, I've always been interested in the north pole... wadda' ya think? Think I should bring him along on an expedition? You know, um, after I get done down here with this current one to the continent of "SX-Land"?
The instruction set and the amount of available cog ram are two diffrent issues. There's nothing wrong with the instruction set; actually, it's quite nice. A good optimiser could generate quite good code for it.
As for the ram issue - yes, it is a bit constrained.
And as for why there are really good optimisers for x86 code - well, it's been around for 28 years, and IA32 for 21 years!
It all comes down to a matter of development·efficiency.· If I already have embedded applications on other hardware that I've already written in C, it is far faster to port from one C run time environment to another than it is to port it to an entirely different language.·
The ease of programming in SPIN is subjective.· I've been programming in C for 18 years.· I've been programming in SPIN for about 4 days.· SPIN is straight forward, but given my ability to write C code, I'm more efficient writing in C than I am in SPIN at this time.
We're talking about a tool.· Sometimes the right tool for the job is a C compiler.· I'm sure that sometimes the right tool for the job is the SPIN interpreter.· It depends on what you are doing.· Engineering is full of choices and compromises.· Having the right menu of tools available lets the developer pick the right tool for the job.·
>>And, you really need to have something that is quite close to the hardware as the Propeller is unlike any other hardware.
Commerical C compilers provide target specific function libraries that enable access to the hardware at the appropriate level of abstraction.· That's what makes them useful.· Many allow inline assembly if that's what you want/need.· The combination of target specific libraries and inline assembly allow you to accomplish any programming task you need.· That is, you can get as "close to the hardware" as you want or need.·
>>You really might do best to spend your $150 on learning to program the SX-28 in Assembly. Parallax's kit and Guenther's text made learning Assembly a joy.· That knowledge would be transferable to the PICs and the speed would be lickety-split.·
Programming in assembly is simply another tool we have available.· It has its place.· The decision to use assembly or not has nothing to do with my familiarity with it.· I've simply found that it's much more efficient to develop most of my software in a higher level language such as C.· There are times when specific optimizations need to be made, and in those cases, judicious use of assembly is the right way to go.·
Remember, you are always balancing a variety of factors when engineering a device.· It simply isn't true that there's a one size fits all language that will be the right tool to use all of the time.·
>>C may just be keeping you from really writing better code and most of microcontroller code is about interfacing and driving hardware in a tight space.
Perhaps that what writing software is all about to you.· That's ok.··There's some joy in that.· However, it's more than that to me.· I derive more joy from making the device that I'm building actually work.· Spending countless hours optimizing the code is a means to the end.· It is not the end in and of itself.· Sometimes, it just makes sense to pay the difference and buy the microcontroller with a little more RAM. :-)
And that's why having a C compiler makes perfect sense to me.· If SPIN takes over the universe, it will make having a C compiler less compelling moving forward.· Until then, I want my options.
Joel-
Well, if soon is < 1 yr, yeah... mcc is currently still firmly in the "hobby project" category, I'm afraid... and I'm still working on the SX version. But, I really like the prop, so...
__________________________________________________________________________________________
>> Having the right menu of tools available lets the developer pick the right tool for the job
I couldn't agree more.
I just ran this thru mcc...
foo(byte a, byte b, byte c) { if(a>5) { return a+b; } { return b+c; }; };and got this back:
_foo: mov w,#0x20; add FSR,w; forg 0x10; __a: ds; mov w,0x08; mov __a,w; __b: ds; mov w,0x09; mov __b,w; __c: ds; mov w,0x0a; mov __c,w; mov w,#0x05; mov 0x1f,w; mov w,__a; sub w,0x1f; page @___else01; sc; jmp @___else01; mov w,__a; add w,__b; mov 0x08,w; mov w,#0x20; sub FSR,w; ret; page @___endif01; jmp @___endif01; ___else01: equ @; mov w,__b; add w,__c; mov 0x08,w; mov w,#0x20; sub FSR,w; ret; ___endif01: equ @; clr 0x08; mov w,#0x20; sub FSR,w; ret;Now, you're gonna' have to work real hard to persuade me that you can code that in assembler faster than I can in mcc - and for a real function; it only gets more severe...
What ever language YOU are productive in, and can get the job done, is the "best" language for YOU.
But I must comment on hammerhead74000, in your last post you disprove your own point.
Just look at all that code that is generated just to add two bytes depending on if another byte is > 5.
You are looking at the very ineffecient output of the C compiler and saying "It would take forever to write this simple code in assembly", well it wouldn't if a·human wrote it in·assembly.
It would look something like this:
Foo: MOV W,#-5 ADD W,byteA MOV W,byteA SC MOV W,byteC ADD W,byteB RETW·Again, if C works for you, then it IS the best language for you. But your not helping your case by showing the compiler output.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
Post Edited (Bean (Hitt Consulting)) : 8/28/2006 12:19:36 PM GMT
relatively inefficient code generation for tasks that are relatively straightforward, yet small enough to fit, where speed
compared to SPIN is important. Unfortunately, the cog memory is too small for any significant task where speed and/or
exacting timing control is important when using a high level language and compiler. If the cogs had maybe 4K longs of
memory, we wouldn't be having this discussion. There would be a large number of tasks that would be very amenable
to compiler-generated code and some minor use of in-line assembly would significantly help the rest. There would be a
clear market for a decent compiler for several languages and you would be seeing them. 512 x 32bit words is at a point
where hand-coded assembly language is necessary for most tasks that can't be done in SPIN. Look at most of the objects
done in assembly like the VGA drivers, floating point, servo drivers, full-duplex serial. None of those could have been done
in a high level language given the hardware resources available. I think a C to SPIN compiler might be a better first step
than trying to do C to native instructions. It bypasses the need to have the (currently) proprietary SPIN interpretive code
or doing a whole new interpreter that's not ROM resident and SPIN is really fast enough for a lot of I/O.
Propeller Assembly is really not as hard as you are setting out to make it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 8/28/2006 4:28:38 PM GMT
What, no curly brackets, plus signs, greater than, parenthesis and semicolons....
TOO EASY Mr. Schwabe!!
That said, SX/B, Spin, and the like are wonderful tools, and I love them all.
-dave
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
This is not a sig. This is a duck. Quack.
You are right, there is no "one true language"; each language lends itself differently to each problem space, and user preference and experience must be taken into account.
What you wrote, while nice and tight, is not equivalent to what mcc output. Also, mcc does not yet have an optimizer on the back-end, and you have taken a few optimizations that while valid for this specific code fragment, are not valid in the general case (but, of course, that's what the - currently missing - optimizer does, and would do for this code fragment: finds specific shortcuts and applies them only as appropriate).
>> Just look at all that code that is generated just to add two bytes depending on if another byte is > 5.
No, no - you misunderstand. It's not that you can't code something that runs faster... it's that I'm saying that to code something equivalent in assembler is usually more work for the programmer.
But, just for general info to the forum, here's what mcc is doing, that your example isn't:
A few other things that the optimiser would drop include:
Beau -
>> Propeller Assembly is really not as hard as you are setting out to make it.
No, prop assebler is actually quite nice. The SX example is a bit bulky, because of all the extra stuff it's doing - but your example only covers the if/compare/add section; not the function prolog/stack-frame/return stuff. Also, if your example were broken up the way that the SX does, it would be about the same length as Bean's...
There is also a readability advantage to languages like C (or Spin, etc); seeing expressions in "standard" format, with proper block-structure indentation, makes figuring out what's going on much easier when first looking at the code (or, when going back to it after a while).
pwssr - real men use !@#$*(){}!!! punctuation!
Existing Basic Stamp customers would probably like to see BASIC as the basis for the Propeller and PIC programmers C.·Looking at SPIN for me what hurts the most in productivity is the operators syntax.
At first glance using BASIC as the starting point would make the most sense since it picks up the existing Stamp customers as well as simplifying the modification of Stamp code to work with the Propeller. Plus I think a majority of programmers have at one point or another been exposed to BASIC.
All this is really moot since SPIN is what it is.·Usually confusion behind things is due to lack of knowlege about the reasons·behind the decisions. What I'd·be interested is·a response from the SPIN designers or someone in the know as to·the reasons why the syntax (again mainly flow control and operators) was chosen.
Variables, how they are held, size limitations, etc.
Conditionals and loops
Program flow
And where supported, passing variables by value and reference
I learned BASIC on an original Apple, re-inforced on a commodore PET (4k!), and taught myself 6402 assembler. The assembler really showed me how the high level level languages need to manage the operations, and made them make more sense to me.
I think, as Bean points out, one of the biggest problems going from anyother language to Spin, or trying to interpret spin, is going to be all the specialized operators. That nearly requires memorization as opposed to seeing a block code and having a gut understanding of what it does.
I never used the SX in my teaching. Students needed to see what was generally used in industry, which is C. The SX's C compiler was a tad much for my taste, and the chip itself has those odd virtual peripherals which also made it unique in industry, so I stuck to AVR's or others.
With the Propeller, the biggest benefit is that there is so little hardware, we can get into the programming much faster. And since they have to code their own peripherals, it will better re-inforce how those peripherals do their job. With ASM, we can deal with all those fun op-codes and conditionals.
As long as a language has the basic elements, I think students can grasp other languages. We turn out so few embedded engineers, I'm hoping it's not a big issue. But they may be one of the 1st classes being taught a multi-core controller, which could be to their benefit too! Though I will spend a couple weeks discussing such mundane things as stacks, interrupts, and internal hardware for those not lucky enough to get a job in a non-Propeller devlopement house.
As for myself, a language is simply a set of tools. I know what I need the program to do - I picture the flow and operations needed in my head - it's just picking out the right coding operations to make it happen. As long as the toolset contains the standards I need, I'll get it to work (I hope? [noparse]:)[/noparse] )
Speaking of which, I haven't dug out the references, but it struck me the other day Spin has a pre-test conditional loop (Repeat While) but no post-test condition loop (Loop while..). Forced me to test prior to entering a loop, but maybe I just overlooked it.
-Martin
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Martin Hebel
Southern Illinois University Carbondale - Electronic Systems Technologies
Personal Links with plenty of BASIC Stamp info
StampPlot - Graphical Data Acquisition and Control
You can do post-test conditional loops like this:
REPEAT
· <code here>
UNTIL somecondition
--or--
REPEAT
· <code here>
WHILE somecondition
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Thought I had tried that (being the natural structure) but UNTIL didn't turn colors on me or some such, so I did it the hardway. Probably just my goof though.
-Martin