Compatibility with C++
Moderator: Stef
Compatibility with C++
The more I come along in my project, the more I realise it would be nice to have some object-orientation. Would SGDK work with C++? Has anyone ever used it with C++ before?
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
I do not provide C++ support currently as it adds some overhead compared to C. Depending your code you can keep it low but when you work on such limited system you want to avoid them as much as possible. Also i believe adding C++ support requires more than just adding g++ binary...
Still that is a possible addition and anyone who want to use C++ can add the G++ compiler. I would need to modify the headers (adding required extern "C" block everywhere) to make then compatible with C++ sources though.
Still that is a possible addition and anyone who want to use C++ can add the G++ compiler. I would need to modify the headers (adding required extern "C" block everywhere) to make then compatible with C++ sources though.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
My own personal toolchain supports C++ and comes with a C++ example. It's not as full featured as sgdk, but if you just have to use C++, you might give it a try. The catch is you have to build it yourself. I just show how to build the toolchain and provide things like linker scripts and such. Start by reading the thread.
viewtopic.php?t=889
viewtopic.php?t=889
My Linux build toolchain that I think you are using, Zontar, is based off of ChillyWilly's and should have c++ support already built.
I don't actually use C++ for Genesis development since it will be less efficient and lead to a larger file size, so I can't say how well this will work, but you ought to be able to link this with the SGDK archive.
You may need to wrap the headers with the 'extern "C"' syntax stuff. See: http://www.cplusplus.com/forum/general/1143/
There may be more fiddling required, but you should be close to setup already for this.
I don't actually use C++ for Genesis development since it will be less efficient and lead to a larger file size, so I can't say how well this will work, but you ought to be able to link this with the SGDK archive.
You may need to wrap the headers with the 'extern "C"' syntax stuff. See: http://www.cplusplus.com/forum/general/1143/
There may be more fiddling required, but you should be close to setup already for this.
-
- Very interested
- Posts: 58
- Joined: Tue Feb 25, 2014 3:38 pm
Building the toolchain with c++ support is also on my todo list.
Btw: Is building the gnu toolchain a lot of work? I never tried it and I really would like a new version of gcc, since the one provided with SGDK has a nasty bug that randomly stops compiling ("couldn't allocate heap" [...] "died waiting for longjmp") that IIRC only happens on x64 systems.
I am curious as to what you mean by that. Speed or size? Or both? Did you benchmark it, and if so what optimization flags did you use? I am wondering because when I coded a bit for the GBA, I tested some code in C and C++ and didn't find any overhead in execution speed for my code. The libraries also look as if they would compile without much changing.I do not provide C++ support currently as it adds some overhead compared to C.
Btw: Is building the gnu toolchain a lot of work? I never tried it and I really would like a new version of gcc, since the one provided with SGDK has a nasty bug that randomly stops compiling ("couldn't allocate heap" [...] "died waiting for longjmp") that IIRC only happens on x64 systems.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Well if you use the OO advantages of the C++ language (as inheritance) ans stuff like that, it would necessary add some overhead (vtable to fetch correct methods for instance). GBA already has a more powerful CPU so the overhead might be lighter also it depends a lot from your code, if you code in C with C++ of course it won't make any differences. Sometime also the compiler optimizations are different and you can even get better performance from the G++ compiler but with an older target as the m68k, generally older compilers outperform newer ones.Stef wrote: Building the toolchain with c++ support is also on my todo list.
...
I am curious as to what you mean by that. Speed or size? Or both? Did you benchmark it, and if so what optimization flags did you use? I am wondering because when I coded a bit for the GBA, I tested some code in C and C++ and didn't find any overhead in execution speed for my code. The libraries also look as if they would compile without much changing.
Compiling the toolchain can consume time, you have to take care about defining correct parameters and almost time you experience some issues during the compilation process... I know about the annoying bug, i also got it and it's true it would be nice to get rid of it. Something to know about newer GCC version, they do produce awful code for m68k target so i really recommend you to test them before fixing on a specific version (when i build the initial GCC version for SGDK i used 3 different version and the oldest one produced the best code).Btw: Is building the gnu toolchain a lot of work? I never tried it and I really would like a new version of gcc, since the one provided with SGDK has a nasty bug that randomly stops compiling ("couldn't allocate heap" [...] "died waiting for longjmp") that IIRC only happens on x64 systems.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Mostly size. These days, the gcc C++ compiler is nearly as fast as the C compiler, but the size is a bit of an issue. I'm not sure why exactly, but the optimizer has trouble removing unneeded library code, so even just adding the include for iostream adds ALL of iostream, or about half a megabyte to the size of the rom. If you look at my C++ example, compile it with and without the include for iostream and look at the difference in the output roms.twosixonetwo wrote:I am curious as to what you mean by that. Speed or size? Or both? Did you benchmark it, and if so what optimization flags did you use? I am wondering because when I coded a bit for the GBA, I tested some code in C and C++ and didn't find any overhead in execution speed for my code. The libraries also look as if they would compile without much changing.
It's super-easy in linux. I give step by step instructions in the thread. It's slightly more work in Windows since you need to setup CygWin or MinGW. If you aren't familiar with either, then you have the extra work of learning that before you can build the toolchain.Btw: Is building the gnu toolchain a lot of work? I never tried it and I really would like a new version of gcc, since the one provided with SGDK has a nasty bug that randomly stops compiling ("couldn't allocate heap" [...] "died waiting for longjmp") that IIRC only happens on x64 systems.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
The old compiler does produce faster code, but my opinion on that is if you NEED code that is faster than the new compiler can make, you should be using assembly language for that part instead of C in the first place.Stef wrote:Something to know about newer GCC version, they do produce awful code for m68k target so i really recommend you to test them before fixing on a specific version (when i build the initial GCC version for SGDK i used 3 different version and the oldest one produced the best code).
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
I think you're overplaying it. "Bad code" was what... 10% the last time someone did any tests? Hmm - maybe we should set up some tests to see what the value is at various optimization levels.Stef wrote:You have the point But still imo the latter GCC really produces bad code for m68k and SGDK performance is really impacted by that :-/
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
In my case it was really more than 10%, a demo running at 16 FPS with GCC 3.4.6 was running at 11 or 12 FPS with GCC 4.4.x... And that is, at comparable optimization level. Anyway, you can easily replace the defaults SGDK compilersChilly Willy wrote:I think you're overplaying it. "Bad code" was what... 10% the last time someone did any tests? Hmm - maybe we should set up some tests to see what the value is at various optimization levels.Stef wrote:You have the point But still imo the latter GCC really produces bad code for m68k and SGDK performance is really impacted by that :-/
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
So 25%... definitely time for another round of checks. I wonder if they've improved that any... or if it got worse.Stef wrote:In my case it was really more than 10%, a demo running at 16 FPS with GCC 3.4.6 was running at 11 or 12 FPS with GCC 4.4.x... And that is, at comparable optimization level. Anyway, you can easily replace the defaults SGDK compilersChilly Willy wrote:I think you're overplaying it. "Bad code" was what... 10% the last time someone did any tests? Hmm - maybe we should set up some tests to see what the value is at various optimization levels.Stef wrote:You have the point But still imo the latter GCC really produces bad code for m68k and SGDK performance is really impacted by that :-/