New PS2 homebrew toolchain based on GCC 5.3.0
#1
https://github.com/sp193/ps2toolchain
Most discussion is here: http://psx-scene.com/forums/f19/completi...c5-154680/
SP193;1201016 Wrote:In roughly 2012, Mega Man added official support for the MIPS R5900 (Emotion Engine) to Binutils and GCC.
Binutils itself has full support for the EE, but GCC only has basic support; it still lacks the EE-specific features that other MIPS processors do not have.

This includes (but not limited to):
  1. 128-bit loads/stores (Also considered part of MMI, but the patch is in a different place)
  2. support for the 2nd pipeline (i.e. mult1, div1 instructions, as well as the hi1 and lo1 registers).
  3. support for optimizations related to MMI.

I feel that this should be done, so that we won't need to constantly "chase the sun" when it comes to having functional tools. While the current tools do work, they sometimes don't play nice with newer operating systems and have some bugs.

My efforts here are for GCC 5.3.0. I built it with the latest version of Cygwin because my laptop in campus is a Windows laptop.
Hopefully, it would be possible to submit a full patch to the GCC steering committee. But at worst, I suppose that keeping it as a PS2-only patch would do.

Configure syntax:
Code:
../configure --prefix="$PS2DEV/ee" --target="mips64r5900el-ps2-elf" --program-prefix="ee-" --enable-languages="c" --disable-nls --disable-shared --disable-libssp --disable-libmudflap --disable-threads --disable-libgomp --disable-libquadmath --disable-target-libiberty --disable-target-zlib --without-ppl --without-cloog --with-headers=no --disable-libada --disable-libatomic --disable-multilib --with-float=hard

I have managed to add support for 128-bit loads/stores, as well as passing 128-bit variables by value.

I think that I have added support for the 2nd pipeline, but I don't know how to test that because GCC finds the mult instruction too convenient. I feel uncertain about the implementation of this system because some expands (i.e. mulsidi3_64bit_split) in mips.md allocate a register with MD_REG_FIRST, so I don't know if this definitely means that hi1 and lo1 won't ever be used.
The following register constrains were added:
  1. wr - LO1/HI1 combined pseudo register
  2. wl - LO1 register

As for processor-specific constrains:
  1. H - returns the current R5900 pipeline used (i.e. used to specify whether mult1 or mult is to be used).

I have yet to add support for MMI, but I feel that it wouldn't be as hard/important as adding support for the 2nd pipeline (no other MIPS has a true 2nd pipeline!).
It should be a better move to confirm that GCC is still working fine, even after the first two features are completed.

Please feel free to give comments/guidelines/suggestions because I am not so good with working with something as complex as GCC. Particularly with its RTL.

Patches:
128-bit load/stores only: https://www.sendspace.com/file/000v9n
128-bit load/stores + 2nd pipeline: https://www.sendspace.com/file/qry9ks
Reply

Sponsored links

#2
SP193 just pushed a patch to ps2toolchain that brings back "dvp" support.

He doesn't know how to use the VUs, anybody experienced with it can test it?
Reply
#3
If somebody bumps into this topic for some reason, most discussion is here:
http://psx-scene.com/forums/f19/completi...c5-154680/

SP193;1206114 Wrote:New update: Added new patches for the EE short-loop bug workaround (Binutils + GCC) and fixed the messed-up libgcc patches.

The existing support for the R5900 within GCC v5 has no support for working around the short-loop bug. This patch adds support for working around the short-loop bug.
Binutils has been patched to check for and warn against loops that would trigger the bug, while GCC has been patched to not generate loops that would trigger the bug.



EE revision 2.9 has a PRId of 0x2E14, as one SONY DEVNET message said.
The CXD9542GB has a PRId of 0x2E14, so EE revision 2.9 is the CXD9542GB. This EE chip is the one found in the SCPH-10000, SCPH-15000, SCPH-18000 (GH-003), as well as all TOOL and DTL-H10xxx DEX units.
This is the earliest EE chip model that we know of.

On a side note, it seems like the short-loop bug workaround within the existing homebrew GCC version is bugged.
Currently:
Code:
void
machine_dependent_reorg (first)
     rtx first;
{
  int insns_len, max_internal_pool_size, pool_size, addr, first_constant_ref;
  rtx insn;
  struct constant *constants;

  if (! TARGET_MIPS16)
    return;

#ifdef FILL_BDSLOT_WITH_NOP
  if (TARGET_MIPS5900 && !TARGET_NO_LENGTHEN_LOOP)
    r5900_lengthen_loops (first,0);
#endif

SONY original:
Code:
void
machine_dependent_reorg (first)
     rtx first;
{
  int insns_len, max_internal_pool_size, pool_size, addr, first_constant_ref;
  rtx insn;
  struct constant *constants;

#ifdef FILL_BDSLOT_WITH_NOP
  if (TARGET_MIPS5900 && !TARGET_NO_LENGTHEN_LOOP)
    r5900_lengthen_loops (first,0);
#endif

  if (! TARGET_MIPS16)
    return;

This mistake was already there in the GCC v3.2.2 patch. With the fix, the generated code is a little different.

Before:
Code:
00100018 <test>:
  100018:    af808008     sw    zero,-32760(gp)
  10001c:    00000000     nop
  100020:    1000fffd     b    100018 <test>
  100024:    00000000     nop

After:
Code:
00100018 <test>:
  100018:    af808008     sw    zero,-32760(gp)
  10001c:    1000fffe     b    100018 <test>
  100020:    00000000     nop
  100024:    00000000     nop

Input function:
Code:
volatile int glob;

void test(void)
{
    while(1)
        glob = 0;
}

***



That would be more worthwhile, indeed!
By the way, the Makefile problem that [MENTION=328668]AKuHAK[/MENTION] had was due to MinGW Make. That explains why none of us had that issue.
The problem has been worked around with a patch from AKuHAK.



There were many changes between GCC v3.2 and v5 as well. Especially around GCC v4.2, when some of the practices that GCC used to allow, got changed in favour of being more compliant with the C and C++ standards.
There is now better support for some things like vectorization, although I don't think that there is anything really interesting to us in v5.4.



Will look into it, thanks.

EDIT: it is caused by the source code having the import and export tables not stored within their designated files.
Starting from around GCC v4.2, the way that optimization is done was changed and that caused GCC to split apart the import and export tables.
For now, we're disabling that functionality with the fno-toplevel-reorder option, but it is only done by the Makefile rules for imports.lst and exports.tab.
Reply




Users browsing this thread: 1 Guest(s)