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.

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.

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).

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. :)

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 >_<

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 >_<
>

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?

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.

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.

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.