C++ on a prop
4x5n
Posts: 745
I hope this doesn't turn into a flame war about C++, C, Spin, Interupts, etc but I've got a question about C++ on the prop.
I only have a little experience with C++ and never did any machine control work with it. What I'm wondering about is the real world usefullness of C++ on a machine with the limited memory of a propeller. I understand using C and even C++ used in a C like way but I don't understand the use of classes, overloading, and inheratence on a prop. I understand the advantages of all the C++ bells and whistles on a machine with substantial hardware resources.
I'm just wondering if anyone has done anything on the prop with more "advanced" functionality of C++ and what the size of the executable was and if it provides any significant advantages over C.
I only have a little experience with C++ and never did any machine control work with it. What I'm wondering about is the real world usefullness of C++ on a machine with the limited memory of a propeller. I understand using C and even C++ used in a C like way but I don't understand the use of classes, overloading, and inheratence on a prop. I understand the advantages of all the C++ bells and whistles on a machine with substantial hardware resources.
I'm just wondering if anyone has done anything on the prop with more "advanced" functionality of C++ and what the size of the executable was and if it provides any significant advantages over C.
Comments
You need XMMC for any real C++ code.
Thanks,
I'd post a link but searching from this phone is tough. It was probably on a Zog thread.
All in all C++ is quite suitable for small systems. After all it is what the Arduino is programmed in.
Thanks, I'll look for it. I have no doubt that C++ would be usable on the prop. I'm just wondering about the usefulness of things like overloading, inheritance, etc.
I'm asking because I'm rapidly getting to a point with a project that spin and the 32K limit is becoming an issue and I'm trying to figure a way out of it. I'm not having issues with speed and in fact most of the time spent in various delays. What I need is more than 32K of spin. I've been thinking of paging pasm routines in and out of hub ram but am thinking that C or C++ running out of an SD card might be a better choice. It's been a long time since I've done anything significant in C or C++ (a lot of C and very little C++) in a decade and either way I'll be on a relearn curve. With the object oriented nature of having 8 cogs each running their own thing my thought was that C++ might be a better choice in the long run. As I'm sure every one can understand I don't want to put a lot of time and effort into going down the wrong road and than have to go back.
Operator overloading might be useful but cause problems. For example a simple harmless looking "+" could well end up involving a huge amount of code, when it is over ridden there is no limit to what you can put in its redefinition. Soon you may find yourself forgetting what is actualy behind that little "+" and your program starts to bloat out.
Classes can be used to effect just like objects in Spin.
Dynamically creating instances on the stack or heap may be a bit heavy weight. Wanting to use inheritance may be over the top.
Your Spin code might be a good candidate for translating to C/C++. You can find the program to do that being discussed here recently.
With that said, What I think much of this is about has three goals:
1. giving the thousands of engineers and programmers who are currently comfortable with C & C++ an easy migration path to the Parallax "Family" of processors.
2. opening up the cornucopia of resources currently available in C & C++ libraries.
but most importantly:
3. Giving Prop users a tool that will allow us to take full advantage of the horsepower that the Prop II will unleash for us.
That "Family" is so far a family of 1, but with the introduction of the "Turboprop" in the next decade or two ( Sorry Parallax, I know you're peddling as fast as you can) we are going to need a language that has been proven capable of handling multi-tasking, multi-processing, and thank God-almighty (free at last) will let us get away from Windows if we want to. I'm not a Linux guru because most of my engineering applications are tied to Windows, but I see the bright shadows on the horizon of a Linux (like) operating system that will provide us the ability to have all our tools and tricks neatly packaged in a few terabytes that we carry with us on our prop-phones, communicate with our hardware through wireless com functions created with a trace on a circuit board, a couple of discrete components and some clever programming, and as the geometries continue to shrink, will be able to easily take advantage of the 16,32,64 etc, processors and multi-terabytes of memory available to us over time.
The PROP is hardly the correct engine for C++ with "overloading, inheritance, bells-and-whistles" etc... but you can bet your sweet bippy that a Prop II hooked into a 10$ 500 gig SD card is gonna be.
I love Spin and have gotten reasonably capable in Propeller Assembly, I hate the idea of having to learn to program in C++ all over again... it's been a while... but I applaud Parallax and the guys who have developed these tools for us for understanding where that "Long and winding" road is leading us back to.
Ken
While I'm not fond of the blocking by indentation used by spin it is well suited for the propeller!
I'm still trying to decide if it would be better in the long run to go with C or C++ on the propeller. The idea of using constructors launch an object into a cog is appealing. My problem is that all the references on C++ are geared towards application development on general purpose computers (unix and windows) not embedded applications like I'm looking to do with the propeller.
Not quite all. Have you noticed that the Arduino is programmed in C++?. They are sneaky and wrap it up in "sketches", they never refer to "C++" and their documentation only presents a simple subset of C++. How small a system could you want for C++?
The only difference is that Spin has some specializations and many limits that make it easier (in most cases).
C++ is powerful. We all know of course that with great power comes great responsibility. It is up to the user to exercise good judgement. C++ in the right hands is fine.
This is my opinion, and I'm sure someone else will have a different opinion (which is fine by me). C/C++ are necessary on Propeller so that Parallax can maintain an education market relevance. PBASIC has been accepted for many years, but is being phased out because of educational goal standardization (and the availability/use of that Arduino alternative). SPIN will go the same way. Without an educational market position, Parallax will vanish.
The give away is Arduino code examples like this:
If you are already running out of hub RAM with Spin the C++ code will definately need to be compiled in XMMC mode. You'll need to run from EEPROM or an SD card, or maybe you can add a flash chip to your hardware platform.
You can continue to program in Spin, and use spin2cpp every time you rebuild. Or you can switch over to programming in C++ using the output from spin2cpp as your starting point.
The other more advanced features I think you simply have to decide... "do I actually need that" bad enough to outweigh the hit you take in using it? The answer is probably "not really".
Thanks Dave. The newest version of spin2cpp (0.95) is checked in to Google Code at http://code.google.com/p/spin2cpp, so that's probably the best one to use.
I will warn that spin2cpp doesn't always produce "colloquial" C++, because the only data type supported by Spin is 32 bit integers. But that may not matter for many purposes.
Eric
This has been mentioned several times by different people already. I'd like to question one point: operator overloading. I don't think it will increase the size or adversely affect the speed at all. An overloaded operator is merely the chance to change "obj1.add(obj2)" into "obj1 + obj2" in the syntax. I haven't tried it out and compared the sizes though.
Yes, that is true. If you really have to do the work involved in that "add" function call then it does not matter if you implement it is a function "add" or an overload of "+".
(Thinks...Except possibly that the code for "+" might get put in line at every usage whereas the "add" methods might be just a call to "add" at each usage. I have to experiment a bit with that)
Anyway, the point I was making earlier is that you might, for example, grab some code for a class from me and then when writing your application that uses "+" on my objects think it is is pretty harmless. Could be though that my "+" overload method is a huge and/or slow piece of work. At which point your program balloons out in time and space when you were not expecting it to.
I have to admit I've never felt comfortable with overloading. To easy to make a mistake. I have to write all the functions anyhow so in my never humble opinion it's better to use different names for each to make it clear which "version" I'm using. The overloading of operators being the most problematic! You mileage may vary.
I pretty well agree with Heater. For simple stuff its probably ok but I have seen, just as he mentions, situations where obj3 = obj1 + obj2 implies a mountain of code that it might not be obvious is about to be drug in to allow for that. Like I said further along you just have to use some care. It's not like an operator+ with 4 lines of code is any worse than four lines in ::add(object2). But "properly" abstracting everything like the books for PC programming love to delve into is probably not really a great plan on 32KB device.
Really the bigger issue is do you have to be able to do obj3 = obj1 + obj2? If the mountain of code is required then it's required but in these environments its good to strongly question mountains of code and ask if that can be handled another way, even if it isn't "proper" OOP practice.
I'm looking to do this sort of thing too. I've been distracted the last two months getting some propeller hardware designs worked out but I'm now at a stage of being able to look again at software. I got a lot of simple test working and certainly C++ works well with huge programs and caching off an sd card.
A couple of times I added in some objects and added a few hundred kb to the compiled code. It was nice to know that it didn't really matter and the only downside to that is the download times.
One thing I'd like to push further is the idea of objects that can load and reload cogs many times. You can do that in spin up to a point, in that you can reload the pasm part but every time you add an object there is the overhead of the spin part which fills up the hub. With huge C programs it should be possible in theory to add every object in the obex into your code and load the pasm part in and out of cogs as needed.
The "advanced" parts of C should work. It would be interesting to think of some simple demo programs.
Are you using BST or any of the Spin compilers that will toss out unused code? The standard Spin compiler does no optimization whatsoever, for either size or speed, so it's quite possible to gain space back if you're using Obex objects that haven't been "stripped down" for your application.
Also, small things like using the constant() directive, can save a decent amount of space / time too. I've saved significant amounts of code space and execution time by making relatively minor changes.
Here we have a simple C++ program showing a class with set() and get() methods being used from main()
#include <stdio.h> #include <stdlib.h> class AClass { public: int get(); void set(int data); private: int data1; int data2; }; void AClass::set(int data) { data1 = data; data2 = data1 % 10; } int AClass::get() { return (data2); } AClass a; int main (int argc, char* argv[]) { a.set(rand()); return (a.get()); }Here we have a C equivalent of the above C++, the class is replaced by a C struct.The get() and set() functions now have a pointer parameter to select which struct instance to operate on.
#include <stdio.h> #include <stdlib.h> typedef struct AClass { int data1; int data2; } AClass_t; void set(AClass_t* ptr, int data) { ptr->data1 = data; ptr->data2 = ptr->data1 % 10; } int get(AClass_t* ptr) { return (ptr->data2); } AClass_t a; int main (int argc, char* argv[]) { set(&a, rand()); return get(&a); }Now it turns out there is no overhead over C in using C++ classes to implement this kind of thing.
In fact amazingly the generated code is identical!! Just try it in propgcc with or with out optimizations.
You will agree that the C++ code is much easier on the eyes.
I'm not sure why Kye implies this kind of usage is not "real C++".
It is, and it helps keep things orderly and clean.
I believe what Kye meant is that the typical C++ bloat that comes from "application" programming will require some form of XMM.