MinGW32 compiled GCC 7.2.0 Toolchain (mipsel-unknown-elf)

Downloadable items posted by PSXDEV members are within this forum.
User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

MinGW32 compiled GCC 7.2.0 Toolchain (mipsel-unknown-elf)

Post by LameGuy64 » November 13th, 2018, 4:13 pm

Here's a download of the GNU GCC 7.2.0 Toolchain and Binutils 2.29.1 compiled using MinGW32 for 32-bit Windows hosts. I decided to put this up when I managed to compile the toolchain under Windows some time ago which took me quite awhile to figure out even with msys and cygwin64 environments for convenience to those who want to play around with PSXSDK and other homebrew PlayStation libraries. It includes compilers for C and C++.

Toolchain archives for Windows and other host platforms can be downloaded here.

I've also included versions of the toolchain precompiled for the following hosts:
  • linux-amd64
  • linux-i686
  • linux-arm (RPi)
  • freebsd-amd64
You may want to install MSys if you want to use make and some Linux commands to use in your makefile.

You'll also need a little tool called elf2x for converting ELF files into a PS-EXE as well as instructions on specifying a program text load address to your executable.

Keep in mind that this download includes the toolchain only and does not include any libraries for doing anything with the PlayStation. You'll either have to get those elsewhere (such as PSXSDK) or write your own libraries :). C++ and possibly other languages will not work if the support functions those languages depend on are not available.

If you wish to compile the toolchain yourself, use the following parameters:

Code: Select all

For Binutils (always compile and install first):
../binutils-2.29.1/configure --disable-nls --prefix=/usr/local/mipsel-unknown-elf --target=mipsel-unknown-elf --with-float=soft

Then install with [b]make install-strip[/b]

For GCC:
../gcc-7.2.0/configure --disable-nls --disable-libada --disable-libssp --disable-libquadmath --disable-libstdc++-v3 --disable-static --target=mipsel-unknown-elf --prefix=/usr/local/mipsel-unknown-elf --with-float=soft --enable-languages=c,c++ --with-gnu-as --with-gnu-ld

Then install with [b]make install-strip[/b]
Those options only include C and C++ compilers. Other compilers may be compiled by adding them to the --enable-languages parameter.

When compiling for Windows add a --enable-win32-registry=mips-gcc option for both GCC and Binutils. It will configure perfectly fine without it however. You'll also need to add --disable-libgcc because for whatever reason it appears to be impossible to compile libgcc under Windows even with cygwin64 or msys2 so I've included libgcc in precompiled form in the toolchain downloads. You only need to download the libgcc libraries only for the win32 version, the other versions already have it included.

Update: Replaced toolchain download with a link to a Mediafire folder that conains the precompiled toolchain for win32 and various hosts.
Last edited by LameGuy64 on December 8th, 2018, 11:09 pm, edited 3 times in total.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

Orion_
Verified
Legendary Programmer
Legendary Programmer
Posts: 240
Joined: Aug 13, 2012
I am a: Programmer
PlayStation Model: Net Yaroze
Location: France
Contact:

Post by Orion_ » November 13th, 2018, 10:19 pm

nice ! Thank you for this, It's really a nightmare to compile GCC under windows, I never managed to get it working, I always used precompiled toolchain (like pspsdk) but it's an old gcc version
I wonder if the code is better optimized with this version
Retro game development on Playstation and other consoles http://orionsoft.free.fr/

mrhaboobi
Active PSXDEV User
Active PSXDEV User
Posts: 59
Joined: Nov 18, 2012

Post by mrhaboobi » November 14th, 2018, 6:34 am

LameGuy64 wrote: November 13th, 2018, 4:13 pm Here's a download of the GNU GCC 7.2.0 Toolchain and Binutils 2.29.1 compiled using MinGW32 for 32-bit Windows hosts. I decided to put this up when I managed to compile the toolchain under Windows some time ago which took me quite awhile to figure out even with msys and cygwin64 environments for convenience to those who want to play around with PSXSDK and other homebrew PlayStation libraries. It includes compilers for C, C++, ObjC and Fortran.

