On 18 Oct 2015 9:45 am, "Vladimir Panteleev via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 18 October 2015 at 07:37:55 UTC, Iain Buclaw wrote:
>>
>> Essentially, the reason D has not been ported to X has nothing to do
with lack of compiler support.  A compiler can always be built to target X, and if that wasn't enough, there are many ready built packages available that target X.
>>
>> It is now your job as porters to fix up druntime to allow a library to
be built by these compilers.
>
>
> That's not very useful. LDC and GDC still include Phobos and Druntime.
>

It is infinitely more useful than having no compiler at all to test porting changes.

> You're essentially saying that once LDC gets Android/iOS support, GDC
will automatically get it as well with no effort required from you?
>

In it's runtime? Correct - assuming no one invents any new predefined version conditions in the process. :-)

Am Sun, 18 Oct 2015 09:55:52 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 18 Oct 2015 9:45 am, "Vladimir Panteleev via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
> >
> > On Sunday, 18 October 2015 at 07:37:55 UTC, Iain Buclaw wrote:
> >>
> >> Essentially, the reason D has not been ported to X has nothing to do
> with lack of compiler support.  A compiler can always be built to target X, and if that wasn't enough, there are many ready built packages available that target X.
> >>
> >> It is now your job as porters to fix up druntime to allow a library to
> be built by these compilers.
> >
> >
> > That's not very useful. LDC and GDC still include Phobos and Druntime.
> 
> It is infinitely more useful than having no compiler at all to test porting changes.
> 
> > You're essentially saying that once LDC gets Android/iOS support, GDC
> will automatically get it as well with no effort required from you?
> > 
> 
> In it's runtime? Correct - assuming no one invents any new predefined version conditions in the process. :-)
> 

Generally speaking the nice thing about the GCC backend is that as frontend developers we don't have to care much about the target architecture. Porting the compiler to a new architecture is usually trivial, the only exception being bugs in our frontend which only manifest for specific backends.

I guess it's similar for LDC. Porting D to a new architecture is really mostly porting druntime and phobos. Progress is slow however, as the LDC and GDC teams don't really have the ressources to do this in addition to compiler support and the DMD team OTOH only supports X86.

As the test suite requires drutime and phobos, there's however no reliable way to estimate how stable a compiler really is without having a druntime/phobos port.



Android is a kinda special case. I had another look at Android/ARM with GDC some time ago and after fixing a few regressions (missing version(Android) in the arm unwinder) it passed the druntime unittests on my mobile phone. As Joakim has fixed most druntime parts and GDC gained emulated TLS some time ago this is not surprising.

Phobos tests however, immediately segfaulted. The reason is the way we detect data sections. The fix is complicated but as this code will be rewritten once GDC has shared library support there's no need to fix this now.

TLDR: We're not far from Android/ARM support in GDC. Once we have
shared library support there's not much left*. And there are some good
news: I recently learned something new about the binutils linker
from Martin Nowak (regarding _start/_end symbols for named
sections). This hopefully means we'll have shared library support soon
in GDC. I'll 'just' have to update my old pull request...


* From a compiler/runtime perspective. I agree that 'Android
  support' should also include bindings/wrappers for various android
  functions and tutorials. But that's not my department ;-)

On 2015-10-18 09:55, Iain Buclaw via Digitalmars-d wrote:

> In it's runtime? Correct - assuming no one invents any new predefined
> version conditions in the process. :-)

I'm pretty sure Dan has added/is planning to add new version identifiers for iOS. It might be that the OSX version identifier is enabled as well.

-- 
/Jacob Carlborg

On Sunday, 18 October 2015 at 16:00:11 UTC, Jacob Carlborg wrote:
> On 2015-10-18 09:55, Iain Buclaw via Digitalmars-d wrote:
>
>> In it's runtime? Correct - assuming no one invents any new predefined
>> version conditions in the process. :-)
>
> I'm pretty sure Dan has added/is planning to add new version identifiers for iOS. It might be that the OSX version identifier is enabled as well.

New predefined versions are not a problem for any of the D compilers.  There's just been some of the usual bikeshedding about how many to add for new platforms and what exactly to call them.

On Sunday, 18 October 2015 at 07:56:02 UTC, Iain Buclaw wrote:
> On 18 Oct 2015 9:45 am, "Vladimir Panteleev via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>>
>> On Sunday, 18 October 2015 at 07:37:55 UTC, Iain Buclaw wrote:
>>>
>>> Essentially, the reason D has not been ported to X has nothing to do
> with lack of compiler support.  A compiler can always be built to target X, and if that wasn't enough, there are many ready built packages available that target X.
>>>
>>> It is now your job as porters to fix up druntime to allow a library to
> be built by these compilers.
>>
>>
>> That's not very useful. LDC and GDC still include Phobos and Druntime.
>>
>
> It is infinitely more useful than having no compiler at all to test porting changes.

