Compatibility with C++

SGDK only sub forum

Moderator: Stef

Zontar
Very interested
Posts: 55
Joined: Fri Oct 21, 2011 8:58 pm

Compatibility with C++

Post by Zontar » Sat Nov 15, 2014 10:44 pm

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?

Stef
Very interested
Posts: 3057
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Sun Nov 16, 2014 10:28 pm

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.

Chilly Willy
Very interested
Posts: 2854
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Sun Nov 16, 2014 10:39 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

kubilus1
Very interested
Posts: 237
Joined: Thu Aug 16, 2012 2:25 am
Contact:

Post by kubilus1 » Mon Nov 17, 2014 3:34 am

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.

twosixonetwo
Very interested
Posts: 58
Joined: Tue Feb 25, 2014 3:38 pm

Post by twosixonetwo » Mon Nov 17, 2014 12:15 pm

Building the toolchain with c++ support is also on my todo list.
I do not provide C++ support currently as it adds some overhead compared to C.
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.

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.

Stef
Very interested
Posts: 3057
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Nov 17, 2014 12:51 pm

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.
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.
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.
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).

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Mon Nov 17, 2014 1:31 pm

You don't need C++ to write object-oriented code.

Linux core writen in C (as far as I remember). And I don't think that FILE - is not object.
Image

Stef
Very interested
Posts: 3057
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Nov 17, 2014 2:25 pm

Of course you can everything in C but still having C++ make OO programming far easier :) I just translated a java program to C code is it was a big pain in the ass compared to C++ translation :p

Chilly Willy
Very interested
Posts: 2854
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Nov 17, 2014 6:45 pm

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.
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.

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.
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.

Chilly Willy
Very interested
Posts: 2854
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Nov 17, 2014 6:50 pm

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).
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. :lol:

Stef
Very interested
Posts: 3057
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Nov 17, 2014 9:43 pm

You have the point ;) But still imo the latter GCC really produces bad code for m68k and SGDK performance is really impacted by that :-/

Chilly Willy
Very interested
Posts: 2854
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Mon Nov 17, 2014 11:26 pm

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 :-/
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
Very interested
Posts: 3057
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Tue Nov 18, 2014 9:15 am

Chilly Willy wrote:
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 :-/
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.
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 compilers ;)

Chilly Willy
Very interested
Posts: 2854
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Tue Nov 18, 2014 6:11 pm

Stef wrote:
Chilly Willy wrote:
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 :-/
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.
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 compilers ;)
So 25%... definitely time for another round of checks. I wonder if they've improved that any... or if it got worse.

Stef
Very interested
Posts: 3057
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Tue Nov 18, 2014 10:10 pm

From my last checks out was getting worse, but maybe absolute latter version are better, I've to admit I didn't checked from sometime now.
Of course for better test you need to benchmark 100% C code, I say that because sgdk uses assembly sometime.

Post Reply