On Monday, 11 November 2013 at 08:11:06 UTC, Kai Nacke wrote:
> On Friday, 19 July 2013 at 13:38:12 UTC, Chad Joan wrote:
>> I think a C backend would get us farther than an LLVM backend.
>
> Hi,
>
> LLVM has a C++ backend in the git tree. The old C backend is still maintained outside the git tree (search the dev mailing list for an url).
>
> So if you like C-output, you can start with LDC today. For sure, you have to port druntime to this new environemnt...
>
> Regards,
> Kai

Is there any built-in support for using this C++ backend in LDC right now?  Something like "ldc --target=c++ main.d -o main.cpp"?

This seems very promising.

I would still want to write xdc for other reasons, but I have more immediate use for a D compiler that can output C/C++ code.  If it works, I would probably down-prioritize C/C++ output in xdc and instead retarget on something more needed (like Java bytecode or Javascript).

On Saturday, 9 November 2013 at 21:45:30 UTC, Andrei Alexandrescu wrote:
> On 11/9/13 9:14 AM, nazriel wrote:
>> On Thursday, 18 July 2013 at 01:21:44 UTC, Chad Joan wrote:
>>> I'd like to present my vision for a new D compiler.  I call it xdc, a
>>> loose abbreviation for "Cross D Compiler" (if confused, see
>>> ...
>>> Thank you for reading.
>>
>> I think C backend is a good idea.
>
> I think C is not a good back-end language. Other backend generators usually have a white paper explaining why... http://www.cminusminus.org/
>
> Andrei

What would you suggest as an alternative for targeting disparate hardware like microcontrollers (ALL of them), newly released game consoles, and legacy platforms that could use D for migration tools (like OpenVMS on IA64)?

Oh, and I want instantaneous release times.  I need to be able to stick the compiler on a machine it has NEVER seen and say, "Use POSIX libraries to fulfill Phobos' deps.  Use reference counting.  DO WORK!".  Or maybe I would say, "Ditch Phobos, we in da sticks.  Use reference counting.  GOGOGO!"  And I want to be running my D program 5 minutes later.

Let me initially dismiss these:
LLVM: not /everywhere/ yet, and missing on many of the targets I mentioned.
C--: also not everywhere; this is the first I've heard of it.
Java/Javascript/.NET: Actually also good backends, but a different ecosystems.

Thus, I suggest that C is an AWESOME backend (with C++ for exceptions, but ONLY if it's available).  Destroy :)

On Sunday, 10 November 2013 at 08:21:37 UTC, Walter Bright wrote:
> On 11/9/2013 9:27 PM, deadalnix wrote:
>> On Sunday, 10 November 2013 at 04:54:18 UTC, Daniel Murphy wrote:
>>> That is true in general, but D actually maps quite well onto C.
>>>
>>> I did some work on creating a C backend a while back, and it worked quite
>>> well.
>>>
>>
>> Out of curiosity, how do you handle exceptions ?
>
> Exceptions is one big problem. Another is COMDATs - C compilers don't emit them. COMDATs are needed to support templates (they remove duplicate instances).
>
> And TLS.

This seems like it matters when linking D code to D code.  Other language's wouldn't care about D's templates.  I imagine that in most cases it would be possible to just compile the D code together.

This whole mess can be done away with by removing the "linking" step in compilation, which is what I'd recommend for a compiler that is designed to output things that aren't object files.

The compiler should be able to dedup templates internally when doing AST manipulation.  I actually /expect/ this.

The only reasons to output object files, that I can think of right now, are as follows:
- Obfuscation is desired in the output.
- Incremental compiling.

To meet those needs, the following approaches could be used:
- Obfuscation: A compiler without a linkable output format could support an "obfuscation" target that would output obfuscated D code for later compiling in a 3rd party's hands.
- Incremental Compiling: This is usually done to help with terrible build times.  A compiler without a linkable output format could offer a "do as much as you can" target that outputs D code that is lowered as far as it can possibly be lowered without being fed more information.  At that point, D might be nearly as fast as the linker, at least in human terms.

On Sunday, 10 November 2013 at 12:24:59 UTC, Daniel Murphy wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message
> news:l5n7iq$2op2$1@digitalmars.com...
>> On 11/9/13 9:37 PM, Daniel Murphy wrote:
>>> "deadalnix" <deadalnix@gmail.com> wrote in message
>>> news:juoauplfttovsmbrafzh@forum.dlang.org...
>>>>
>>>> Out of curiosity, how do you handle exceptions ?
>>>
>>> I didn't.  This was focussed on a subset suitable for microcontrollers. I
>>> would probably emit C++ instead if exceptions were required.
>>
>> That doesn't quite rhyme with C being a good backend language :o).
>>
>> Andrei
>>
>
> I guess it's not for the full language, but if you can't use gdc or llvm,
> chances are your platform is too constrained to use exceptions.
>  I don't
> mean C is capable of representing everything, but it can handle a large and
> useful subset.

My ideal is to have exceptions in C anyways.  I don't understand why people are so afraid of this.  It's doable in very portable ways, and D's nothrow attribute gives a good hint to the compiler that can be used to avoid performance drains in inappropriate places.

I think that setjmp/longjmp comes to mind most of the time because it is what people would normally use in C if they have to write the C code by hand.  This is one approach that I would have a compiler optionally emit, controllable by a command-line flag (--c-exceptions=sjlj or somesuch).

There is a different approach that I'd want to try first: alter the calling convention and always pass an exception object as the first argument (but only if the called function can throw).

Given this example:

-----------------------------------------------------------------

float baz(int a);

void foo()
{
    int a = 42;
    // do stuff
    float b = baz(a);
    // do other stuff
}

float bar()
{
    try
        return baz(9);
    catch( Exception e )
        return 0.0;
}

--------------------------------

The D->C compiler would emit code like so:

-----------------------------------------------------------------

float baz(Exception *exception, int a);

void foo(Exception *exception)
{
    int a = 42;
    // do stuff
    float b = baz(exception, a);
    if ( exception->thrown )
        return;
    // do other stuff
}

float bar(Exception *exception)
{
    float result = baz(exception, 9);
    if ( exception->thrown )
        goto ExceptionHandler1;
    return result;

ExceptionHandler1:
    Exception *e = exception;
    (void)e;
    return 0.0;
}

--------------------------------
(Name mangling omitted for the sake of sanity.)

This is not something that you'd want to do by hand when writing C-code, though that doesn't stop people from trying to poorly approximate it using integer return values ;)

It would integrate nicely with scope, because the compiler would know where to put all of the goto statements and labels.

It's also made of pointers, ifs, goto's, and labels: stuff that any usable C compiler should have.  Super portable.

The drawback: This would, of course, not link nicely with code generated by other D compilers.  I don't mind this at all though, because if you're using this then it's probably because there aren't any other D compilers supporting your platform anyways.

I've already written a bunch of C code that emulates exception handling + scope statements using setjmp/longjmp, and I really wish that a compiler could write better optimized C code /for/ me.

On Saturday, 9 November 2013 at 04:46:14 UTC, Etienne wrote:
> Many vendors would have their processors supported in D if we had
> a D to C compiler. I feel like it would be simpler than going for
> native code directly. Did this idea follow-through?
>

No, not yet I'm afraid.  At least not for xdc.

Here's the lowdown:
The future of xdc will be determined by whether or not I can save up enough money to reliably support myself between the time I would leave my current job and the time I would be compensated by means of crowdsourcing.  In the middle there I would need to create some kind of working demo, make a good pitch, talk to a bunch of writers and programmer communities, etc etc, all while burning precious savings.  If, before any of that, I get recruited by another company with a non-terrible (and possibly /good/) codebase (like Sociomantic or Facebook), then we would be able to consider the whole idea effectively cancelled before it can start.  As great for /me/ as it would be to write D code for a job, I just don't see it being a boon to xdc: companies usually hire folks to work on the company's stuff, not the employee's stuff.  But, if I end up sticking with my current job, then at some point I may just go out on my own and make things happen.  Time will tell.

That said, if all you want is a C/C++ backend, then Kai's recent post on this thread brings up a possibility that seems unexplored, as of yet:
http://forum.dlang.org/post/psqajaggngbuctqfrrnc@forum.dlang.org
Maybe that'll get you there in more certain terms.

On 11/11/2013 6:34 PM, Chad Joan wrote:
> This whole mess can be done away with by removing the "linking" step in
> compilation,

That's not really an option if you intend to use C as a back end.

On 11/11/13 5:53 PM, Chad Joan wrote:
> On Saturday, 9 November 2013 at 21:45:30 UTC, Andrei Alexandrescu wrote:
>> On 11/9/13 9:14 AM, nazriel wrote:
>>> On Thursday, 18 July 2013 at 01:21:44 UTC, Chad Joan wrote:
>>>> I'd like to present my vision for a new D compiler.  I call it xdc, a
>>>> loose abbreviation for "Cross D Compiler" (if confused, see
>>>> ...
>>>> Thank you for reading.
>>>
>>> I think C backend is a good idea.
>>
>> I think C is not a good back-end language. Other backend generators
>> usually have a white paper explaining why... http://www.cminusminus.org/
>>
>> Andrei
>
> What would you suggest as an alternative for targeting disparate
> hardware like microcontrollers (ALL of them), newly released game
> consoles, and legacy platforms that could use D for migration tools
> (like OpenVMS on IA64)?
>
> Oh, and I want instantaneous release times.  I need to be able to stick
> the compiler on a machine it has NEVER seen and say, "Use POSIX
> libraries to fulfill Phobos' deps.  Use reference counting.  DO WORK!".
> Or maybe I would say, "Ditch Phobos, we in da sticks.  Use reference
> counting.  GOGOGO!"  And I want to be running my D program 5 minutes later.
>
> Let me initially dismiss these:
> LLVM: not /everywhere/ yet, and missing on many of the targets I mentioned.
> C--: also not everywhere; this is the first I've heard of it.
> Java/Javascript/.NET: Actually also good backends, but a different
> ecosystems.
>
> Thus, I suggest that C is an AWESOME backend (with C++ for exceptions,
> but ONLY if it's available).  Destroy :)

Fine with me. I have no stake in this. I don't see how you reach the conclusion that C is "awesome" given it makes exceptions tenuous to implement. It does have the advantage of being universally available. If that's everything you need, sure.

Andrei

Hey Chad,

It looks like you have put a lot of thought and effort into
this from your posts. Nice work.

I am one of the developers of Amber and we do have a C backend,
as nazriel pointed out earlier in the thread. It supports
exceptions (sjlj and seh depending on the flag and platform).
We support clang, gcc, dmc, tcc and msvc...though I have really
only been testing gcc and clang lately.

I can't say we have perfect coverage of exceptions, and
templates are a little behind with the C backend when compared
to the llvm backend also, but we actually pass more tests in
our testsuite with the CBE than LLVMBE.

Amber is an offshoot of D1, with some small parts of D2 where
it made sense, so it may not be very close to what you are
looking for, but it might be worth checking out. It compiles
best on linux with dmd and ldc 1.074 and needs Tango to compile
(Tango is also our main standard lib for Amber...though we can
only compile about 25-30% of Tango with the Amber compiler right
now).

Good luck with xdc, whichever way you go with it.

Thanks,
Kelly


On Tuesday, 12 November 2013 at 03:51:21 UTC, Chad Joan wrote:
> On Saturday, 9 November 2013 at 04:46:14 UTC, Etienne wrote:
>> Many vendors would have their processors supported in D if we had
>> a D to C compiler. I feel like it would be simpler than going for
>> native code directly. Did this idea follow-through?
>>
>
> No, not yet I'm afraid.  At least not for xdc.
>
> Here's the lowdown:
> The future of xdc will be determined by whether or not I can save up enough money to reliably support myself between the time I would leave my current job and the time I would be compensated by means of crowdsourcing.  In the middle there I would need to create some kind of working demo, make a good pitch, talk to a bunch of writers and programmer communities, etc etc, all while burning precious savings.  If, before any of that, I get recruited by another company with a non-terrible (and possibly /good/) codebase (like Sociomantic or Facebook), then we would be able to consider the whole idea effectively cancelled before it can start.  As great for /me/ as it would be to write D code for a job, I just don't see it being a boon to xdc: companies usually hire folks to work on the company's stuff, not the employee's stuff.  But, if I end up sticking with my current job, then at some point I may just go out on my own and make things happen.  Time will tell.
>
> That said, if all you want is a C/C++ backend, then Kai's recent post on this thread brings up a possibility that seems unexplored, as of yet:
> http://forum.dlang.org/post/psqajaggngbuctqfrrnc@forum.dlang.org
> Maybe that'll get you there in more certain terms.

On 2013-11-10 09:20, Walter Bright wrote:

> Exceptions is one big problem. Another is COMDATs - C compilers don't
> emit them. COMDATs are needed to support templates (they remove
> duplicate instances).
>
> And TLS.

What about the EDG C++ compiler, doesn't that output C code?

-- 
/Jacob Carlborg

On Tuesday, 12 November 2013 at 05:49:23 UTC, Andrei Alexandrescu wrote:
> On 11/11/13 5:53 PM, Chad Joan wrote:
>>
>> What would you suggest as an alternative for targeting disparate
>> hardware like microcontrollers (ALL of them), newly released game
>> consoles, and legacy platforms that could use D for migration tools
>> (like OpenVMS on IA64)?
>>
>> Oh, and I want instantaneous release times.  I need to be able to stick
>> the compiler on a machine it has NEVER seen and say, "Use POSIX
>> libraries to fulfill Phobos' deps.  Use reference counting.  DO WORK!".
>> Or maybe I would say, "Ditch Phobos, we in da sticks.  Use reference
>> counting.  GOGOGO!"  And I want to be running my D program 5 minutes later.
>>
>> Let me initially dismiss these:
>> LLVM: not /everywhere/ yet, and missing on many of the targets I mentioned.
>> C--: also not everywhere; this is the first I've heard of it.
>> Java/Javascript/.NET: Actually also good backends, but a different
>> ecosystems.
>>
>> Thus, I suggest that C is an AWESOME backend (with C++ for exceptions,
>> but ONLY if it's available).  Destroy :)
>
> Fine with me. I have no stake in this. I don't see how you reach the conclusion that C is "awesome" given it makes exceptions tenuous to implement. It does have the advantage of being universally available. If that's everything you need, sure.
>
> Andrei

I call it "awesome" because you seem to have objections to the whole notion, and your objections are usually very interesting.  So I'm just pulling your chain in the hopes that you bestow insights on me :)

Honestly, I look forward to being able to implement exception handling in C!  It sounds like a fun couple coding sessions waiting to happen.  I already did it with C macros, so giving me an entire code generator to work with might make it /too/ easy.  And it scratches an itch that current compiler's can't (well, maybe LDC is catching up).

Perhaps this is just the difference between choosing a good IR (which C is not) and choosing a good compilation target (where C is needed).