I'd love to have C++ for P2. Think memory and speed are enough to support it, right?
Well, PropGCC works pretty well with P1 so I don't see why it wouldn't work even better with P2. Whether it makes sense to build on the GCC-based PropGCC or switch to LLVM is an open question. I guess it depends on the skills of the person or team that takes on the project.
C++ need not require any more speed or memory than C. Provided one stays away from bloaty things like the standard library, which one does not need much on embedded systems. Exceptions and virtual methods are out too.
Remember, the Arduino is programmed in C++ and that is tiny and slow.
C++ need not require any more speed or memory than C. Provided one stays away from bloaty things like the standard library, which one does not need much on embedded systems. Exceptions and virtual methods are out too.
Remember, the Arduino is programmed in C++ and that is tiny and slow.
Why do you say that virtual methods are out? I think I've used them on the Propeller. In fact, I'm sure the Arduino uses them.
Not sure really. Just a guess on the basis that virtual method tables are needed. Aren't they? Perhaps it's not a big deal. I have never looked at the generated code for such things.
Where as I did find out that GCC generates byte for byte exactly the same code for using simple classes and object instances in C++ and the same in C passing object pointers to structures by hand. I was amazed that it was identical.
Not sure really. Just a guess on the basis that virtual method tables are need. Aren't they? Perhaps it's not a big deal. I have never looked at the generated code for such things.
Where as I did find out that GCC generates byte for byte exactly the same code for using simple classes and object instances in C++ and the same in C passing object pointers to structures by hand. I was amazed that it was identical.
Each class needs a single vtable which is pointed to by every class instance. I guess that could take up a significant amount of space if the classes have lots of methods but for a handful it shouldn't be too bad. Each method just requires a pointer to the code that implements the method.
Not sure really. Just a guess on the basis that virtual method tables are need. Aren't they? Perhaps it's not a big deal. I have never looked at the generated code for such things.
Where as I did find out that GCC generates byte for byte exactly the same code for using simple classes and object instances in C++ and the same in C passing object pointers to structures by hand. I was amazed that it was identical.
Each class needs a single vtable which is pointed to by every class instance. I guess that could take up a significant amount of space if the classes have lots of methods but for a handful it shouldn't be too bad. Each method just requires a pointer to the code that implements the method.
In thinking about it a bit more I think I now understand what you meant by staying away from virtual functions. If you have a class with lots of virtual functions many of which are not used by your code, I don't think the linker can eliminate them because of the references to them in the vtable. This may be the problem.
Phil, the Arduino has proven that C++ can be taught to novices as long as they focus on a small subset of the language, and a framework is provided that shields them from the more complex features of the language. Spin does have some nice features. Since it is a limited language, a novice can become proficient in Spin in a few months. The tight integration between Spin and PASM is also a nice feature. The biggest concern I have about Spin is that it is only used on the Prop. Students that learn Spin will not be able to program in the same language on other platforms. On the other hand, C is available for almost every processor.
Not sure really. Just a guess on the basis that virtual method tables are need. Aren't they? Perhaps it's not a big deal. I have never looked at the generated code for such things.
Where as I did find out that GCC generates byte for byte exactly the same code for using simple classes and object instances in C++ and the same in C passing object pointers to structures by hand. I was amazed that it was identical.
Each class needs a single vtable which is pointed to by every class instance. I guess that could take up a significant amount of space if the classes have lots of methods but for a handful it shouldn't be too bad. Each method just requires a pointer to the code that implements the method.
In thinking about it a bit more I think I now understand what you meant by staying away from virtual functions. If you have a class with lots of virtual functions many of which are not used by your code, I don't think the linker can eliminate them because of the references to them in the vtable. This may be the problem.
That's exactly it. I had to find this out the hard way with PropWare. Virtual functions are fantastic and allow for the whole concept of "interfaces"... but anything virtual can't be pruned by the linker.
So it means library designers need to be very careful not to mark methods unnecessarily as virtual. For me, that means marking the bare minimum, but I do use it. For instance, my UART classes inherit from an interface that provides the "put_char()" method. I figure this is pretty safe, because it's quite rare that someone would use a UART object without wanting to send a single character (though there is a separate method for transmitting an array, so it's possible someone might never want "put_char()").
As for standard library and exceptions... I'm dying to finally have access to that! It's going to be great! With 512kB of program space, that's PLENTY. It won't hold the whole thing, but it'll be a lot better. Already we have enough space for basic usage of std::vector and some other simple stuff. And I think basic usage of exceptions was only in the 10s of kB (I won't swear to it though... been a couple years since I checked).
Still be nice to have something like PropString, PropFile, etc. to make things easier...
If Parallax agree, I'll do what I can to make that happen. That's been my dream as well. (Though I do hope we have space for std::string on Prop2)
What are you wondering about regarding agreement from Parallax?
Inclusion into (or replacement of) the Simple libraries. Users of the Propeller will, by and large, only use what Parallax advertise. So Parallax needs to agree to be willing to advertise a C++ library.
Students that learn Spin will not be able to program in the same language on other platforms. On the other hand, C is available for almost every processor.
I guess it depends upon how you view secondary education. If you see it as purely vocational, then your argument has validity. But I prefer to think of it in more academic, liberal arts terms: that the programming skills learned from working with Spin transfer to other languages that the students will encounter in college or, later, in the workplace. My main objective in teaching programming is to get the kids thinking in algorithmic terms with as few syntactical speed bumps along the way as possible. And it has to be fun for them as well. IMO, Spin makes these objectives easier to accomplish than would other languages I've worked with.
Students that learn Spin will not be able to program in the same language on other platforms. On the other hand, C is available for almost every processor.
I guess it depends upon how you view secondary education. If you see it as purely vocational, then your argument has validity. But I prefer to think of it in more academic, liberal arts terms: that the programming skills learned from working with Spin transfer to other languages that the students will encounter in college or, later, in the workplace. My main objective in teaching programming is to get the kids thinking in algorithmic terms with as few syntactical speed bumps along the way as possible. And it has to be fun for them as well. IMO, Spin makes these objectives easier to accomplish than would other languages I've worked with.
-Phil
The age of the audience I think plays in big. For your average kid middle-school or younger, I would say Spin almost every time. High-school is a bit muddied. For college, I would say C/C++ 100% of the time. By college, they are old enough to grasp C and C++ and most likely need (or will benefit from, even if they don't need) the experience for industry.
Not sure really. Just a guess on the basis that virtual method tables are needed. Aren't they? Perhaps it's not a big deal. I have never looked at the generated code for such things.
Where as I did find out that GCC generates byte for byte exactly the same code for using simple classes and object instances in C++ and the same in C passing object pointers to structures by hand. I was amazed that it was identical.
A virtual method is just a pointer indirection. If you mark *everything* as virtual, yes it'd be wasteful and could lead to the linker not being able to prune unused code, but virtual methods themselves are no worse than a manually implemented function pointer, and they're easier to read.
C++ compilers have gotten VERY good at optimizing code. Initially they were a fair bit worse because most compilers were C based, and C++ compilers were new, but now it's other way around - Most compilers are C++ native, and just compile straight C as a subset. You should look up "Whole Program Optimization" and "Link Time Code Generation". Those are fun.
"Whole Program Optimization" and "Link Time Code Generation". Those are fun.
I try to keep an eye on such things. It's amazing what a compiler can do. All over my head of course.
It's also amazing how easily ones source code can break all optimizations with simple changes and leave you with really inefficient executables. Ask Chandler Carruth, an optimizer guru on the Clang/LLVM team.
It's kind of hard to know if the code you are writing will be optimized well or not at all.
If anybody complains about the performance part we might look at that later...
One point that Chandler Carruth makes is that such code styles that defeat optimizers cannot really be found with a profiler. They infect the whole program and slow everything down. Makes it hard to find the "hot spot".
Sorry, I can't link you to his argument, it's buried in YouTube videos somewhere.
I have been fighting with this in Verilog recently. Change the code in what looks like harmless ways and all of a sudden it requires 100 times more logic blocks to implement in your FPGA. At least with C/C++ I have some idea what instructions it needs to generate. I really don't have a feel for the Verilog to logic gate mapping yet.
Heater,
I am familiar with Chandler Carruth and his talks. I am also familiar with code styles causing whole program sluggishness.
For example, the whole smart/weak/ref pointer (or combination there of) thing. Some coders use them everywhere and for everything. They are the bane of my existence right now. Extra indirection happening everywhere, accessing disparate memory causing cache thrash. If coders would just learn how to use regular old pointers properly, we'd never need this Smile. They are just lazy and use the "safe" pointers where they don't have to worry about lifetime or ownership. Same thing goes for using STL containers for small quantities of things. There seems to be an aversion to just using regular old arrays. Let's use a std::map to hold 3 items (max ever), and always just linear walk the map. Or let's use a doubly linked list to hole 2 items. Or let's use a dynamic array to hold something that is ALWAYS a fixed size.
I blame academia for all this Smile, teaching that one should ways use the bloated, over engineered, forms of things instead of the simple built in to the language features.
In my day job, I live in a blissful world where performance is of absolutely no concern whatsoever (henceforth why we use Java). It is stressed many times that code legibility is far more important performance. We also stress the point that one should not pre-optimize their code - just like you and Heater were saying above.
That being said, I find it very interesting that you're bothered by overuse of STL containers. Seems like doing anything other than defaulting to the STL containers is counter-productive. Now, obviously there are always exceptions. If performance was considered a possible concern, then the necessary tests should have been run to determine if something more efficient was needed. But you seem to be promoting the use of built-in types first and by default, and only STL containers when necessary.
My issue is when something is of a known fixed size, and doesn't need any special lookup/access features, then using a standard C array is usually better in pretty much every way.
Also, just to get your brain more frazzled, since we care about performance where I work, we avoid STL like the plague. Also, until recently, using STL meant incompatibilities depending on platform (think game consoles).
STL is a bloated mess, and it's performance is notoriously bad. You'll find that most places that care about performance (like game dev) don't use it. Where I work we have out own set of very performance conscious containers and utility templates/classes/etc. We have done comparisons against STL and are often at least an order of magnitude (if not several) faster. A lot of it boils down the memory allocations.
Even still our dynamic array or linked list container for a small fixed set of stuff (think 2-10) is almost always wasted memory and overhead. It's especially bad it you need to have optimal cache coherency in you data, since the dynamic containers will typically have your data all over the place in memory.
There are correct places to use STL (or STL like) containers and what not, and we use them a lot for those cases.
The age of the audience I think plays in big. For your average kid middle-school or younger, I would say Spin almost every time. High-school is a bit muddied.
I don't disagree. Some of my HS students had never done any programming. When I was in college, I had never done any programming, either, and the first language I had to learn was Fortran. It was a total struggle, due to many syntactical obscurities. Let's look at Fortran's looping and print structures, for example:
DO 9, I = 1, 15, 2
WRITE (6,8) I
8 FORMAT( I2 )
9 CONTINUE
Ugh. 'Not completely obvious what that means! But then BASIC came along:
20 FOR I = 1 TO 15 STEP 2
30 PRINT I
40 NEXT I
Now, that's easy to read. It says what it means and means what it says.
Fast forward 50 years from 1967 to 2017. It's the same story all over again. In C, we're looking at:
for (int i = 1; i <= 15; i += 2) {
printf("%i\n", i);
}
What does all that syntactical gobbledegook say to a novice programmer? In Spin,
repeat i from 1 to 15 step 2
sio.dec(i)
sio.char(CR)
To me, this seems much easier to explain, although the sio object will require a little 'splainin' -- but not as much as printf. Nonetheless, as a teacher teaching Spin, I can move on to other topics more quickly.
Introducing C programming to non-programmers seems almost cruel by comparison. But, again, I'm not criticizing Parallax for the direction they took in their Learn program. They had to take that route as a business decision. It's the school systems that need educating about their roles as vocational vs. academic learning centers. They really have to divorce themselves from knee-jerk buzzwords and take a closer look at the costs versus benefits of teaching the various available computer languages.
And yet everyday people that are totally new to programming get introduced to the Arduino and start programming in C++ easily enough.
Or their first programming experience is Javascript which has similar syntactic constructs.
I think if I were introducing a non-programmer to programming in C I would make it a bit simpler for them to start with:
int i;
for (i = 1; i <= 15; i = i + 2)
print(i);
Admittedly that does not compete with the simplicity of a repeat in Spin or a BASIC FOR loop but moving the declaration if "i" out of the loop and avoiding "+?" makes it look a bit less like line noise.
And yet everyday people that are totally new to programming get introduced to the Arduino and start programming in C++ easily enough.
Or their first programming experience is Javascript which has similar syntactic constructs.
I think if I were introducing a non-programmer to programming in C I would make it a bit simpler for them to start with:
int i;
for (i = 1; i <= 15; i = i + 2)
print(i);
Admittedly that does not compete with the simplicity of a repeat in Spin or a BASIC FOR loop but moving the declaration if "i" out of the loop and avoiding "+?" makes it look a bit less like line noise.
Or introduce it like this and then introduce the for statement later as a shorthand.
int i = 1;
while (i <= 15) {
print(i);
i = i + 2;
}
My issue is when something is of a known fixed size, and doesn't need any special lookup/access features, then using a standard C array is usually better in pretty much every way.
Also, just to get your brain more frazzled, since we care about performance where I work, we avoid STL like the plague. Also, until recently, using STL meant incompatibilities depending on platform (think game consoles).
STL is a bloated mess, and it's performance is notoriously bad. You'll find that most places that care about performance (like game dev) don't use it. Where I work we have out own set of very performance conscious containers and utility templates/classes/etc. We have done comparisons against STL and are often at least an order of magnitude (if not several) faster. A lot of it boils down the memory allocations.
Even still our dynamic array or linked list container for a small fixed set of stuff (think 2-10) is almost always wasted memory and overhead. It's especially bad it you need to have optimal cache coherency in you data, since the dynamic containers will typically have your data all over the place in memory.
There are correct places to use STL (or STL like) containers and what not, and we use them a lot for those cases.
Interesting issues, Roy. I didn't know STL was so bad. I will most certainly keep it in mind.
Comments
Seconded.
Runs for the door ...
Well, PropGCC works pretty well with P1 so I don't see why it wouldn't work even better with P2. Whether it makes sense to build on the GCC-based PropGCC or switch to LLVM is an open question. I guess it depends on the skills of the person or team that takes on the project.
Remember, the Arduino is programmed in C++ and that is tiny and slow.
Where as I did find out that GCC generates byte for byte exactly the same code for using simple classes and object instances in C++ and the same in C passing object pointers to structures by hand. I was amazed that it was identical.
That's exactly it. I had to find this out the hard way with PropWare. Virtual functions are fantastic and allow for the whole concept of "interfaces"... but anything virtual can't be pruned by the linker.
So it means library designers need to be very careful not to mark methods unnecessarily as virtual. For me, that means marking the bare minimum, but I do use it. For instance, my UART classes inherit from an interface that provides the "put_char()" method. I figure this is pretty safe, because it's quite rare that someone would use a UART object without wanting to send a single character (though there is a separate method for transmitting an array, so it's possible someone might never want "put_char()").
As for standard library and exceptions... I'm dying to finally have access to that! It's going to be great! With 512kB of program space, that's PLENTY. It won't hold the whole thing, but it'll be a lot better. Already we have enough space for basic usage of std::vector and some other simple stuff. And I think basic usage of exceptions was only in the 10s of kB (I won't swear to it though... been a couple years since I checked).
But, I'll be happy with regular C++
Still be nice to have something like PropString, PropFile, etc. to make things easier...
If Parallax agree, I'll do what I can to make that happen. That's been my dream as well. (Though I do hope we have space for std::string on Prop2)
What are you wondering about regarding agreement from Parallax?
Inclusion into (or replacement of) the Simple libraries. Users of the Propeller will, by and large, only use what Parallax advertise. So Parallax needs to agree to be willing to advertise a C++ library.
-Phil
The age of the audience I think plays in big. For your average kid middle-school or younger, I would say Spin almost every time. High-school is a bit muddied. For college, I would say C/C++ 100% of the time. By college, they are old enough to grasp C and C++ and most likely need (or will benefit from, even if they don't need) the experience for industry.
A virtual method is just a pointer indirection. If you mark *everything* as virtual, yes it'd be wasteful and could lead to the linker not being able to prune unused code, but virtual methods themselves are no worse than a manually implemented function pointer, and they're easier to read.
C++ compilers have gotten VERY good at optimizing code. Initially they were a fair bit worse because most compilers were C based, and C++ compilers were new, but now it's other way around - Most compilers are C++ native, and just compile straight C as a subset. You should look up "Whole Program Optimization" and "Link Time Code Generation". Those are fun.
It's also amazing how easily ones source code can break all optimizations with simple changes and leave you with really inefficient executables. Ask Chandler Carruth, an optimizer guru on the Clang/LLVM team.
It's kind of hard to know if the code you are writing will be optimized well or not at all.
That is why I make it work first. Then ship it.
If anybody complains about the performance part we might look at that later...
One point that Chandler Carruth makes is that such code styles that defeat optimizers cannot really be found with a profiler. They infect the whole program and slow everything down. Makes it hard to find the "hot spot".
Sorry, I can't link you to his argument, it's buried in YouTube videos somewhere.
I have been fighting with this in Verilog recently. Change the code in what looks like harmless ways and all of a sudden it requires 100 times more logic blocks to implement in your FPGA. At least with C/C++ I have some idea what instructions it needs to generate. I really don't have a feel for the Verilog to logic gate mapping yet.
I am familiar with Chandler Carruth and his talks. I am also familiar with code styles causing whole program sluggishness.
For example, the whole smart/weak/ref pointer (or combination there of) thing. Some coders use them everywhere and for everything. They are the bane of my existence right now. Extra indirection happening everywhere, accessing disparate memory causing cache thrash. If coders would just learn how to use regular old pointers properly, we'd never need this Smile. They are just lazy and use the "safe" pointers where they don't have to worry about lifetime or ownership. Same thing goes for using STL containers for small quantities of things. There seems to be an aversion to just using regular old arrays. Let's use a std::map to hold 3 items (max ever), and always just linear walk the map. Or let's use a doubly linked list to hole 2 items. Or let's use a dynamic array to hold something that is ALWAYS a fixed size.
I blame academia for all this Smile, teaching that one should ways use the bloated, over engineered, forms of things instead of the simple built in to the language features.
In my day job, I live in a blissful world where performance is of absolutely no concern whatsoever (henceforth why we use Java). It is stressed many times that code legibility is far more important performance. We also stress the point that one should not pre-optimize their code - just like you and Heater were saying above.
That being said, I find it very interesting that you're bothered by overuse of STL containers. Seems like doing anything other than defaulting to the STL containers is counter-productive. Now, obviously there are always exceptions. If performance was considered a possible concern, then the necessary tests should have been run to determine if something more efficient was needed. But you seem to be promoting the use of built-in types first and by default, and only STL containers when necessary.
Did I get that right?
My issue is when something is of a known fixed size, and doesn't need any special lookup/access features, then using a standard C array is usually better in pretty much every way.
Also, just to get your brain more frazzled, since we care about performance where I work, we avoid STL like the plague. Also, until recently, using STL meant incompatibilities depending on platform (think game consoles).
STL is a bloated mess, and it's performance is notoriously bad. You'll find that most places that care about performance (like game dev) don't use it. Where I work we have out own set of very performance conscious containers and utility templates/classes/etc. We have done comparisons against STL and are often at least an order of magnitude (if not several) faster. A lot of it boils down the memory allocations.
Even still our dynamic array or linked list container for a small fixed set of stuff (think 2-10) is almost always wasted memory and overhead. It's especially bad it you need to have optimal cache coherency in you data, since the dynamic containers will typically have your data all over the place in memory.
There are correct places to use STL (or STL like) containers and what not, and we use them a lot for those cases.
DO 9, I = 1, 15, 2 WRITE (6,8) I 8 FORMAT( I2 ) 9 CONTINUEUgh. 'Not completely obvious what that means! But then BASIC came along:Now, that's easy to read. It says what it means and means what it says.
Fast forward 50 years from 1967 to 2017. It's the same story all over again. In C, we're looking at:
for (int i = 1; i <= 15; i += 2) { printf("%i\n", i); }What does all that syntactical gobbledegook say to a novice programmer? In Spin,To me, this seems much easier to explain, although the sio object will require a little 'splainin' -- but not as much as printf. Nonetheless, as a teacher teaching Spin, I can move on to other topics more quickly.
Introducing C programming to non-programmers seems almost cruel by comparison. But, again, I'm not criticizing Parallax for the direction they took in their Learn program. They had to take that route as a business decision. It's the school systems that need educating about their roles as vocational vs. academic learning centers. They really have to divorce themselves from knee-jerk buzzwords and take a closer look at the costs versus benefits of teaching the various available computer languages.
-Phil
Or their first programming experience is Javascript which has similar syntactic constructs.
I think if I were introducing a non-programmer to programming in C I would make it a bit simpler for them to start with:
Admittedly that does not compete with the simplicity of a repeat in Spin or a BASIC FOR loop but moving the declaration if "i" out of the loop and avoiding "+?" makes it look a bit less like line noise.
int i = 1; while (i <= 15) { print(i); i = i + 2; }Interesting issues, Roy. I didn't know STL was so bad. I will most certainly keep it in mind.