forums.ps2dev.org

[pixel]

Hello,

I've end up creating a Work In Progress patch against binutils-2.14 in order to regroup and merge all the previous EE, IOP and DVP patches.

The patch is here:

http://www.nobis-crew.org/~pixel/binutils-2.14-ps2-20040208-WIP-patch.diff.gz

You have to apply it of course on a vanilla binutils-2.14 source tree. Then, it will behave the same way of all the older binutils. You can configure it with --target=ee, iop, dvp, and now, ps2. I added "ps2" as beeing an alias for "ee", since the generated binutils will be fully backward compatible with the iop-binutils too. It means that ee-as/ee-ld (or ps2-as/ps2-ld if you use the new target I created) should behave exactly the same as iop-as/iop-ld, if you specify the same command-line options, that is -march=r3000 and -m mipsirx (yes, "-m mipsirx" was not mandatory before)

Ho, don't forget: -mCPU won't work anymore... use -march instead.

Now, for me, it's still work in progress. It means this was tested a bit, but needs more intensive inner checks. So, if you are willing to help, please try to compile your projects using it, test if it works, and post back here :). Also, I'm interested to know if it compiles/works under cygwin. ;-)
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[Oobles]

Great work..

Which version of GCC should go with this? Use the same versions as before with their associated patches?

[pixel]

Thanks ^^;

Yep, exactly, for now, the older gcc should still be used. I'm now looking at gcc's sources in order to produce a patch for it.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[OptiRoc]

Fresh! Will test these under Cygwin during the next couple of days.

On a related note, what is "the situation" with SCE-developed binutils/gcc patches? For example, the support for VU0 in their EE toolchain is rather nifty, and as far as I know we don't have it in our compilers (correct me right away if I'm wrong). Any improvements made to the GNU tools should remain free, shouldn't they -- or can SCE circumvent this in some way?

[pixel]

SCE actually can.... by providing "precompilers". That's actually what they do. Although I do not exactly know the differences between the dvp-as provided here, and the ee-dvp-as provided by SCE, I know they provide some additionnal precompilers, like "vcl", which will generate vsm sources.
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[OptiRoc]

Yes, but there are also modifications done to GCC that adds inline support for VU0-code (referred to as "Dylan's VU0 support patches"). These are mentioned in the following project at PS2linux:
http://playstation2-linux.com/project/download_single_file.php/5_125

Some details here:
http://playstation2-linux.com/project/download_single_file.php/5_125_34/vector_common.h

Now, I'm not a GCC whiz (this is where you come in!), nor very familiar with the GPL terms, so... What does the GPL say about these improvements to the actual GCC compiler?

[pixel]

I am not a gcc wizard too ^^; I just tend to know how the whole thing ties up and works, so I can tweak it a bit. I play with binutils/gcc since a long time now, creating weired cross compilers ^^ But it's a quite easy task actually...


The GPL say more or less (well, that's the basic idea... don't ask me for the inner details) that one has to give out the modifications done to a GPLed package. But I'm actually unaware of the nature of the modifications done by SCE to the direct gnu tools. Moreover, I think that part of the patches I have here are originated from sony themself (or from SN systems). I have to admit I'm really confused ^^; But all the patches I saw more or less looked the same.

But if they have, say, a gcc/binutils toolchain that produce plain elf files, which you have to convert using a Sony's ELF->IRX converter, then, they do not have to give out this tool.


Well, if I understand correctly what I quickly looked at, the "ps2stuff" package includes some inline ASM statements, but which are not direct DVP code. Or is it ? That would mean that this kind of code should compile with the "current" gcc, or with the patched one, with the patch he gives:

http://playstation2-linux.com/project/download_single_file.php/5_125_47/gcc-2.95.2-ps2stuff.patch
http://playstation2-linux.com/project/download_single_file.php/5_125_48/gcc-3.0.3-ps2stuff.patch


Anyway, the main idea is to stick with newer versions of binutils/gcc. That's why I tried to sort out all the binutils's patches (actually, there were 2 main patches, the IOP and the EE ones, and one 'ugly' package containing binutils and gcc with ee and dvp patches, that I managed to take the DVP part out.)

So, for me, it's even a miracle this actually woks ^^; I don't understand *all* the patches I put together into the pool. A few things remains unknown for me. Hopefully, they are more related to the disassembler part than anything else. "Monkey work" huh :-)

Afterward, the same will have to be done with gcc. That is, grabbing all the patches around, and try to summarize them into a newer gcc's version. The only problem is that gcc's code has heavely changed since then. When I thought that binutils would be the more difficult issue to deal with, it appears that it maybe will be gcc. Messing up with a compiler toolchain is not so easy :-P

So, I'll try to grab every patches for gcc, understand them, and try to merge them together. That's not gonna be an easy task though :) I'll look at this ps2stuff more intensively later. Thanks for the link :)
_________________
pixel: A mischievous magical spirit associated with screen displays. The computer industry has frequently borrowed from mythology. Witness the sprites in computer graphics, the demons in artificial intelligence and the trolls in the marketing department.

[OptiRoc]

I believe the first patches originated from Cygnus (Red Hat), who wrote them for SN Systems' original PS2 SDK's in 1999. It would seem that Dylan Cuthbert's VU0 patches also filtered down to the PS2dev community, according to this:

http://ps2dev.sourceforge.net/hypermail-past/0009.html

So I reckon the VU0 macro-mode functionality may very well be in the current patches (can't try it out for the moment). Someone care to set the record straight? Blackdroid?

[MrHTFord]

Hi Pixel,

Good to hear someone's working on toolchain issues.

What are your plans for gcc? When you say gcc's moved on a lot, are you refering to 3.2.2 against 3.4? The mips side of gcc was completely re-written for 3.4. It's much cleaner than before, and integrating the patch would require understanding the whole patch.

Personally, I'd like to see the bugs ironed out of the current patchsets before we port them to later versions. I've got a zip file with a test case of the .bss align bug.

If I can be of any help, let me know.

[mrbrown]

[mrbrown]

[mrbrown]

[pixel]

[pixel]

[OptiRoc]

[Guest]