What's wrong with GCC (sgdk)? Why it crashes 10% of runs?

greatkreator · Post by **greatkreator** » Mon Jul 30, 2012 2:40 pm

Moved to Mac OS X (Fedora as well for an experiment) and forgot all the problems except my TV tuner became useless because of lack of drivers. Needed to buy a TV.

I have hybridized Chilly Willy's toolchain with Stef's sgdk and now have a very stable and full of features development tool.

Chilly Willy · Post by **Chilly Willy** » Mon Jul 30, 2012 7:34 pm

greatkreator wrote:Moved to Mac OS X (Fedora as well for an experiment) and forgot all the problems except my TV tuner became useless because of lack of drivers. Needed to buy a TV.

I have hybridized Chilly Willy's toolchain with Stef's sgdk and now have a very stable and full of features development tool.

That's what I had done at first... made my own makefile to make sgdk into a library. Right now, I'm trying to help get it working in linux just the same as it does in Windows.

sega16 · Post by **sega16** » Mon Jul 30, 2012 9:03 pm

greatkreator wrote: I have hybridized Chilly Willy's toolchain with Stef's sgdk and now have a very stable and full of features development tool.

That is good idea! Sgdk uses a very old version of gcc but Chilly's tool-chain is the newest version of gcc so in theory that should mean that gcc would generate better code because it has had more time to improve and add features. I think that the official sgdk should use Chilly's tool-chain with the sgdk libraries and tools.

Chilly Willy · Post by **Chilly Willy** » Mon Jul 30, 2012 9:25 pm

sega16 wrote:
greatkreator wrote: I have hybridized Chilly Willy's toolchain with Stef's sgdk and now have a very stable and full of features development tool.
That is good idea! Sgdk uses a very old version of gcc but Chilly's tool-chain is the newest version of gcc so in theory that should mean that gcc would generate better code because it has had more time to improve and add features. I think that the official sgdk should use Chilly's tool-chain with the sgdk libraries and tools.

In fairness, I'd like to point out that there are a couple of threads (and posts in this thread) on how the older gcc Stef still uses gives faster binaries than anything else yet tried. It's why he DOES still use the older gcc.

sega16 · Post by **sega16** » Mon Jul 30, 2012 10:41 pm

Chilly Willy wrote:In fairness, I'd like to point out that there are a couple of threads (and posts in this thread) on how the older gcc Stef still uses gives faster binaries than anything else yet tried. It's why he DOES still use the older gcc.

That makes more sense I was wondering about the gcc version.

Chilly Willy · Post by **Chilly Willy** » Mon Jul 30, 2012 10:50 pm

Of course, you can always replace the gcc with a newer version. Most folks probably won't notice a difference in speed for many programs. I use the new version mainly for SH2 anyway. I haven't really done a big MD project in C... yet.

EDIT: I've wondered if using short relative addressing might make a difference. Here's how you'd make the linker script for pushing variable/data into short addressing space:

Code: Select all

OUTPUT_ARCH(m68k)
EXTERN (_start)
ENTRY (_start)
__DYNAMIC  =  0;

/*
 * The memory map look like this:
 * +--------------------+ <- 0x00000000
 * | .text              |
 * |                    |
 * |          _text_end |
 * +--------------------+
 * .                    .
 * .                    .
 * .                    .
 * +--------------------+ <- 0xFFFF0000
 * |             _stack | top of stack
 * +--------------------+ <- 0xFFFF8000
 * | .data              | initialized data goes here
 * |                    |
 * |          _data_end |
 * +--------------------+
 * | .bss               |
 * |         _bss_start | start of bss, cleared by crt0
 * |                    |
 * |          _bss__end | start of heap, used by sbrk()
 * +--------------------+
 * .                    .
 * .                    .
 * .                    .
 * +--------------------+ <- 0x01000000
 */

MEMORY
{
    rom (rx) : ORIGIN = 0x00000000, LENGTH = 0x00400000
    ram (wx) : ORIGIN = 0xFFFF8000, LENGTH = 0x00008000
}

/*
 * Allocate the stack to be at the top of memory, since the stack
 * grows down
 */

PROVIDE (__stack = 0xFFFF8000);

SECTIONS
{
  .text 0x00000000 :
  {
    __text_start = .;
    *(.text)
    *(.text.*)
    *(.gnu.linkonce.t.*)

    . = ALIGN(16);
    __INIT_SECTION__ = .;
    KEEP (*(.init))
    SHORT (0x4E75)	/* rts */
    . = ALIGN(16);
    __FINI_SECTION__ = .;
    KEEP (*(.fini))
    SHORT (0x4E75)	/* rts */

    *(.eh_frame_hdr)
    KEEP (*(.eh_frame))
    *(.gcc_except_table)
    KEEP (*(.jcr))

    . = ALIGN(16);
     __CTOR_LIST__ = .;
    ___CTOR_LIST__ = .;
    LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2)
    KEEP (*(SORT(.ctors.*)))
    KEEP (*(.ctors))
    LONG(0)
    __CTOR_END__ = .;

    . = ALIGN(16);
    __DTOR_LIST__ = .;
    ___DTOR_LIST__ = .;
    LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2)
    KEEP (*(SORT(.dtors.*)))
    KEEP (*(.dtors))
     LONG(0)
    __DTOR_END__ = .;

    *(.rdata)
    *(.rodata)
    *(.rodata.*)
    *(.gnu.linkonce.r.*)
    . = ALIGN(16);
    __text_end = .;
  } > rom
  __text_size = __text_end - __text_start;

  .data 0xFFFF8000 :
  AT ( LOADADDR (.text) + SIZEOF (.text) )
  {
    __data_start = .;
    *(.data)
    *(.data.*)
    *(.gnu.linkonce.d.*)
    CONSTRUCTORS

    *(.lit8)
    *(.lit4)
    *(.sdata)
    *(.sdata.*)
    *(.gnu.linkonce.s.*)
    . = ALIGN(8);
    __data_end = .;
  } > ram
  __data_size = __data_end - __data_start;

  .bss :
  {
    __bss_start = .;
    *(.bss)
    *(.bss.*)
    *(.gnu.linkonce.b.*)
    *(.sbss)
    *(.sbss.*)
    *(.gnu.linkonce.sb.*)
    *(.scommon)
    *(COMMON)
    . = ALIGN(8);
    end = .;
    _end = end;
    __end = _end;
    __bss_end = .;
  } > ram
  __bss_size = __bss_end - __bss_start;

}

Stef · Post by **Stef** » Mon Jul 30, 2012 10:50 pm

GCC optimizations algorithm follow CPU architecture evolution and so are now very unadapted to old architecture as the m68k. I am currently using GCC 3.4.6 has it indeed does generate better code for m68k target than newer version. Unfortunately it also suffers of the annoying method inlining bug which is fixed in later version, too bad as the code could be even better.
I never tried older version of GCC (as 2.X.X), i wonder if they could be better suited for m68k target...

sega16 · Post by **sega16** » Tue Jul 31, 2012 12:46 am

I guess they are just going with the flow of the market and ignoring older processors. Does gcc use a generic compiler then translate the compiled code to the target that would expalin why gcc supports so many different processors.

Chilly Willy · Post by **Chilly Willy** » Tue Jul 31, 2012 1:02 am

sega16 wrote:I guess they are just going with the flow of the market and ignoring older processors. Does gcc use a generic compiler then translate the compiled code to the target that would expalin why gcc supports so many different processors.

Yes, they (usually) compile to an intermediate language that is then converted by the backend into assembly for the particular processor. You can see a simple block diagram here:
http://en.wikibooks.org/wiki/GNU_C_Comp ... chitecture