Download the Toolchain Here

You may want to install MSys if you want to use make and some Linux commands to use in your makefile.

You'll also need a little tool called elf2x for converting ELF files into a PS-EXE as well as instructions on specifying a program text load address to your executable.

Keep in mind that this download only includes the toolchain only and does not include any libraries for doing anything with the PlayStation. You'll either have to get those elsewhere (such as PSXSDK) or write your own libraries :). C++ and possibly other languages will not work if the support functions required for those languages are not available.
HI.

So i wondered if this is something that will work with Yaroze? which is Ecoff not elf? Can you provide any instructions as to how you did this, are you able to help put together an updated Yaroze version using djgpp v2 or something along those lines?

This is agreat achievement.!

Orion_
Verified
Legendary Programmer
Legendary Programmer
Posts: 240
Joined: Aug 13, 2012
I am a: Programmer
PlayStation Model: Net Yaroze
Location: France
Contact:

Post by Orion_ » November 14th, 2018, 8:28 am

I see no point in using the net yaroze SDK, which is far less capable than the official PSY-Q available.
Retro game development on Playstation and other consoles http://orionsoft.free.fr/

User avatar
gwald
Verified
Net Yaroze Enthusiast
Net Yaroze Enthusiast
Posts: 282
Joined: Sep 18, 2013
I am a: programmer/DBA
PlayStation Model: Net Yaroze
Contact:

Post by gwald » November 16th, 2018, 6:44 pm

LameGuy64 wrote: November 13th, 2018, 4:13 pm Here's a download of the GNU GCC 7.2.0 Toolchain and Binutils 2.29.1 compiled using MinGW32 for 32-bit Windows hosts.
Thanks for this, I'll have to try it out!

And +1 for a yaroze (ecoff) build.
Maybe upload your PSX toolchain configs or source tree to github or a zipfile etc?
I could look at it and see, it might work. :shrug

Orion_ wrote: November 14th, 2018, 8:28 am I see no point in using the net yaroze SDK, which is far less capable than the official PSY-Q available.
You might not, but many others might :dance
Programming isn't always about the software's capabilities, and obviously that wasn't the point to the Net Yaroze :roll:
As someone that programmed it, I think it has plenty of merit to be maintained/supported, It's a very simple SDK and great tech to learn on :ugeek:

And come on.. it's your favourite PSX! :clap :lol:
Image

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » November 17th, 2018, 1:18 pm

I did try to build GCC to output ECOFF (using mipsel-unknown-ecoff) a few days ago but sadly, the toolchain no longer supports it anymore.

To those who want to try to build a toolchain yourself, make sure you have MinGW and msys installed and referenced in your PATH environment variable. Create a build directory (ie. gcc-build or binutils-build) next to the directories containing the toolchain source files. Go into a bash prompt by entering sh and enter the following while inside a build directory:

Code: Select all

For GCC:
../gcc-7.2.0/configure --target mipsel-unknown-elf --enable-win32-registry=mips-gcc --prefix /mips-gcc --disable-nls --disable-shared --disable-libada --disable-libssp --with-float=soft

For Binutils:
../binutils-2.29.1/configure --prefix=/mips-gcc --target=mipsel-unknown-elf -enable-win32-registry=mips-gcc --with-float=soft
These options are derived from the build instructions in PSXSDK.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

User avatar
gwald
Verified
Net Yaroze Enthusiast
Net Yaroze Enthusiast
Posts: 282
Joined: Sep 18, 2013
I am a: programmer/DBA
PlayStation Model: Net Yaroze
Contact:

Post by gwald » November 18th, 2018, 4:42 pm

Ha, true, I don't know why ask. :shrug
I mentioned that a few days ago :

anyway, I might try again with an old mingw gcc build.

Thanks again :praise

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » November 21st, 2018, 9:58 pm