That's not what I meant. Aside from the compiler, LDC and GDC include the runtime, standard library, probably documentation etc. They come as a complete package.

>> You're essentially saying that once LDC gets Android/iOS support, GDC
> will automatically get it as well with no effort required from you?
>>
>
> In it's runtime? Correct - assuming no one invents any new predefined version conditions in the process. :-)

No, not just the runtime. Surely the runtime contains some compiler/linker/toolchain-specific things... intrinsics, linker scripts, section names, predefined versions, assembler syntax... some of these might be platform/architecture-independent but surely not all?

On 19 Oct 2015 10:50 pm, "Vladimir Panteleev via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 18 October 2015 at 07:56:02 UTC, Iain Buclaw wrote:
>>
>> On 18 Oct 2015 9:45 am, "Vladimir Panteleev via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>>>
>>>
>>> On Sunday, 18 October 2015 at 07:37:55 UTC, Iain Buclaw wrote:
>>>>
>>>>
>>>> Essentially, the reason D has not been ported to X has nothing to do
>>
>> with lack of compiler support.  A compiler can always be built to target
X, and if that wasn't enough, there are many ready built packages available that target X.
>>>>
>>>>
>>>> It is now your job as porters to fix up druntime to allow a library to
>>
>> be built by these compilers.
>>>
>>>
>>>
>>> That's not very useful. LDC and GDC still include Phobos and Druntime.
>>>
>>
>> It is infinitely more useful than having no compiler at all to test
porting changes.
>
>
> That's not what I meant. Aside from the compiler, LDC and GDC include the
runtime, standard library, probably documentation etc. They come as a complete package.
>
>>> You're essentially saying that once LDC gets Android/iOS support, GDC
>>
>> will automatically get it as well with no effort required from you?
>>>
>>>
>>
>> In it's runtime? Correct - assuming no one invents any new predefined
version conditions in the process. :-)
>
>
> No, not just the runtime. Surely the runtime contains some
compiler/linker/toolchain-specific things... intrinsics, linker scripts, section names, predefined versions, assembler syntax... some of these might be platform/architecture-independent but surely not all?
>

As a compiler (and only a frontend language at that) I care very little about any of that.  Apart from predefined versions which are exposed to the language user code, making the rest work is Someone Else's Problem™

Iain.

On Monday, 19 October 2015 at 20:59:37 UTC, Iain Buclaw wrote:
> As a compiler (and only a frontend language at that) I care very little about any of that.  Apart from predefined versions which are exposed to the language user code, making the rest work is Someone Else's Problem™

That's what I meant when I said "not very useful" :)

Well, if you say you're responsible for the compiler and the compiler only, then who is responsible for GDC the package, the one that contains Phobos and Druntime? Who tests these packages to make sure that they all work together? Who packages and uploads them to the website?

On 19 Oct 2015 11:15 pm, "Vladimir Panteleev via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Monday, 19 October 2015 at 20:59:37 UTC, Iain Buclaw wrote:
>>
>> As a compiler (and only a frontend language at that) I care very little
about any of that.  Apart from predefined versions which are exposed to the language user code, making the rest work is Someone Else's Problem™
>
>
> That's what I meant when I said "not very useful" :)
>
> Well, if you say you're responsible for the compiler and the compiler
only, then who is responsible for GDC the package, the one that contains Phobos and Druntime? Who tests these packages to make sure that they all work together? Who packages and uploads them to the website?
>

In order:
You are responsible, the library maintainers (I chip in a bit on the side
when I have the hardware / virtual environment).
You are responsible, the authors and reviewers of the testsuite and
unittests.
Johannes packages and uploads them.

I wouldn't refer to them as official, but they are officially enough to use where building yourself is difficult - Continuous integration platforms , Embedded targets, Windows in general, etc.

On Monday, 19 October 2015 at 20:47:55 UTC, Vladimir Panteleev wrote:
> No, not just the runtime. Surely the runtime contains some compiler/linker/toolchain-specific things... intrinsics, linker scripts, section names, predefined versions, assembler syntax... some of these might be platform/architecture-independent but surely not all?

There also was a question how one can help knowing nothing about compiler development. Then a working compiler would make sense.

On Monday, 19 October 2015 at 21:24:00 UTC, Iain Buclaw wrote:
> In order:
> You are responsible, the library maintainers (I chip in a bit on the side
> when I have the hardware / virtual environment).
> You are responsible, the authors and reviewers of the testsuite and
> unittests.

Who is this "You", specifically?

If I run into a bug with GDC on a specific platform/architecture, who am I supposed to talk to? With DMD/Phobos bugs I can at least use "git blame".

Also, are you saying that it is every Phobos/Druntime contributor's responsibility to make sure that their changes are GDC-compatible? Other than the Travis auto-tester which seems to be failing half the time, we don't have any CI or any tests at all for GDC!