ldc
ldc copied to clipboard
ldc-developers
Fix issue 3363: Support PS4
Theres some LTO stuff that I haven't changed yet, because I assume that you will be doing the linking manually.
Wow, that was fast! Yeah, we'll link externally.
I don't understand how this works, is that a method from llvm? How does this patch stop the error I was seeing? And what are the proper args to build a PS4 binary?
Yeah, we'll link externally.
Good.
is that a method from llvm?
Yes. https://llvm.org/doxygen/Triple_8h_source.html#l00655
How does this patch stop the error I was seeing?
Ah, I forgot that one. Done, see line 846 of the diff.
And what are the proper args to build a PS4 binary?
Dunno. You obviously need to supply -mtriple=x86_64-scei-ps4. Hopefully that should be all that is needed.
That should target the system, but do you reckon that triple will drive defaults for the CPU and potential other build flags, or do I need to collect the proper set and supply them all manually?
I would suspect the LLVM would do that for you, but that is only a suspicion. Either way it will be the same as for what clang does. If you specify it for that I would presume that you also need it for LDC.
Well the official compiler is built configured as default. You don't specify anything to that compiler. We need to match all the flags they enable by default I guess.
can you post the result of clang -v (and clang -### if it i different)?
- There's a reserved
PS4version. - The target CPU should probably default to
btver2. - Linking should work with LDC too, like any other target. So specifying the SDK clang as
-gccoption should be enough; @TurkeyMan: please test and e.g. see if we have to modify the hardcoded C libs. - Manu: I assume you can run and test console processes on the device/simulator. In that case, building the druntime/Phobos test runners via ldc-build-runtime and running them would be very helpful.
There's a reserved PS4 version.
OK, we should probably still set version(FreeBSD) though, since it is a FreeBSD.
The target CPU should probably default to btver2
How do I do that?
OK, we should probably still set version(FreeBSD) though, since it is a FreeBSD.
Of course, otherwise adapting druntime/Phobos would be very much fun.
How do I do that?
https://github.com/ldc-developers/ldc/blob/bdb613d0ad81c40a13ece387709b91d8d6deb1e2/driver/targetmachine.cpp#L120-L126
There are more FreeBSD cases, e.g., https://github.com/ldc-developers/ldc/blob/bdb613d0ad81c40a13ece387709b91d8d6deb1e2/gen/target.cpp#L69-L72
- There's a reserved
PS4version.
Apparently the decision landed on PlayStation4 instead of PS4.
https://dlang.org/spec/version.html#predefined-versions
That way PlayStation5 will also have the common PlayStation version for PSx general code that doesn't care which one?
Of course, but this is still very much WIP. I'll be waiting to get the green light from Manu and Pursche and then polish this up.
That way PlayStation5 will also have the common PlayStation version for PSx general code that doesn't care which one?
IMO, PlayStation as a generalization for all PS consoles is useless; AFAIK, the used hardware (no idea about the software) has changed dramatically over the years. And we'll yet have to see whether there's a justification for any PS reserved version at all, if it's really nothing but a FreeBSD on specific x64 CPUs.
I find it pretty much incredible that there's PlayStation[4], but darwin is still deprecated (but would be very useful for recent iOS-derived platforms support, as there are hardly any relevant divergences across Darwin-based flavors for a specific bitness).
That way PlayStation5 will also have the common PlayStation version for PSx general code that doesn't care which one?
IMO,
PlayStationas a generalization for all PS consoles is useless; AFAIK, the used hardware (no idea about the software) has changed dramatically over the years. And we'll yet have to see whether there's a justification for any PS reserved version at all, if it's really nothing but a FreeBSD on specific x64 CPUs.I find it pretty much incredible that there's
PlayStation[4], butdarwinis still deprecated (but would be very useful for recent iOS-derived platforms support, as there are hardly any relevant divergences across Darwin-based flavors for a specific bitness).
I can tell you that it definitely isn't "just" FreeBSD on specific x64 CPUs, I expect to have to make significant changes to the DRuntime when it comes to threading, networking and possibly memory.
Of course, but this is still very much WIP. I'll be waiting to get the green light from Manu and Pursche and then polish this up.
I was trying to remind you that you should build up your testcase along with the code you are writing. ;-) Forces you to think a little harder about all the changes needed, and also points review to cases to look into.
@thewilsonator It's a pity this PR has not been merged yet. Can you address the comments and patch it up?
I have been made aware that there has been internal discussions between Sony and a developer about running Rust on PS4/5 by having their LLVM based compiler output LLVM IR, and then finishing compilation with the provided Sony specific toolchain.
The outcome of the discussion was Sony telling the developer that combining a custom LLVM front end via LLVM IR is not allowed because it is likely to break with the customized ABI. There is also a specific technical requirement (that you need to pass to get certified before release) which prohibits using anything but the provided toolchain.
The suggested "workaround" seems to be to cross-compile to C/C++ first, and then compile using the full toolchain, but I don't know how viable that sounds.