I recently figured out the right parameters to compile the toolchain with absolutely no errors. I replaced the download with a new version of the archive containing an error free build of the toolchain along with being configured with --with-gnu-as and --with-gnu-ld options which fixes include paths not working when compiling assembler files with gcc.

I also added the command line options I used to build the toolchain properly to spare anyone who wants to compile the toolchain themselves from insanity. It may also work for building newer versions of the toolchain.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

danhans42
BANNED
BANNED
Posts: 329
Joined: Nov 28, 2012

Post by danhans42 » November 22nd, 2018, 12:04 am

This is something I am interested in, as I want to get some stuff running on RaspberryPi.
Will give it a go later.

Thanks

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » December 8th, 2018, 11:11 pm

Just added downloads of the toolchain compiled for various hosts including linux-arm (Raspberry Pi). I also added a download of the libgcc library since it is apparently mandatory for things like int64 emulation and for whatever reason it will never compile under Windows.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

Sblorgz
Curious PSXDEV User
Curious PSXDEV User
Posts: 22
Joined: May 18, 2015

Post by Sblorgz » December 8th, 2018, 11:52 pm

Does this even work with Psy-Q natively or with converted libs? Because otherwise you're in for a can of warms with those system calls and open source libraries to port correctly.

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » December 9th, 2018, 12:30 am

These are intended to be used with open source libraries. I haven't bothered compiling any of the existing ones with these builds of the GNU toolchain since I write my own libraries instead (yeah, I'm that hardcore) as the existing ones don't really fit my standards very well but I occasionally use them as a reference.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

Sblorgz
Curious PSXDEV User
Curious PSXDEV User
Posts: 22
Joined: May 18, 2015

Post by Sblorgz » December 9th, 2018, 2:28 am

If you did write any low level libraries then you should probably already know what kind of screw ups modern GCC can do to PSX i-cache (code reorder specifically, which can be awful) and with hardware register access (i.e. unwanted default optimization to operations like spu stagger for wait loops). This needs some deep testing.

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » December 9th, 2018, 11:13 am

