Official support for the PlayStation 2 EE FPU - did it ever exist?

Hi all,

Over the past months, I have been trying to complete support for the MIPS R5900 (the Emotion Engine) within GCC. With the help of the folks there, I've been able to add support for the 2nd integer arithmetic pipeline, MMI, and provide 128-bit loads and stores to boost memory-copying operations.

However, there is one part that I haven't figured out how to implement yet: support for the FPU. Regardless of how I do it, GCC doesn't seem to want to use the newly-added FPU accumulator register (and hence the new instruction patterns).

The homebrew EE GCC v3.2.2 port has no support for the FPU instructions, despite what its README file says. I don't have access to a working installation of other EE GCC compiler (official or not), so I don't have any idea whether this can even be implemented or how it can be done.

Does anyone know whether SONY ever supported the FPU in its official EE GCC compilers? I am not only referring to the one used for developing games, but the one that came with PS2Linux. The documentation doesn't seem to mention this.

Thanks in advance!

EDIT: It probably isn't possible because there is no way to preserve the content of $ACC. As a result, other threads and interrupt handlers are able to overwrite its content, in the middle of a chain of MADDs or MSUBs. Hence it is unlikely that SONY would have supported it within GCC.

The PS2Linux EE GCC patch does not seem to have support for it either.

 

Sony should have released the GNU sources right?

 

Thanks. It's probably buried somewhere, which I probably don't have legal access to. At least, I don't know where they might have distributed it, if they did. The one that comes with PS2Linux had its sources released though.

I got a dump of the PS2Linux beta disc, but its GCC does not seem to support the FPU. However, it is possible that they had several versions of GCC made.

There's also one more thing that bothers me now: the manual mentions that the FPU has a bug, whereby placing the division instructions in certain places (around branches and their destinations) may result in the result value getting stuck to a certain value. Our existing GCC v3.2.2 port has no workaround for this, neither does the GCC patch that Mega Man committed (to GCC) in 2012.
The late (v3.0.3) SCE PS2SDK mentions that they were still implementing a workaround within Binutils. So does this mean that they never worked around it?
The exact chip revisions affected was not disclosed, although one file mentioned that it affects the one mounted on the DTL-T10000(H).

 

I know a guy that worked at SCEE around the PS2Linux time, I'll ask if he has anything useful.
I found some interesting links
http://psx-scene.com/forums/f167/blackrhino-gnu-linux-lets-remember-how-111488/
https://github.com/jur/linux-2.2.1-ps2/tree/master/Documentation

 

Thanks. Although I am already pretty satisfied with my own reasoning behind support for the FPU instructions, I'm still keen to know whether the bugs in the FPU were worked around or not.

Thanks, but I'm not actually involved with the PS2Linux porting effort. I'm just completing support for the R5900 within GCC, mainly for the normal PS2SDK.
Given that it was also made to target Linux, the new PS2Linux ports should benefit from the implementation of support for the EE core extensions.

 

You can read the accumulator with a madd instruction (add zero to it) and set the accumulator with a mul instruction (value * 1). So it should be possible to preserve it, although it is of course possible that they do not. I'd be quite surprised if it's not preserved, because it wouldn't be safe to use from assembler either & they do appear to support that http://www.hsfortuna.pwp.blueyonder.co.uk/asm/asm.htm

http://web.archive.org/web/20070630145927/http://cosmos.raunvis.hi.is/~johannos/mips/sparky.html
"By the way GCC for ps2/ps2linux doesn't know how to use the accumulator instructions"

I suspect GCC just didn't have a good idea how to identify C code that could be turned into multiply add instructions. Similar to how it took a while before compilers could identify code that could be turned into SSE instructions.

 

I remembered seeing an official Sony site with sources for their use of Open Source software; however I couldn't find anything for PS2.
In case you want to look at them:
http://oss.sony.net/Products/Linux/common/search.html
https://products.sel.sony.com/opensource/
(There may be others, but that's what I could find with a quick google-fu.)
Also tried them via archive.org; only Playstation related page in them seems to be for BB-Nav.

Maybe newer patches for PS2Linux released via the playstation2-linux.com site? I remember someone shared an archive of that site here on AG.

 

If Sony had a GCC/binutils port that was used for official PS2 development, they would only have to share the source code to that version of GCC with the people who they shared the binaries with (i.e. PS2 developers) and not the entire world.
The GCC that went with the PS2 Linux stuff would have to be shared with anyone who got the Linux kit though (which means it should be out there in the public space)

 

Thank you all for your input.

It is true that there are ways to preserve and restore the contents of the accumulator register, but there isn't an explicit instruction for that - so it is possible that Toshiba/SONY never intended it to be preserved. That's what I meant.
It's because there isn't a $zero register in the FPU. If an immediate value is required, then it has to be first loaded into a GPR, before being loaded from the GPR into a FPU register.

I haven't confirmed this yet, but I really don't remember seeing SONY preserve the contents of that accumulator register in the EE kernel. So even if it is possible to implement support for it within GCC, it wouldn't be safe to use it for regular
PlayStation 2 development.
If it is implemented within PS2Linux, then it is possibly a PS2Linux-only thing because PS2Linux replaces the EEkernel.

@smf: GCC can identify when to use MADD and MADD.S, but somehow just can't do that when the FPU accumulator comes into play (the regular MADD.S instruction uses FPU registers directly). I suspect that GCC isn't that intelligent, especially when there isn't a direct way to move the value between FP registers and the accumulator. Either that, or it was a problem with the way that I set up the new register.

 

If no other cpu has instructions that fit the same pattern then I suspect it's going to be an uphill struggle. Looking at the source for https://github.com/gcc-mirror/gcc/blob/master/gcc/config/mips/mips.c , I suspect because of the hidden register that where normally it just needs to identify the add and multiply and output one instruction, you'd have to identify all of them and output a sequence of instructions (start with a mula.s then madd.s until the final madda.s).

 

Thanks. But I want it accepted by the GCC folks, so it cannot be butchered up for the sake of only the R5900 (not that I find that an easy thing to do anyway!).

I added the ACC register, so GCC knows that it is there. But perhaps because I set it as a FIXED REGISTER, so GCC doesn't ever allocate it. But if I didn't do that, then GCC would spew Internal Compiler Errors (ICEs) because there is no way to preserve/restore its content.
Anyway, given that the EE kernel doesn't support the FPU, it is not safe for GCC to be automatically generating code that uses the FPU because its content may get overwritten by other threads and interrupt handlers.