HomeForumsWhat's newResources 
 
 
C++ on Saturn
vbt - Aug 25, 2008
  vbt Aug 25, 2008
is there specific things to configure or best practices to make CPP on Saturn ? or more generally with SuperH CPUs ?

 RockinB Aug 25, 2008
Things I stumbled over with CPP projects on Saturn (Lynx and Wonderswan emu) were:

  • the link script may have to contain some additional sections

  • in SGL examples, function main() is located in a seperate C file. Because of linking problems, better place main() in a C++ file.
  • a lot of additional stuff is linked to the binary, making it very big

  • to reduce executable size, I overloaded the new and delete constructors with custom memory allocators and specified -fno-rtti (real time type invokation) and -fno-exceptions. Then the result should be comparable to standard C. Google for "embedded C++"
  • If you use a C library like SGL or SBL, special care must be taken when calling them from C++. Declarations of functions must be labeled as C, an example:
    Code: 
      
    #ifdef __cplusplus

extern "C" {

#endif

#include 

#include 

#ifdef __cplusplus

}

#endif

  vbt Aug 30, 2008

RockinB said:
Things I stumbled over with CPP projects on Saturn (Lynx and Wonderswan emu) were:


That's also my target, I asked mainly for a stella port but I don't really like the source. Thanks for all these, they will be used.

 vbt Dec 17, 2008

RockinB said:
  • to reduce executable size, I overloaded the new and delete constructors with custom memory allocators and specified -fno-rtti (real time type invokation) and -fno-exceptions. Then the result should be comparable to standard C. Google for "embedded C++"


I've just tested the binary moved from 372kb to 320kb.


  
	
	

		
		

			
    

  • If you use a C library like SGL or SBL, special care must be taken when calling them from C++. Declarations of functions must be labeled as C
    

    •


Thanks for this I've used it and it fixed all my problems.

 RockinB Jan 4, 2009
Recently, I've had problems getting a c++ game to run on Saturn. It didn't enter main() or ss_main(), must have hanged up in some startup code linked in by the linker. Looking at yabause's CPU debugger and at my map file, I found out that it hangs in a function called __sccl, somehow related to vfprintf and __main().

So I put a dummy function void __main() {} in a seperate .c file, linked it to the other .c++ files and the game started up correctly . It won't work when you compile that dummy function as c++ file. Obviously, it hanged in __main(), but I can't say why.

On a different note, with COFF compiler the function __main() is the reason why malloc() and free() are linked to the binary, even if it's not used in the game at all. Defining a dummy function void __main() {} in a c file (not c++) helps here. This can be useful when you want to save some kBytes of binary size, or if you must be sure to not use malloc somewhere, because you use a different memory allocator.