New patches, debian packages update, etc...

[pixel]

Hello, after MrHTFord just updated his patch that fixes a bss bug, here I go :-)

First, the two patches, binutils and gcc:

http://www.nobis-crew.org/ps2-patches/b ... ch.diff.gz
http://www.nobis-crew.org/ps2-patches/g ... ch.diff.gz

The only difference between this binutils patch and the previous one is the missing instruction MrHTFord noticed is now added. Let me just resume what's in:

-) Merged the three previous releases of dvp-binutils, iop-binutils and ee-binutils into this single one.
-) Added a "ps2" target, which will take both ee and iop features. Meaning that ps2-as supports -march=r5900, as well as -mmipsirx.
-) Added the register aliases patch, that allows you to type registers like $a2 or $t5 instead of the corresponding numberings.

So, the better way to use this package is now to compile it two times, once with the --target=ps2 option, and once with the --target=dvp option.

There is still no changelog or readme... I'm too tired to do that now ^^;


Now, for the gcc patch, I took MrHTFord's latest patch, and I modified it, so you'll find back all the previous features and bugfixes. Now, what's added:

-) Added a "ps2" target, since now the compiler will support both ee and iop (like the ps2-binutils)
-) Added a "-miop" option to ps2-gcc, so that it will behave like iop-gcc. This option will expand as "-march=r3000 -mfp32 -mgp32 -fno-builtin -DR3000 -D_3000 -D__3000 " for the cpp-specs, "-march=r3000 -mips1" for the asm-specs, and "-mmipsirx" for the link-specs.
-) Fixed some miscellaneous problems about that "iop compatibility". Especially the fact that by default, ps2-gcc was acting like compiling on a level 3 mips-ISA. Uglily fixed but working.
-) Fixed an issue that would cause a mingw32 host not compiling straight. (removing the creation of collect2 when creating a cross-compiler). I created two mingw32 packages as well:

http://www.nobis-crew.org/ps2-mingw32/p ... 32msvc.zip
http://www.nobis-crew.org/ps2-mingw32/p ... 32msvc.zip


Now, what does this imply about compiling the rest of the toolchain. There is a really really small patch on the ps2-newlib. Into config.sub, look for the line:

Code: Select all

ee)

and change it into:

Code: Select all

ee | ps2)

So that the --target=ps2 will be recognized correctly.

For the ps2lib, you have to change the Makefile.prefs in order EE_PREFIX and IOP_PREFIX will be equal to "ps2-", and the Makefile.iopglobal in order to add "-miop" at the end of the IOP_CFLAGS and IOP_LDFLAGS.

After that, if your package includes the ps2lib's Makefiles, there'll be no problem. Otherwise, just don't forget to change the "ee-" and "iop-" prefix into "ps2-" and add "-miop" as a CFLAGS of the iop part of your compilation.


Ho and, don't forget that -mCPU is not to be used anymore... Use -march instead.


For the binary packages I provide, the debian repository is the same as before:

deb http://www.nobis-crew.org/debian/ unstable main
deb-src http://www.nobis-crew.org/debian/ unstable main

and the binary tgz-packages are at:

http://www.nobis-crew.org/ps2-tgzs/

Packages provided are:

ps2-binutils (2.14)
dvp-binutils (2.14)
ps2-gcc (3.2.2, C and C++)
ps2-gcc-base (3.2.2 C only)
ps2-newlib (1.10.0)
ps2lib-cvs


Enjoy, and good night ;-)

[mrbrown]

This is outstanding work you've done :). I can't wait to grab everything and play around, especially with the updated IOP compiler. Very good work pixel :).

One note though - a while ago some ps2dev'rs came to the consensus to leave out the register aliases patch. The main reason is that those names will cause conflicts if you use the same names (for example, a variable named zero or t0) in your C code. If you check out the TGE source in CVS, there is an include file called regs.h that does the same thing using the C preprocessor. I don't know if you want to leave the register patch in, but that's just a suggestion.

Very nice stuff :).

[ooPo]

Just one word: w00t

Between Pixel doing the grunt work and MrHTFord whipping up bugfixes, we find ourselves with a spicy toolchain more up to date than what the pros use. Congrats. :)

Now, make sure you add some credit to yourselves in these patches.

[Oobles]

Fw0000rrrrr!

And absolutely incredible piece of work! Thanks.. and fw0000rr...

Oobles.

[emoon]

Great work dudes :)

[pixel]

Thanks guys :)

For the register aliases, it's "$t0" which is recognized as an alias, not "t0". The C code should have a global "$t0" variable then ;-)

Well, I don't think it will really really cause troubles in the way it's done. binutils-2.14 already added some aliases from the previous release. I just added more of them. $zero was already added between 2.9 and 2.14 :)
Actually, the defaults in the binutils-2.14 are "$zero", "$kt0", "$kt1", "$sp", "$fp" and "$ra". I added all the other registers as well here...

Now, for the tests... I continued compiling stuff and trying to run it. Aura for laura compiled after some quite modifications in the source and makefile. But when running it, it crashes randomly.

What's bugging me is the fact that whe compiling the ps2lib, gas gives warnings about the "loop too short"-bug of the r5900. Maybe it comes from here, but all the other small samples I tested runs fine (aura was the first "big" thing I tested)

Comments? :-)

[blackdroid]

What kind of exception and what is EPC pointing at, use nm to get the block that is faulty.

loop too short is "just" a warning, on rare occasions it is said that a loop <= 5 under special conditions will end after running once or twice.

Never ever encountered a problem with this myself, could very well be an early pipeline bug that has been fixed in later revisions of the ps2.

[pixel]

The demo just freezes. The current music bloc starts looping. No "big evident crash" actually.

I just tested DreamGL now ^^;

Well, the samples just act... "weired". It's like the Z-Buffer is.... well... reversed. But they do not crash or freeze at least :-)

That's fun to see that when I finally release the whole thing, the various things I didn't test before are not well working, while all the various things I tested work. Murphy's law huh? :)

Well, I'm still not really convinced that it might comes from the patches themselves ^^;

[blackdroid]

Ah ok well I guess the only thing you can do is start commenting out stuff :)

[ryani]

I've fixed some bugs in the disassembler and assembler. Also, you can now use vi05-style arguments to cfc2 and ctc2 instead of just $5.

http://www.mindspring.com/~foo/binutils ... 9ryani.txt

-- ryani

[Lukasz]

Greab job :)