On 4 April 2015 at 00:46, weaselcat via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote:
>>
>> On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote:
>>>
>>> The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think.
>>
>>
>> Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow.
>
>
> The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.)
>

Summary of sources in first link, those familiar with DMD internals will understand what the glue methods more or less do.

http://gdcproject.org/documentation/

Only coding guidelines are the rough notes in the link below, and that all changes should be reported in the relevant ChangeLog entry.

https://gcc.gnu.org/codingconventions.html#CandCxx

I'd expect things to change dramatically in the future though what with all these glue methods now gone (thanks yebblies), and the new glue Visitor's giving free reign on compiler backend's to simplify and lower the entry barrier for potential new contributors.

Regards
Iain.

On Friday, 3 April 2015 at 21:59:38 UTC, Kai Nacke wrote:
> On Friday, 3 April 2015 at 18:04:14 UTC, deadalnix wrote:
>> Also, what are the plan for GDC and LDC if we move toward DDMD ?
>
> My plan with LDC is to use the CPP backend to produce a boot strap compiler and then compile the D source. Much work...
>
> Regards,
> Kai

Bindings for LLVM and GCC would still have to be written/generated (and work).

Calypso could help with building D versions of GDC and LDC, H1 seems a bit early but it's shaping up.

On Friday, 3 April 2015 at 22:46:31 UTC, weaselcat wrote:
> On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote:
>> On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote:
>>> The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think.
>>
>> Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow.
>
> The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.)
>

Even if so what is the point ? That is completely wasted work. It is already done elsewhere.

That is aggravated pathological NIH syndrome right there.

On Friday, 3 April 2015 at 23:47:48 UTC, deadalnix wrote:
> On Friday, 3 April 2015 at 22:46:31 UTC, weaselcat wrote:
>> On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote:
>>> On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote:
>>>> The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think.
>>>
>>> Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow.
>>
>> The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.)
>>
>
> Even if so what is the point ? That is completely wasted work. It is already done elsewhere.
>
> That is aggravated pathological NIH syndrome right there.

Maybe I'm misreading, but I don't see how documentation is NIH syndrome.

On Friday, 3 April 2015 at 23:59:52 UTC, weaselcat wrote:
> On Friday, 3 April 2015 at 23:47:48 UTC, deadalnix wrote:
>> On Friday, 3 April 2015 at 22:46:31 UTC, weaselcat wrote:
>>> On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote:
>>>> On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote:
>>>>> The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think.
>>>>
>>>> Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow.
>>>
>>> The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.)
>>>
>>
>> Even if so what is the point ? That is completely wasted work. It is already done elsewhere.
>>
>> That is aggravated pathological NIH syndrome right there.
>
> Maybe I'm misreading, but I don't see how documentation is NIH syndrome.

Like always in economy, the question is compared to what ? Writing documentation on that thing, compared to what valuable use of people's time.

Considering there is no hope for this to compete with other backends in term of supported targets, the only reason you'd have to invest in there is NIH syndrome.

On Saturday, 4 April 2015 at 01:03:14 UTC, deadalnix wrote:
> On Friday, 3 April 2015 at 23:59:52 UTC, weaselcat wrote:
>> On Friday, 3 April 2015 at 23:47:48 UTC, deadalnix wrote:
>>> On Friday, 3 April 2015 at 22:46:31 UTC, weaselcat wrote:
>>>> On Friday, 3 April 2015 at 20:56:09 UTC, deadalnix wrote:
>>>>> On Friday, 3 April 2015 at 19:45:29 UTC, weaselcat wrote:
>>>>>> The reliance on GDC/LDC to produce production-level binaries(i.e, optimized) and the actual people working on them really is worrisome. If Iain or Kai decided one day to leave D, it would be a very big blow I think.
>>>>>
>>>>> Yes. And considering there is no hope that we bring dmd's backend up to speed with GCC or LLVM (let's be realistic one second) what is even more worrisome is how little they are integrated in the workflow.
>>>>
>>>> The best way to help would probably be to work on contributor guides/documentation. They don't seem to have much of either of these - or I'm blind(good possibility.)
>>>>
>>>
>>> Even if so what is the point ? That is completely wasted work. It is already done elsewhere.
>>>
>>> That is aggravated pathological NIH syndrome right there.
>>
>> Maybe I'm misreading, but I don't see how documentation is NIH syndrome.
>
> Like always in economy, the question is compared to what ? Writing documentation on that thing, compared to what valuable use of people's time.
>
> Considering there is no hope for this to compete with other backends in term of supported targets, the only reason you'd have to invest in there is NIH syndrome.

