I will soon test out GCC for the Prop...
Ahle2
Posts: 1,179
C/C++ is my favourite language and I use it for everything I do outside of "propeller world".(even at work)
Initially I hated spin and how slow it was, but the unique features and powers of the propeller chip made me force myself to "like" it.
In my world spin is just usable for gluing high speeds pasm-objects together and maybe doing some low performance tasks and initializing of objects... etc..
That's the reason why 90% of my "Propeller work" is done in pasm with a very thin shell of spin-api.
I really LOVE pasm and how things can be "optimized beyond recognition" thanks to the good instruction set and the "conditional execution feature".
To be honest I havn't come across a single architecture which is so fun to code in assembler as the Propeller.
I have been coding in pasm for a long time (since 2007) and I do realize that making a C compiler that takes advantage of all the "tricks" that can be done when "hand coding" in pasm will be hard or even "impossible".
While other architectures can be coded in C and achieve almost more optimized code than if "hand optimized", I'm certain that GCC for the Propeller will not even come close.
The Propeller architecture is obviously not made with C or C++ in mind and I'm afraid that even GCC will mostly be used for gluing pasm-objects together. (even though it's many times faster than spin)
My goal is to eventually do all my "gluing" in C instead of spin, but for me it's a MUST to be able to do inline assembly.
For example, how do I incorperate my own pasm objects (SIDcog, Retronitus... etc..) into a game made in C++.
/Johannes
Initially I hated spin and how slow it was, but the unique features and powers of the propeller chip made me force myself to "like" it.
In my world spin is just usable for gluing high speeds pasm-objects together and maybe doing some low performance tasks and initializing of objects... etc..
That's the reason why 90% of my "Propeller work" is done in pasm with a very thin shell of spin-api.
I really LOVE pasm and how things can be "optimized beyond recognition" thanks to the good instruction set and the "conditional execution feature".
To be honest I havn't come across a single architecture which is so fun to code in assembler as the Propeller.
I have been coding in pasm for a long time (since 2007) and I do realize that making a C compiler that takes advantage of all the "tricks" that can be done when "hand coding" in pasm will be hard or even "impossible".
While other architectures can be coded in C and achieve almost more optimized code than if "hand optimized", I'm certain that GCC for the Propeller will not even come close.
The Propeller architecture is obviously not made with C or C++ in mind and I'm afraid that even GCC will mostly be used for gluing pasm-objects together. (even though it's many times faster than spin)
My goal is to eventually do all my "gluing" in C instead of spin, but for me it's a MUST to be able to do inline assembly.
For example, how do I incorperate my own pasm objects (SIDcog, Retronitus... etc..) into a game made in C++.
/Johannes
Comments
I haven't had a chance to give propgcc a try yet but I've read posts that it's almost as fast as pasm! At the very least it's faster then spin. I've currently got a project I'm working on in spin and it's close enough to being completed that I'm not going to switch to C or C++.
For what I'm trying to do with a propeller running at 80MHZ spin is more then fast enough for my needs. :-)
Aside from being able to write prop code in C I like the idea of being able to write code larger then 32K.
You might be surprised. GCC is fast enough to do real drivers, including VGA and full duplex serial (we already have examples of those). The compiler does take advantage of some of the architectural features like conditional execution. PASM code can still run faster than compiled C code, of course -- but C code is easier to write
There are a number of ways to link assembly code and C code:
(1) Inline assembly -- GCC has a pretty rich inline assembly feature, so you can mix assembly and C. This is intended for replacing inner loops of C functions and such, rather than actually writing whole drivers though.
(2) Separate assembly files -- you can write .s files which are assembled by GAS (the GNU assembler) and then linked with your C code. This is the easiest way to write PASM code to run in other cogs. The only downside to this is that GAS has slightly different syntax than PASM (only slightly, but it can sometimes mean that you have to modify your PASM code).
(3) Compile the spin code to a binary blob and then include that in the C code. There are examples of how to do this in the demos.
Eric
Then you can combine this with usual/unusual ways of using flags/conditional execution.
These kinds of optimizations are limited to be used in just rare occasions. There are literally thousands of potential optimizations like this and every situation needs to be handled differently.
Pasm has got some unusual but extremely powerful instructions... like for an example.. ADDABS, MOVI, MOVS, REV, SUMNZ, CMPSUB... to name a few. These can be used to do things in 1 instruction instead of a lot of instructions and are often used in combination with conditional execution in unusual ways to do unusual things.
I'm just saying that GCC will probably never be used to make optimtized video drivers or high performance sound synthesis running in a single cog.
It will however be a huge improvement over spin in both speed and performance and make a "C++ junkie" like myself very very very happy coding on my favorite microcontroller.
It will also make it easy to make large programs running in external memory, which is very welcome.
/Johannes
I'll write new COG code in C where possible mainly because it will be easier to maintain over time (extend, modify, be useful for others). The good news is that any COG code I write in C can be used by any language (C/C++, SPIN, xBasic, etc...) that understands the interface, so I consider it a good use of my time.
One PASM module I have that is a candidate for rewriting in C is an I2C driver that supports up to 5 different devices in one COG (Accelerometer, ADC, EEPROM, NES-Button scanner, and RTC). The NES button register clock is on the SCL pin, so it has to be either locked or in the same COG. Regardless I'm pretty sure it will all fit in a COG.
Sorry I haven't had time to participate these last few weeks. I'll be back home by New Years.
Happy Holidays!
--Steve
Sorry for the late chime in... busy....ill.....honey-doos......call......busier still..........
Steve's statement about "new where possible" seems the most reasonable approach. I am not a proponent of re-writing the whole OBEX in C "just because". An awful waste of time unless rewriting is a learning exercise where the purpose is to learn to create an identical function and then compare and understand the performance trade-offs. Which I am doing with a couple of objects since I am rusty as 7734 in the little C I learned and remember.
As to the debate of spin, pasm, C, etc. they all do the same thing ultimately. The big push for C is that most systems have C available, so if I can do it on ARM, PIC, Prop, X8xxx, or whatever, I only need to learn the hardware interface, I already know C. If I need speed, I can go to assembly, but then you would need to learn the whole instruction set rather than just the hardware specific parts. Rather do that only if I have to. (Personally I prefer pasm to spin)
I only found this chip in July, almost by accident, and I really like its huge potential. Prop II seeing is believing, so I really don't care or follow much of the speculation about it, but the C support needs to be there for its future. Parallax should really spend some money on getting the gang that did the REDBOX C and ecliipse environment for the NXP arm based chips to do the same for them. Make the environment able to be modified or extended to support spin, pasm, Catalina, GCC or custom C as the future reveals.