I never had any issues working with code compiled using GCC 7.2.0 on the PS1 so I don't exactly know what you're talking about. The compiler's register usage adheres to the R3000 specification and I've had no issue interacting with hardware registers (though it might be because I do such operations in MIPS assembly but I didn't have issues with interacting with hardware registers in C either). Heck, I can even call 25+ year old BIOS functions from the C compiler and they still work properly including printf() with a large number of arguments.

I've been working on something pretty sophisticated complete with full GTE support (both assembly and in-line) lately using GCC 7.2.0 and haven't ran into any of the problems you've mentioned. Also, the toolchain included with Programmer's Tool SDK (or PsyQ SDK) uses GNU GCC as well while Codewarrior on the other hand uses MIPSPRO.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

Sblorgz
Curious PSXDEV User
Curious PSXDEV User
Posts: 22
Joined: May 18, 2015

Post by Sblorgz » December 10th, 2018, 6:20 am

I mean intentionally weird code like the following taken from libspu:

Code: Select all

// spu time waster
void _spu_Fw1ts()
{
	int v[2];

	v[1] = 13;
	v[0] = 0;
	goto stuff;

	while (1)
	{
		v[1] += v[1] * 12;
		v[0]++;
		__asm__ volatile ("nop");
		__asm__ volatile ("nop");
		__asm__ volatile ("nop");
stuff:
		if (v[0] >= 60) break;
	}
}
If it translates into this intended piece of assembly you're in the clear, otherwise there will be several issues with low level code and possibly more:

Code: Select all

_spu_Fw1ts:
                addiu   $sp, -8
                li      $v0, 0xD
                sw      $v0, 4($sp)
                j       loc_D64
                sw      $zero, 0($sp)
loc_D38:
                lw      $a0, 4($sp)
                addiu   $v1, 1
                sw      $v1, 0($sp)
                sll     $v0, $a0, 1
                addu    $v0, $a0
                sll     $v0, 2
                addu    $a0, $v0
                sw      $a0, 4($sp)
                nop
                nop
                nop
loc_D64:
                lw      $v1, 0($sp)
                nop
                slti    $v0, $v1, 0x3C
                bnez    $v0, loc_D38
                nop
                jr      $ra
                addiu   $sp, 8
I'm aware that PSY-Q uses GCC, but it's a heavily modified version crafted for the hardware. You can't just take any MIPS toolchain and call it a day.

User avatar
LameGuy64
Verified
Psy-Q Enthusiast
Psy-Q Enthusiast
Posts: 388
Joined: Apr 10, 2013
I am a: Hobbyist Game Developer
Motto: Commercial or not, play it!
PlayStation Model: H2000/7000
Location: Philippines
Contact:

Post by LameGuy64 » December 10th, 2018, 11:19 am

Well, the only compiler related bug I've encountered was having a while() statement that waits for a specific hardware register to change with no code in it would sometimes produce an indefinite loop (branch instruction jumping to itself) but that was fixed by putting some dummy logic into said while loop.

I suppose the reason why I don't run into such compiler related issues is because I write all low level stuff in my libraries entirely in assembly which is how its supposed to be done when dealing with hardware registers.
Please don't forget to include my name if you share my work around. Credit where it is due.

Dev. Console: SCPH-7000 with SCPH-7501 ROM, MM3, PAL color fix, Direct AV ports, DB-9 port for Serial I/O, and a Xplorer FX with Caetla 0.35.

DTL-H2000 PC: Dell Optiplex GX110, Windows 98SE & Windows XP, Pentium III 933MHz, 384MB SDRAM, ATI Radeon 7000 VE 64MB, Soundblaster Audigy, 40GB Seagate HDD, Hitachi Lite-on CD-RW Drive, ZIP 250 and 3.5" Floppy.

Yagotzirck
Verified
Extreme PSXDEV User
Extreme PSXDEV User
Posts: 131
Joined: Jul 17, 2013

Post by Yagotzirck » December 10th, 2018, 10:32 pm

LameGuy64 wrote: December 10th, 2018, 11:19 am Well, the only compiler related bug I've encountered was having a while() statement that waits for a specific hardware register to change with no code in it would sometimes produce an indefinite loop (branch instruction jumping to itself) but that was fixed by putting some dummy logic into said while loop.
Wouldn't the volatile keyword do the trick in such cases? Just curious.

Sblorgz
Curious PSXDEV User
Curious PSXDEV User
Posts: 22
Joined: May 18, 2015

Post by Sblorgz » December 13th, 2018, 8:29 am

LameGuy64 wrote: December 10th, 2018, 11:19 amI suppose the reason why I don't run into such compiler related issues is because I write all low level stuff in my libraries entirely in assembly which is how its supposed to be done when dealing with hardware registers.
Problem is PSY-Q libraries are mostly written in C, only a very restricted amount of function is done via assembly or even inlined assembly.
Yagotzirck wrote: December 10th, 2018, 10:32 pmWouldn't the volatile keyword do the trick in such cases? Just curious.
That's exactly how you should declare hardware registers in C.

Yagotzirck
Verified
Extreme PSXDEV User
Extreme PSXDEV User
Posts: 131
Joined: Jul 17, 2013

Post by Yagotzirck » December 13th, 2018, 9:48 am

I know, I was wondering if he declared the hardware register he was talking about as volatile and the compiler still optimized it away, or if he declared it as a "normal" variable and had to resort to the kludge he mentioned... in the latter case I wouldn't call it a compiler-related bug, more like an oversight on his part.

Sblorgz
Curious PSXDEV User
Curious PSXDEV User
Posts: 22
Joined: May 18, 2015

Post by Sblorgz » December 13th, 2018, 1:12 pm

It's likely a missing volatile declaration or some macro using a type cast. Doubt GCC got that broken with standard variable types on MIPS, but if volatile is already there it's certainly not a good thing.

Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests