www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can D get on XBone and PS4?

reply "Joakim" <dlang joakim.fea.st> writes:
I just stumbled across this article from a year ago, which says 
the PS4 toolchain is based on llvm/clang:

http://www.phoronix.com/scan.php?page=news_item&px=MTU1MTY

I know some here were excited about the possibility of getting D 
on the new consoles since they were switching to x86, but is that 
really possible?  I googled other alternative compiled languages 
combined with playstation 4 and found... nothing.

I don't know if Sony/Microsoft put in legal roadblocks to using 
anything other than the officially supported languages for game 
development on their consoles.  If not, this could be a good way 
to differentiate D, especially given the current nogc focus.

Perhaps Manu or one of the the other game developers can comment 
on the feasibility of getting D on the major consoles.
Jan 17 2015
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 18 January 2015 at 16:48, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 I just stumbled across this article from a year ago, which says the PS4
 toolchain is based on llvm/clang:

 http://www.phoronix.com/scan.php?page=news_item&px=MTU1MTY

 I know some here were excited about the possibility of getting D on the new
 consoles since they were switching to x86, but is that really possible?  I
 googled other alternative compiled languages combined with playstation 4 and
 found... nothing.

 I don't know if Sony/Microsoft put in legal roadblocks to using anything
 other than the officially supported languages for game development on their
 consoles.  If not, this could be a good way to differentiate D, especially
 given the current nogc focus.

 Perhaps Manu or one of the the other game developers can comment on the
 feasibility of getting D on the major consoles.


At Remedy, we ran D code on xbone with no opposition from MS.
For xbone, we wanted to maintain compatibility with the rest of our
MSVC code, which meant we needed to produce COFF output that the MSVC
linker accepts. Walter implemented DMD-Win64 with these requirements
in mind.
PS4 should be easier using LDC, but I don't know if Sony would take
issue with this. I expect them to take less issue than MS, so I'd give
good odd's that they'd be fine with it.

Short answer, D works on modern consoles just fine, and there were no
political blocks for us. GC is a demonstrated problem; avoid it. DMD's
codegen is also a problem; it uses x87 to perform operations, despite
the fact the x64 ABI uses SSE regs for float passing. That results in
a lot of register switching, and poor float performance as a result.
As an (awkward) workaround, you can use explicit SSE intrinsics to
keep working in XMM, but I haven't tested the optimiser's quality in
that case, and the std library obviously doesn't do that.
Jan 18 2015
parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via 
Digitalmars-d wrote:

 At Remedy, we ran D code on xbone with no opposition from MS.
 For xbone, we wanted to maintain compatibility with the rest of 
 our
 MSVC code, which meant we needed to produce COFF output that 
 the MSVC
 linker accepts. Walter implemented DMD-Win64 with these 
 requirements
 in mind.
 PS4 should be easier using LDC, but I don't know if Sony would 
 take
 issue with this. I expect them to take less issue than MS, so 
 I'd give
 good odd's that they'd be fine with it.

 Short answer, D works on modern consoles just fine, and there 
 were no
 political blocks for us. GC is a demonstrated problem; avoid 
 it. DMD's
 codegen is also a problem; it uses x87 to perform operations, 
 despite
 the fact the x64 ABI uses SSE regs for float passing. That 
 results in
 a lot of register switching, and poor float performance as a 
 result.
 As an (awkward) workaround, you can use explicit SSE intrinsics 
 to
 keep working in XMM, but I haven't tested the optimiser's 
 quality in
 that case, and the std library obviously doesn't do that.


Thanks for the detailed answer.  Sounds like the only thing 
holding D back is someone putting in the effort to integrate it 
with the console runtime and APIs.  It's not going to be me, as I 
haven't owned a console or even played a console game in a 
decade.  Yes, I know I'm an old fogey. :)
Jan 18 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 18 January 2015 at 19:56, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote:

 At Remedy, we ran D code on xbone with no opposition from MS.
 For xbone, we wanted to maintain compatibility with the rest of our
 MSVC code, which meant we needed to produce COFF output that the MSVC
 linker accepts. Walter implemented DMD-Win64 with these requirements
 in mind.
 PS4 should be easier using LDC, but I don't know if Sony would take
 issue with this. I expect them to take less issue than MS, so I'd give
 good odd's that they'd be fine with it.

 Short answer, D works on modern consoles just fine, and there were no
 political blocks for us. GC is a demonstrated problem; avoid it. DMD's
 codegen is also a problem; it uses x87 to perform operations, despite
 the fact the x64 ABI uses SSE regs for float passing. That results in
 a lot of register switching, and poor float performance as a result.
 As an (awkward) workaround, you can use explicit SSE intrinsics to
 keep working in XMM, but I haven't tested the optimiser's quality in
 that case, and the std library obviously doesn't do that.



 Thanks for the detailed answer.  Sounds like the only thing holding D back
 is someone putting in the effort to integrate it with the console runtime
 and APIs.  It's not going to be me, as I haven't owned a console or even
 played a console game in a decade.  Yes, I know I'm an old fogey. :)


I don't think there's any particularly compelling reason to make
runtime calls from D. You can link C/C++ and D code together just
fine. If you're a gamedev, there's a very high chance that you already
have an engine (presumably C/C++) in place. You'll need to bind the
engine api, not the OS api.
Trouble with the console OS api's are that they're protected by NDA;
it would probably be pretty dubious to release any such foreign
language binding here, so each studio would have to do that work
themselves... unless it were posted on the official dev forums or
something.

If I had to say there was one thing holding D back, it's Win64 support
in LLVM. We really need LDC for comprehensive gamedev. DMD is okay for
game-logic and script-like code, but the codegen isn't good enough to
do really hot work.
Win64 is almost there in LLVM, the only thing missing that I know of
is CV8 debuginfo. Without that, we can't debug... which is like,
really important >_<
Jan 18 2015
next sibling parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote:

 On 18 January 2015 at 19:56, Joakim via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote:

 At Remedy, we ran D code on xbone with no opposition from MS.
 For xbone, we wanted to maintain compatibility with the rest of our
 MSVC code, which meant we needed to produce COFF output that the MSVC
 linker accepts. Walter implemented DMD-Win64 with these requirements
 in mind.
 PS4 should be easier using LDC, but I don't know if Sony would take
 issue with this. I expect them to take less issue than MS, so I'd give
 good odd's that they'd be fine with it.

 Short answer, D works on modern consoles just fine, and there were no
 political blocks for us. GC is a demonstrated problem; avoid it. DMD's
 codegen is also a problem; it uses x87 to perform operations, despite
 the fact the x64 ABI uses SSE regs for float passing. That results in
 a lot of register switching, and poor float performance as a result.
 As an (awkward) workaround, you can use explicit SSE intrinsics to
 keep working in XMM, but I haven't tested the optimiser's quality in
 that case, and the std library obviously doesn't do that.



 Thanks for the detailed answer.  Sounds like the only thing holding D back
 is someone putting in the effort to integrate it with the console runtime
 and APIs.  It's not going to be me, as I haven't owned a console or even
 played a console game in a decade.  Yes, I know I'm an old fogey. :)


 I don't think there's any particularly compelling reason to make
 runtime calls from D. You can link C/C++ and D code together just
 fine. If you're a gamedev, there's a very high chance that you already
 have an engine (presumably C/C++) in place. You'll need to bind the
 engine api, not the OS api.
 Trouble with the console OS api's are that they're protected by NDA;
 it would probably be pretty dubious to release any such foreign
 language binding here, so each studio would have to do that work
 themselves... unless it were posted on the official dev forums or
 something.


$ dub add-local .
Could be rather useful here!


 If I had to say there was one thing holding D back, it's Win64 support
 in LLVM. We really need LDC for comprehensive gamedev. DMD is okay for
 game-logic and script-like code, but the codegen isn't good enough to
 do really hot work.
 Win64 is almost there in LLVM, the only thing missing that I know of
 is CV8 debuginfo. Without that, we can't debug... which is like,
 really important >_<
Jan 18 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 January 2015 at 09:42, Rikki Cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote:

 On 18 January 2015 at 19:56, Joakim via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote:

 At Remedy, we ran D code on xbone with no opposition from MS.
 For xbone, we wanted to maintain compatibility with the rest of our
 MSVC code, which meant we needed to produce COFF output that the MSVC
 linker accepts. Walter implemented DMD-Win64 with these requirements
 in mind.
 PS4 should be easier using LDC, but I don't know if Sony would take
 issue with this. I expect them to take less issue than MS, so I'd give
 good odd's that they'd be fine with it.

 Short answer, D works on modern consoles just fine, and there were no
 political blocks for us. GC is a demonstrated problem; avoid it. DMD's
 codegen is also a problem; it uses x87 to perform operations, despite
 the fact the x64 ABI uses SSE regs for float passing. That results in
 a lot of register switching, and poor float performance as a result.
 As an (awkward) workaround, you can use explicit SSE intrinsics to
 keep working in XMM, but I haven't tested the optimiser's quality in
 that case, and the std library obviously doesn't do that.




 Thanks for the detailed answer.  Sounds like the only thing holding D
 back
 is someone putting in the effort to integrate it with the console runtime
 and APIs.  It's not going to be me, as I haven't owned a console or even
 played a console game in a decade.  Yes, I know I'm an old fogey. :)



 I don't think there's any particularly compelling reason to make
 runtime calls from D. You can link C/C++ and D code together just
 fine. If you're a gamedev, there's a very high chance that you already
 have an engine (presumably C/C++) in place. You'll need to bind the
 engine api, not the OS api.
 Trouble with the console OS api's are that they're protected by NDA;
 it would probably be pretty dubious to release any such foreign
 language binding here, so each studio would have to do that work
 themselves... unless it were posted on the official dev forums or
 something.



 $ dub add-local .
 Could be rather useful here!


I don't know what that means?
Jan 18 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 19/01/2015 12:47 p.m., Manu via Digitalmars-d wrote:

 On 19 January 2015 at 09:42, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote:

 On 18 January 2015 at 19:56, Joakim via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d wrote:

 At Remedy, we ran D code on xbone with no opposition from MS.
 For xbone, we wanted to maintain compatibility with the rest of our
 MSVC code, which meant we needed to produce COFF output that the MSVC
 linker accepts. Walter implemented DMD-Win64 with these requirements
 in mind.
 PS4 should be easier using LDC, but I don't know if Sony would take
 issue with this. I expect them to take less issue than MS, so I'd give
 good odd's that they'd be fine with it.

 Short answer, D works on modern consoles just fine, and there were no
 political blocks for us. GC is a demonstrated problem; avoid it. DMD's
 codegen is also a problem; it uses x87 to perform operations, despite
 the fact the x64 ABI uses SSE regs for float passing. That results in
 a lot of register switching, and poor float performance as a result.
 As an (awkward) workaround, you can use explicit SSE intrinsics to
 keep working in XMM, but I haven't tested the optimiser's quality in
 that case, and the std library obviously doesn't do that.




 Thanks for the detailed answer.  Sounds like the only thing holding D
 back
 is someone putting in the effort to integrate it with the console runtime
 and APIs.  It's not going to be me, as I haven't owned a console or even
 played a console game in a decade.  Yes, I know I'm an old fogey. :)



 I don't think there's any particularly compelling reason to make
 runtime calls from D. You can link C/C++ and D code together just
 fine. If you're a gamedev, there's a very high chance that you already
 have an engine (presumably C/C++) in place. You'll need to bind the
 engine api, not the OS api.
 Trouble with the console OS api's are that they're protected by NDA;
 it would probably be pretty dubious to release any such foreign
 language binding here, so each studio would have to do that work
 themselves... unless it were posted on the official dev forums or
 something.



 $ dub add-local .
 Could be rather useful here!


 I don't know what that means?


You don't need to register packages of the dub repository for dub to be 
able to use a package. In this case its registered locally instead.
In terms of NDA's, can definitely be used to make e.g. wrappers of 
bindings private and then use them to publically distribute the usage of 
them.
Jan 18 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 19 January 2015 at 09:50, Rikki Cattermole via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 19/01/2015 12:47 p.m., Manu via Digitalmars-d wrote:

 On 19 January 2015 at 09:42, Rikki Cattermole via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:

 On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote:

 On 18 January 2015 at 19:56, Joakim via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d
 wrote:

 At Remedy, we ran D code on xbone with no opposition from MS.
 For xbone, we wanted to maintain compatibility with the rest of our
 MSVC code, which meant we needed to produce COFF output that the MSVC
 linker accepts. Walter implemented DMD-Win64 with these requirements
 in mind.
 PS4 should be easier using LDC, but I don't know if Sony would take
 issue with this. I expect them to take less issue than MS, so I'd give
 good odd's that they'd be fine with it.

 Short answer, D works on modern consoles just fine, and there were no
 political blocks for us. GC is a demonstrated problem; avoid it. DMD's
 codegen is also a problem; it uses x87 to perform operations, despite
 the fact the x64 ABI uses SSE regs for float passing. That results in
 a lot of register switching, and poor float performance as a result.
 As an (awkward) workaround, you can use explicit SSE intrinsics to
 keep working in XMM, but I haven't tested the optimiser's quality in
 that case, and the std library obviously doesn't do that.





 Thanks for the detailed answer.  Sounds like the only thing holding D
 back
 is someone putting in the effort to integrate it with the console
 runtime
 and APIs.  It's not going to be me, as I haven't owned a console or
 even
 played a console game in a decade.  Yes, I know I'm an old fogey. :)




 I don't think there's any particularly compelling reason to make
 runtime calls from D. You can link C/C++ and D code together just
 fine. If you're a gamedev, there's a very high chance that you already
 have an engine (presumably C/C++) in place. You'll need to bind the
 engine api, not the OS api.
 Trouble with the console OS api's are that they're protected by NDA;
 it would probably be pretty dubious to release any such foreign
 language binding here, so each studio would have to do that work
 themselves... unless it were posted on the official dev forums or
 something.




 $ dub add-local .
 Could be rather useful here!



 I don't know what that means?



 You don't need to register packages of the dub repository for dub to be able
 to use a package. In this case its registered locally instead.
 In terms of NDA's, can definitely be used to make e.g. wrappers of bindings
 private and then use them to publically distribute the usage of them.


...I don't follow.
Jan 18 2015
parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 19/01/2015 5:13 p.m., Manu via Digitalmars-d wrote:

 On 19 January 2015 at 09:50, Rikki Cattermole via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On 19/01/2015 12:47 p.m., Manu via Digitalmars-d wrote:

 On 19 January 2015 at 09:42, Rikki Cattermole via Digitalmars-d

 <digitalmars-d puremagic.com> wrote:

 On 19/01/2015 12:39 p.m., Manu via Digitalmars-d wrote:

 On 18 January 2015 at 19:56, Joakim via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Sunday, 18 January 2015 at 08:06:06 UTC, Manu via Digitalmars-d
 wrote:

 At Remedy, we ran D code on xbone with no opposition from MS.
 For xbone, we wanted to maintain compatibility with the rest of our
 MSVC code, which meant we needed to produce COFF output that the MSVC
 linker accepts. Walter implemented DMD-Win64 with these requirements
 in mind.
 PS4 should be easier using LDC, but I don't know if Sony would take
 issue with this. I expect them to take less issue than MS, so I'd give
 good odd's that they'd be fine with it.

 Short answer, D works on modern consoles just fine, and there were no
 political blocks for us. GC is a demonstrated problem; avoid it. DMD's
 codegen is also a problem; it uses x87 to perform operations, despite
 the fact the x64 ABI uses SSE regs for float passing. That results in
 a lot of register switching, and poor float performance as a result.
 As an (awkward) workaround, you can use explicit SSE intrinsics to
 keep working in XMM, but I haven't tested the optimiser's quality in
 that case, and the std library obviously doesn't do that.





 Thanks for the detailed answer.  Sounds like the only thing holding D
 back
 is someone putting in the effort to integrate it with the console
 runtime
 and APIs.  It's not going to be me, as I haven't owned a console or
 even
 played a console game in a decade.  Yes, I know I'm an old fogey. :)




 I don't think there's any particularly compelling reason to make
 runtime calls from D. You can link C/C++ and D code together just
 fine. If you're a gamedev, there's a very high chance that you already
 have an engine (presumably C/C++) in place. You'll need to bind the
 engine api, not the OS api.
 Trouble with the console OS api's are that they're protected by NDA;
 it would probably be pretty dubious to release any such foreign
 language binding here, so each studio would have to do that work
 themselves... unless it were posted on the official dev forums or
 something.




 $ dub add-local .
 Could be rather useful here!



 I don't know what that means?



 You don't need to register packages of the dub repository for dub to be able
 to use a package. In this case its registered locally instead.
 In terms of NDA's, can definitely be used to make e.g. wrappers of bindings
 private and then use them to publically distribute the usage of them.


 ...I don't follow.


Because of an NDA's, we may not be able to release bindings to the 
native API's but we can release wrapper interfaces. So long as they are 
not one for one. Atleast theoretically.
Assuming the bindings/wrapper implementation is distributed via official 
means e.g. a forum which is non public and approved of.
Dub could be used, as the build manager for any projects using the 
bindings. As long as when the bindings/wrappers are released, they are 
built as dub packages.
Once downloaded they merely need to be added as a local package into 
dub. Ensuring NDA and the ability to public publically engines and such.
Jan 18 2015
prev sibling parent reply "Joakim" <dlang joakim.fea.st> writes:
On Sunday, 18 January 2015 at 23:39:44 UTC, Manu via 
Digitalmars-d wrote:

 I don't think there's any particularly compelling reason to make
 runtime calls from D. You can link C/C++ and D code together 
 just
 fine. If you're a gamedev, there's a very high chance that you 
 already
 have an engine (presumably C/C++) in place. You'll need to bind 
 the
 engine api, not the OS api.
 Trouble with the console OS api's are that they're protected by 
 NDA;
 it would probably be pretty dubious to release any such foreign
 language binding here, so each studio would have to do that work
 themselves... unless it were posted on the official dev forums 
 or
 something.


Hmm, those NDAs probably explain why no other alternative 
compiled language advertises native console support.


 If I had to say there was one thing holding D back, it's Win64 
 support
 in LLVM. We really need LDC for comprehensive gamedev. DMD is 
 okay for
 game-logic and script-like code, but the codegen isn't good 
 enough to
 do really hot work.
 Win64 is almost there in LLVM, the only thing missing that I 
 know of
 is CV8 debuginfo. Without that, we can't debug... which is like,
 really important >_<


Well, you're in luck, as the llvm devs just announced the 
beginnings of better debug and lldb support for Windows on the 
llvm blog: :)

http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html
Jan 20 2015
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 21 January 2015 at 14:10, Joakim via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Sunday, 18 January 2015 at 23:39:44 UTC, Manu via Digitalmars-d wrote:

 I don't think there's any particularly compelling reason to make
 runtime calls from D. You can link C/C++ and D code together just
 fine. If you're a gamedev, there's a very high chance that you already
 have an engine (presumably C/C++) in place. You'll need to bind the
 engine api, not the OS api.
 Trouble with the console OS api's are that they're protected by NDA;
 it would probably be pretty dubious to release any such foreign
 language binding here, so each studio would have to do that work
 themselves... unless it were posted on the official dev forums or
 something.



 Hmm, those NDAs probably explain why no other alternative compiled language
 advertises native console support.


 If I had to say there was one thing holding D back, it's Win64 support
 in LLVM. We really need LDC for comprehensive gamedev. DMD is okay for
 game-logic and script-like code, but the codegen isn't good enough to
 do really hot work.
 Win64 is almost there in LLVM, the only thing missing that I know of
 is CV8 debuginfo. Without that, we can't debug... which is like,
 really important >_<



 Well, you're in luck, as the llvm devs just announced the beginnings of
 better debug and lldb support for Windows on the llvm blog: :)

 http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html


Super awesome!
Does LLDB have any support for D though?
Jan 21 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-01-21 10:28, Manu via Digitalmars-d wrote:


 Super awesome!
 Does LLDB have any support for D though?


No, not that I've heard of :(

-- 
/Jacob Carlborg
Jan 21 2015
prev sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 18 January 2015 at 06:48:45 UTC, Joakim wrote:

 I just stumbled across this article from a year ago, which says 
 the PS4 toolchain is based on llvm/clang:

 http://www.phoronix.com/scan.php?page=news_item&px=MTU1MTY

 I know some here were excited about the possibility of getting 
 D on the new consoles since they were switching to x86, but is 
 that really possible?  I googled other alternative compiled 
 languages combined with playstation 4 and found... nothing.

 I don't know if Sony/Microsoft put in legal roadblocks to using 
 anything other than the officially supported languages for game 
 development on their consoles.  If not, this could be a good 
 way to differentiate D, especially given the current nogc focus.

 Perhaps Manu or one of the the other game developers can 
 comment on the feasibility of getting D on the major consoles.


If you want to know more about it,check the LLVM talks:

http://llvm.org/devmtg/

Many of them have talks from either Sony or CodePlay (also does
PS compilers).
Jan 18 2015