GenDev SpritesMind Website SpritesMind.Net
Sega Megadrive/Genesis development
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Update your Genesis/32X Toolchain!
Goto page 1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    SpritesMind.Net Forum Index -> Tools
View previous topic :: View next topic  
Author Message
Chilly Willy
Very interested


Joined: 17 Aug 2007
Posts: 2224

PostPosted: Sat Feb 26, 2011 7:01 am    Post subject: Update your Genesis/32X Toolchain! Reply with quote

Building a Genesis/SCD/32X toolchain

1 - Go here and download gcc-4.8.3.tar.bz2.

Decompress the archive; you should end up with one folder called gcc-4.8.3.

2.1 - Go here and download mpfr-3.1.2.tar.bz2.
2.2 - Go here and download mpc-1.0.2.tar.gz.
2.3 - Go here and download gmp-6.0.0a.tar.lz.

Decompress them all in the same folder. You should have three folders called mpfr-3.1.2, mpc-1.0.2, and gmp-6.0.0. Rename them to get rid of the version numbers, leaving you with mpfr, mpc, and gmp. Copy them into the gcc-4.8.3 folder.

3 - Go here and download binutils-2.24.tar.bz2.

Decompress it in the same folder as the gcc folder so that you have two folders - gcc-4.8.3 and binutils-2.24.

4 - Go here and download newlib-2.1.0.tar.gz.

Decompress it in the same folder as gcc and binutils, leaving you with three folders - gcc-4.8.3, binutils-2.24, and newlib-2.1.0.

5 - Download this archive containing a makefile, several linker scripts, and a set of SCD boot blocks.

Decompress it to the same folder as the others above.

6 - If you wish to leave the makefile with the default path of /opt/toolchains/sega, make sure you have permission to write to /opt or the toolchain will fail to install to the path. Since there's nothing critical in /opt, it's easiest just to do "sudo chmod 777 -R /opt" which allows anyone to do anything they want in /opt.

7 - Run "make -f makefile-sega" - depending on the speed of your computer, you should now have two toolchains in /opt/toolchains/sega: m68k-elf and sh-elf. Copy the ldscripts and bootblocks folders into /opt/toolchains/sega - the full folders, not just the contents of the folders.

You now have the latest gcc, binutils, and newlib for both the 68000 and the SH2. The 68000 and SH2 have compilers for C, C++, Objective-C, and Objective-C++.

8 - Make a bin folder in /opt/toolchains/sega. Copy whatever misc tools you use into it, like sixpack or bin2c.

9 - You'll need the proper export to use the toolchains, and assuming you left the path to /opt, this would be:

export GENDEV=/opt/toolchains/sega

Note: My examples assume the path to be as above. You therefore only need to set GENDEV if you used some other path.

Here is an archive with example code - it includes Tic-Tac-Toe in both C and C++ for both the MD and the 32X, as well as my 32X version of Yeti3D with Module playing and sound effects. The linker scripts in the archive are older than the ones in step 5, so don't replace them!

MD_32X_Examples.7z

