What's wrong with GCC (sgdk)? Why it crashes 10% of runs?
Moderator: Stef
-
- Very interested
- Posts: 158
- Joined: Sat May 12, 2012 7:37 pm
- Location: Ukraine
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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.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 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.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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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 wrote: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.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 makes more sense I was wondering about the gcc version.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.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 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:
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;
}
Last edited by Chilly Willy on Mon Jul 30, 2012 10:53 pm, edited 1 time in total.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
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...
I never tried older version of GCC (as 2.X.X), i wonder if they could be better suited for m68k target...
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
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: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.
http://en.wikibooks.org/wiki/GNU_C_Comp ... chitecture