Page 4 of 4
Posted: Mon Jul 30, 2012 2:40 pm
by greatkreator
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.
Posted: Mon Jul 30, 2012 7:34 pm
by Chilly Willy
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.
Posted: Mon Jul 30, 2012 9:03 pm
by sega16
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.
Posted: Mon Jul 30, 2012 9:25 pm
by Chilly Willy
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.
Posted: Mon Jul 30, 2012 10:41 pm
by sega16
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.
Posted: Mon Jul 30, 2012 10:50 pm
by Chilly Willy
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;
}
Posted: Mon Jul 30, 2012 10:50 pm
by Stef
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...
Posted: Tue Jul 31, 2012 12:46 am
by sega16
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.
Posted: Tue Jul 31, 2012 1:02 am
by Chilly Willy
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