I was referring to LDC and/or GDC.

On Friday, 3 April 2015 at 16:41:14 UTC, David Nadlinger wrote:
> On Friday, 3 April 2015 at 15:07:57 UTC, Andrei Alexandrescu wrote:
>> On 4/3/15 3:10 AM, Andrea Fontana wrote:
>>> It would be great to have dmd on embedded platforms.
>>
>> I agree. We just don't have the champion for that yet. -- Andrei
>
> I might obviously be biased, but to be honest I don't see much value in starting to port a largely obsolete backend to a whole new processor architecture.
>

I see a benefit in bringing DMD to an embedded platform: To suggest, experiment with, and introduce changes to the frontend/runtime that benefit all compilers and embedded development in D.  Such a task isn't one for an embedded champion, however, it needs a compiler champion.  We can't really get serious about building embedded systems in D until there is better compiler/runtime support.

There are two impediments to this:
(1) A strategy identifying a way forward.  How do we modularize the language, and how do we implement that modularization?  My suggestions have not been very popular, but I enthusiastically welcome suggestions.
(2) Compiler hacking skills necessary to implement those changes without stirring the aversion to change.

I have worked on this, but I failed while trying to modify the compiler, and I've been discouraged by suggestions that we don't want to "shuffle the deck".  Perhaps in the next few months I'll try to get some conversations started around this, but I'm still exploring other alternatives at the moment.

Also, there may not be any need for changes to the backend.  The Intel Galileo [1] is a Pentium-based Quark MCU [2], and the Intel Edison [3] is a dual-core Atom CPU.  Walter already said he thinks DMD might be able to program the Quark.  These aren't really "micro"controllers as they have an abundance of resources compared to the ARM Cortex-M and Atmel AVRs, but it has it's place in the ecosystem.

Also, there is no reason one can't use their desktop PC to experiment.  I see modularization of the language benefiting all domains, and I think if it existed, we'd see those features exploited in many interesting ways.

Mike

[1] - Intel Galileo - http://www.intel.com/content/www/us/en/do-it-yourself/galileo-maker-quark-board.html
[2] - Intel Quark - http://www.intel.com/content/www/us/en/processors/quark/intel-quark-technologies.html
[3] - Intel Edison - http://www.intel.com/content/www/us/en/do-it-yourself/edison.html

"Mike"  wrote in message news:ipfucgyjwwjdvmmikqcm@forum.dlang.org...

> Also, there may not be any need for changes to the backend.  The Intel Galileo [1] is a Pentium-based Quark MCU [2], and the Intel Edison [3] is a dual-core Atom CPU.  Walter already said he thinks DMD might be able to program the Quark.  These aren't really "micro"controllers as they have an abundance of resources compared to the ARM Cortex-M and Atmel AVRs, but it has it's place in the ecosystem.
>
> Also, there is no reason one can't use their desktop PC to experiment.  I see modularization of the language benefiting all domains, and I think if it existed, we'd see those features exploited in many interesting ways.

Yes, as long as we're targeting x86 the dmd backend has a chance.  Targeting another architecture would not be worth the effort. 

On 2015-04-04 01:00, Iain Buclaw via Digitalmars-d wrote:

> Summary of sources in first link, those familiar with DMD internals
> will understand what the glue methods more or less do.

It's not like there's a lot of documentation for the DMD internals ;)

-- 
/Jacob Carlborg

On Friday, 3 April 2015 at 21:59:38 UTC, Kai Nacke wrote:
> My plan with LDC is to use the CPP backend to produce a boot strap compiler and then compile the D source. Much work...

CPP backend?

 — David