Update your Genesis/32X Toolchain!

Talk about development tools here

Moderator: KanedaFr

Chilly Willy
Very interested
Posts: 2360
Joined: Fri Aug 17, 2007 9:33 pm

Update your Genesis/32X Toolchain!

Postby Chilly Willy » Sat Feb 26, 2011 7:01 am

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.

antime
Interested
Posts: 22
Joined: Sun Feb 06, 2011 9:18 pm
Contact:

Postby antime » Sat Feb 26, 2011 7:48 pm

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: Select all

$ ../../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.

sega16
Very interested
Posts: 248
Joined: Sat Jan 29, 2011 3:16 pm
Location: U.S.A.

Postby sega16 » Sun Mar 06, 2011 4:20 pm

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.

User avatar
powerofrecall
Very interested
Posts: 202
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Postby powerofrecall » Sun Mar 06, 2011 5:21 pm

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.

sega16
Very interested
Posts: 248
Joined: Sat Jan 29, 2011 3:16 pm
Location: U.S.A.

Postby sega16 » Sun Mar 06, 2011 5:32 pm

I guess so...
Image

Chilly Willy
Very interested
Posts: 2360
Joined: Fri Aug 17, 2007 9:33 pm

Postby Chilly Willy » Sun Mar 06, 2011 8:15 pm

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.

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. :lol:

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

http://dcemulation.org/phpBB/viewtopic. ... 9&t=100843

User avatar
powerofrecall
Very interested
Posts: 202
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Postby powerofrecall » Sun Mar 06, 2011 10:18 pm

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.

Chilly Willy
Very interested
Posts: 2360
Joined: Fri Aug 17, 2007 9:33 pm

Postby Chilly Willy » Sun Mar 06, 2011 11:53 pm

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! :D


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.

antime
Interested
Posts: 22
Joined: Sun Feb 06, 2011 9:18 pm
Contact:

Postby antime » Mon Mar 07, 2011 1:23 am

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.

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.

Chilly Willy
Very interested
Posts: 2360
Joined: Fri Aug 17, 2007 9:33 pm

Postby Chilly Willy » Mon Mar 07, 2011 2:26 am

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.


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. :?

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.

sega16
Very interested
Posts: 248
Joined: Sat Jan 29, 2011 3:16 pm
Location: U.S.A.

Postby sega16 » Mon Mar 07, 2011 3:15 am

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.

antime
Interested
Posts: 22
Joined: Sun Feb 06, 2011 9:18 pm
Contact:

Postby antime » Mon Mar 07, 2011 4:51 am

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.

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.

Chilly Willy
Very interested
Posts: 2360
Joined: Fri Aug 17, 2007 9:33 pm

Postby Chilly Willy » Mon Mar 07, 2011 6:05 am

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.


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. :D

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:

antime
Interested
Posts: 22
Joined: Sun Feb 06, 2011 9:18 pm
Contact:

Postby antime » Mon Mar 07, 2011 6:30 am

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.

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.

User avatar
powerofrecall
Very interested
Posts: 202
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Postby powerofrecall » Mon Mar 07, 2011 4:18 pm

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.


Return to “Tools”

Who is online

Users browsing this forum: No registered users and 0 guests