One thing to note about gcc 4.4 and better (which concerns this toolchain since it's 4.8.3) - if the C/C++ code directly accesses hardware, you MUST compile that code with -O1! If you compile at -O2 or greater, gcc reorders the code for better speed regardless of how reordering may affect the system. Casting the accesses as volatile will NOT cure the problem. I can personally vouch this behavior occurs for gcc 4.4 and 4.5 on MIPS, SH, and M68K. If you look in my 32X example, you'll see hw_32x.c is compiled at -O1 while the rest is compiled at -O3. Note, I need to do some checking on this part - it may just be necessary to add full memory barriers after any hardware access. Until I can check on that, have hardware access in its own file and compile that one file with -O1. All others are fine with -Ofast.

EDIT: Updated toolchain - latest versions on everything but gcc. I won't update gcc to 4.9 until they've had a couple updates to it.


Last edited by Chilly Willy on Mon Aug 25, 2014 8:19 pm; edited 6 times in total
Back to top
View user's profile Send private message
antime
Interested


Joined: 06 Feb 2011
Posts: 22

PostPosted: Sat Feb 26, 2011 7:48 pm    Post subject: Reply with quote

I've built GCC 4.5.1 for m68k, and I don't recall having to do anything special to get C++ support working. I had to apply a patch so MPFR 3.0.0 would build, but that has apparently been fixed in 4.5.2. The configure command I used was just
Code:
$ ../../gcc-4.5.1/configure --prefix=/Users/anders/local --target=m68k-elf --disable-nls --enable-languages=c,c++ --with-newlib


In any case, it is worth pointing out that at least in my admittedly meager experience, GCC 4.5.1 produced much worse code than version 4.4.0 I used previously.
Back to top
View user's profile Send private message Visit poster's website
sega16
Very interested


Joined: 29 Jan 2011
Posts: 239
Location: U.S.A.

PostPosted: Sun Mar 06, 2011 4:20 pm    Post subject: Reply with quote

Edit:To get makefiles on windows go to :http://gnuwin32.sourceforge.net/packages/make.htm
And edit your path once you install it.
So i tried to build the make files and got "make is not recognized as an internal or external command" (yes I am using windows 7)is there a package I need to download for make?
it appears there is a version 3 of mpfr available is your link just old? or the old version better.I am just gonna try v.3
Edit and also mpc is on .9


Last edited by sega16 on Sun Mar 06, 2011 5:22 pm; edited 1 time in total
Back to top
View user's profile Send private message
powerofrecall
Very interested


Joined: 17 Apr 2009
Posts: 122
Location: USA

PostPosted: Sun Mar 06, 2011 5:21 pm    Post subject: Reply with quote

The instructions he posted are for linux/unix type machines. They won't work on windows without an environment like cygwin or msys. I'm taking a shot at building it under msys + mingw32 and it looks like it's doing fine so far. If there is any interest (and it continues to build properly!) I can upload the binaries somewhere when it's done.
_________________
my album - last thursday died last week
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
sega16
Very interested


Joined: 29 Jan 2011
Posts: 239
Location: U.S.A.

PostPosted: Sun Mar 06, 2011 5:32 pm    Post subject: Reply with quote

I guess so...
Back to top
View user's profile Send private message
Chilly Willy
Very interested


Joined: 17 Aug 2007
Posts: 2224

PostPosted: Sun Mar 06, 2011 8:15 pm    Post subject: Reply with quote

antime wrote:
I've built GCC 4.5.1 for m68k, and I don't recall having to do anything special to get C++ support working.


Maybe it's the difference between using gcc-core + g++ instead of gcc + g++; gcc-core has problems even building with the ARM processor, so maybe it also has problems with the 68000 as well. If you want to try geting c++ for the 68000 as well, you might try that - substitute gcc-4.5.2 for gcc-core-4.5.2 and add the second pass to the 68000 target like the SH2 target.

Quote:
In any case, it is worth pointing out that at least in my admittedly meager experience, GCC 4.5.1 produced much worse code than version 4.4.0 I used previously.


Usually, new versions introduce something "new" or "big", so the tenths are usually decent releases. The first update then usually breaks a bunch of stuff on the new release, so 4.x.1 releases usually suck. Then they fix it all for the next release, so 4.x.2 are pretty good. Laughing

For Windows people - my toolchain build is based on the Dreamcast toolchain build... which is for Windows. Laughing So check out that tutorial for differences in using Windows instead of linux.

http://dcemulation.org/phpBB/viewtopic.php?f=29&t=100843
Back to top
View user's profile Send private message
powerofrecall
Very interested


Joined: 17 Apr 2009
Posts: 122
Location: USA

PostPosted: Sun Mar 06, 2011 10:18 pm    Post subject: Reply with quote

I don't think I'll be uploading the binaries I got because they're about 800mb uncompressed.

On the positive side it builds Chilly's 32x mod player just fine and there are no compile problems that need to be sorted, so if you want to do this on windows, install minGW + msys, start up the msys shell, and just follow the instructions.
_________________
my album - last thursday died last week
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
Chilly Willy
Very interested


Joined: 17 Aug 2007
Posts: 2224

PostPosted: Sun Mar 06, 2011 11:53 pm    Post subject: Reply with quote

powerofrecall wrote:
I don't think I'll be uploading the binaries I got because they're about 800mb uncompressed.


Yeah, that's exactly why I posted the instructions and a couple files rather than make an archive. It's just too damn big! Very Happy


Quote:
On the positive side it builds Chilly's 32x mod player just fine and there are no compile problems that need to be sorted, so if you want to do this on windows, install minGW + msys, start up the msys shell, and just follow the instructions.


That's good. If you can compile that, you can do anything for the MD/32X. I don't just want to do 32X stuff, I want to help others who want to do 32X stuff as well. The more folks working on the 32X, the more valuable it is for everyone.
Back to top
View user's profile Send private message
antime
Interested


Joined: 06 Feb 2011
Posts: 22

PostPosted: Mon Mar 07, 2011 1:23 am    Post subject: Reply with quote

Chilly Willy wrote:
Maybe it's the difference between using gcc-core + g++ instead of gcc + g++; gcc-core has problems even building with the ARM processor, so maybe it also has problems with the 68000 as well.

Nah, I've been using the gcc-core and gcc-g++ packages for quite some time now. Just to test, I built 4.5.2 for the m68k-elf, sh-elf and arm-eabi targets and all built without issues. Since I had previous versions of the toolchains installed I didn't perform a two-stage bootstrap, but I suspect your problems stem from some of the configuration options in your script. I know that in the past I've had to use some some specific options to get GCC to build for more "obscure" targets like SH, but with newer versions the situation has reversed so that you can't pass some of those options if you want the build to succeed. I do know that for the targets listed above you don't need any special options for a basic C/C++ toolchain.

Quote:
Usually, new versions introduce something "new" or "big", so the tenths are usually decent releases. The first update then usually breaks a bunch of stuff on the new release, so 4.x.1 releases usually suck. Then they fix it all for the next release, so 4.x.2 are pretty good.

Well, I filed a bug, but so far no-one's been interested. Since m68k is such a marginal target nowadays I kinda doubt anyone will take an active interest. There's basically one GCC developer who's still interested in it, so unless there's a universal change that happens to fix it I fear it'll only get worse as time goes on.
Back to top
View user's profile Send private message Visit poster's website
Chilly Willy
Very interested


Joined: 17 Aug 2007
Posts: 2224

PostPosted: Mon Mar 07, 2011 2:26 am    Post subject: Reply with quote

antime wrote:
Chilly Willy wrote:
Maybe it's the difference between using gcc-core + g++ instead of gcc + g++; gcc-core has problems even building with the ARM processor, so maybe it also has problems with the 68000 as well.

Nah, I've been using the gcc-core and gcc-g++ packages for quite some time now. Just to test, I built 4.5.2 for the m68k-elf, sh-elf and arm-eabi targets and all built without issues. Since I had previous versions of the toolchains installed I didn't perform a two-stage bootstrap, but I suspect your problems stem from some of the configuration options in your script.


The two-stage build is so that newlib is used when building the standard c/c++ libs. You build binutils first, build the plain C compiler with no libs, use that to build the newlibs, then use BOTH of those to build the FULL gcc suite of compilers.


Quote:
I know that in the past I've had to use some some specific options to get GCC to build for more "obscure" targets like SH, but with newer versions the situation has reversed so that you can't pass some of those options if you want the build to succeed. I do know that for the targets listed above you don't need any special options for a basic C/C++ toolchain.


It probably is one of the options, as you mention. There's so many of the stupid things now with no explanation of what they are for and what systems need them. Confused

At least the SH2 went through with all the compilers - I see more folks using C++ on the 32X than on the MD. It has the memory for it.
Back to top
View user's profile Send private message
sega16
Very interested


Joined: 29 Jan 2011
Posts: 239
Location: U.S.A.

PostPosted: Mon Mar 07, 2011 3:15 am    Post subject: Reply with quote

so... How would one get this to work on windows... I read all the post but did not relay see anything that was that helpful.
Back to top
View user's profile Send private message
antime
Interested


Joined: 06 Feb 2011
Posts: 22

PostPosted: Mon Mar 07, 2011 4:51 am    Post subject: Reply with quote

Chilly Willy wrote:
The two-stage build is so that newlib is used when building the standard c/c++ libs. You build binutils first, build the plain C compiler with no libs, use that to build the newlibs, then use BOTH of those to build the FULL gcc suite of compilers.

GCC only really needs the headers from newlib when building the compiler itself, but the newlib build process needs the compiler to generate the configuration needed by a particular target. If you know there's been no radical change that would break C compatibility (which is very unlikely) you can build the second stage directly using an existing newlib. You can then of course rebuild newlib to take advantage of any compiler improvements.

Quote:
At least the SH2 went through with all the compilers - I see more folks using C++ on the 32X than on the MD. It has the memory for it.

Well, C++ by itself doesn't really cost anything, and if you take advantage of the idioms offered by the language it usually costs less than if you were to implement them yourself. And if you think C++ is expensive, Objective-C is orders of magnitude above that.

sega16 wrote:
so... How would one get this to work on windows...

Cygwin is by far the easiest way to build GCC under Windows. It should work pretty much out-of-the-box.
Back to top
View user's profile Send private message Visit poster's website
Chilly Willy
Very interested


Joined: 17 Aug 2007
Posts: 2224

PostPosted: Mon Mar 07, 2011 6:05 am    Post subject: Reply with quote

antime wrote:
Chilly Willy wrote:
The two-stage build is so that newlib is used when building the standard c/c++ libs. You build binutils first, build the plain C compiler with no libs, use that to build the newlibs, then use BOTH of those to build the FULL gcc suite of compilers.

GCC only really needs the headers from newlib when building the compiler itself, but the newlib build process needs the compiler to generate the configuration needed by a particular target. If you know there's been no radical change that would break C compatibility (which is very unlikely) you can build the second stage directly using an existing newlib. You can then of course rebuild newlib to take advantage of any compiler improvements.


But if you're building a clean toolchain for cross-compiling, you almost certainly don't have the needed newlib. That's the point - you probably only have the "native" newlib for your system, which will NOT make a proper build.


Quote:
Quote:
At least the SH2 went through with all the compilers - I see more folks using C++ on the 32X than on the MD. It has the memory for it.

Well, C++ by itself doesn't really cost anything, and if you take advantage of the idioms offered by the language it usually costs less than if you were to implement them yourself. And if you think C++ is expensive, Objective-C is orders of magnitude above that.


The obj-c stdlib is TINY compared to the c++ stdlib. Granted you won't be using EVERYTHING in the lib, but it's well known that C++ has ridiculous requirements for the libs. However, much of that can go in rom, so I suppose it's POSSIBLE to do some stuff on the MD in C++, I just don't see it. Very Happy

Quote:
sega16 wrote:
so... How would one get this to work on windows...

Cygwin is by far the easiest way to build GCC under Windows. It should work pretty much out-of-the-box.


Install CygWin and go into the cygwin terminal, not the Windows command shell. Then follow the linux directions. I think that's what he's saying.
Wink
Back to top
View user's profile Send private message
antime
Interested


Joined: 06 Feb 2011
Posts: 22

PostPosted: Mon Mar 07, 2011 6:30 am    Post subject: Reply with quote

Chilly Willy wrote:
But if you're building a clean toolchain for cross-compiling, you almost certainly don't have the needed newlib. That's the point - you probably only have the "native" newlib for your system, which will NOT make a proper build.

Of course. But after you've done it once, there's usually no need to spend the extra time for a full bootstrap.

Quote:
The obj-c stdlib is TINY compared to the c++ stdlib. Granted you won't be using EVERYTHING in the lib, but it's well known that C++ has ridiculous requirements for the libs.

I guess you mean the Objective-C runtime, you also need a class library to actually do anything. But keep in mind that Objective-C is a dynamic language; whereas C++ method calls are function calls going through at most one level of indirection, the corresponding Objective-C mechanism works by sending a signature to the runtime which uses it to look up the function for the recipient class. The dynamic nature of the language also means it's more or less impossible for the linker to know which parts of a library is actually needed, so you're pretty much forced to include the whole thing.
Back to top
View user's profile Send private message Visit poster's website
powerofrecall
Very interested


Joined: 17 Apr 2009
Posts: 122
Location: USA

PostPosted: Mon Mar 07, 2011 4:18 pm    Post subject: Reply with quote

Windows GCC 4.5.2 toolchain (about 55mb compressed, 800+ uncompressed)

I added Make and an environment batch file to this package and it will function at a windows command prompt, but I recommend downloading msys and setting your environment variables for the toolchain in there so you can have unix commands in your makefiles.

Tested with chilly's 32x mod player and my own in-progress MD project, seems to work fine.
_________________
my album - last thursday died last week
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
Display posts from previous:   
Post new topic   Reply to topic    SpritesMind.Net Forum Index -> Tools All times are GMT
Goto page 1, 2, 3, 4, 5, 6  Next
Page 1 of 6

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group