Add ImportC compiler to dmd (page 4)

On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote: > https://github.com/dlang/dmd/pull/12507 > > If you could add a C compiler to dmd with 3000 lines of code, so C code could be imported directly? I would! How does this impact gdc as part of GCC? GCC already has a C compiler, so this could be seen as some kind of duplication of features/effort from their perspective.

On 5/9/2021 1:57 PM, Walter Bright wrote: > https://github.com/dlang/dmd/pull/12507 > > If you could add a C compiler to dmd with 3000 lines of code, so C code could be imported directly? I would! Looks like we're on the front page of hackernews! https://news.ycombinator.com/

On Monday, 10 May 2021 at 08:09:23 UTC, Ola Fosheim Grostad wrote: > On Monday, 10 May 2021 at 02:12:02 UTC, Adam D. Ruppe wrote: > ... > It makes more sense to reuse clang and emit llvm IR. Except that llvm IR is not understood by DMD, also llvm IR is post-semantic. So you you have to take the opposite path, i.e IR -> AST, which is quite unusual. Anyway, this is is not a bad idea, let's say for a another project.

On 5/10/2021 12:39 AM, Patrick Schluter wrote: > The only thing that bothers me as it is now is the fact that it doesn't support intializer list `{ intializers }`, which I suppose means that designated initializers `{ .field = ..., [3]=... }`and compound statements `(type){ initializers }` are not working either. This would be a real real problem for modern C code (C99 and superior). The only issue is { initializer-list } has no direct analog in D, so I've got to add one to the D side. For the purpose of this prototype, I wished to avoid adding code that wasn't in cparse.d.

On 5/10/2021 1:53 AM, Gregor Mückl wrote: > How does this impact gdc as part of GCC? GCC already has a C compiler, so this could be seen as some kind of duplication of features/effort from their perspective. Since this is all front end work, and it translates the C code into D AST nodes, it should "just work". After all, CTFE "just worked" with ImportC. I didn't do a thing to enable it. I didn't do a thing to the glue code, optimizer, or back end (other than not generating moduleinfo).

On Monday, 10 May 2021 at 09:14:02 UTC, Basile B. wrote: > On Monday, 10 May 2021 at 08:09:23 UTC, Ola Fosheim Grostad wrote: >> On Monday, 10 May 2021 at 02:12:02 UTC, Adam D. Ruppe wrote: >> ... >> It makes more sense to reuse clang and emit llvm IR. > > Except that llvm IR is not understood by DMD, also llvm IR is post-semantic. > So you you have to take the opposite path, i.e IR -> AST, which is quite unusual. > > Anyway, this is is not a bad idea, let's say for a another project. No, you take a C-expression in D, use an external tool/library to obtain the semantics of the resulting expression. Then you compile and link at IR level. Anyway, I suggested the approach Walter is taking here years ago, but at this point there are more critical issues on the table... This is a diversion from adressing the hard issues.

On Monday, 10 May 2021 at 09:24:39 UTC, Walter Bright wrote: > On 5/10/2021 12:39 AM, Patrick Schluter wrote: >> The only thing that bothers me as it is now is the fact that it doesn't support intializer list `{ intializers }`, which I suppose means that designated initializers `{ .field = ..., [3]=... }`and compound statements `(type){ initializers }` are not working either. This would be a real real problem for modern C code (C99 and superior). > > The only issue is { initializer-list } has no direct analog in D, so I've got to add one to the D side. > > For the purpose of this prototype, I wished to avoid adding code that wasn't in cparse.d. I get that but just wanted to point out that that will be a big issue (it's such a big issue that C++ had to implement it with C++20).

On Monday, 10 May 2021 at 09:31:58 UTC, Ola Fosheim Grostad wrote:

Anyway, I suggested the approach Walter is taking here years ago, but at this point there are more critical issues on the table... This is a diversion from adressing the hard issues.

The changelog mentions htod, dpp and DStep. The solution proposed should be as good as the union of the three.

There are chances that the discussion will derivate on the topic of full translation of C while the point is rather to translate headers i.e declarations and only that. Like if it can handle most commonly used c headers, let's say zlib, ssl, etc. it's ok. What people want is more like cairo headers, llvm headers, x11 headers, etc. to be handled.

On Sunday, 9 May 2021 at 20:57:06 UTC, Walter Bright wrote: > https://github.com/dlang/dmd/pull/12507 > > If you could add a C compiler to dmd with 3000 lines of code, so C code could be imported directly? I would! Hi Walter This seems like a good step forward. I would recommend adding an in-built C pre-processor. Maybe port something small like this one: https://github.com/rui314/chibicc/blob/main/preprocess.c Many people write single header file C programs. With this enhancement it will be easy to use all of that code in D. Regards

May 10, 2021

Re: Add ImportC compiler to dmd

Posted by Ola Fosheim Grøstad
in reply to Basile B.

Permalink

Ola Fosheim Grøstad

Posted in reply to Basile B.

Permalink

On Monday, 10 May 2021 at 10:03:48 UTC, Basile B. wrote:

The topic presented is to translate C code to D's high level IR after cpp.

My point is that you don't need to translate headers if you have an external tool that accept a set of header files and a C-expression and provide a mechanism to do reflection on that expression.

What you need then is some way to translate D-constructs to C-constructs which shouldn't be too hard.

But regardless, D's focus ought to be on memory management and fixing issues in the type system. Adding more source code to the compiler won't help.

Basic system development strategy:

Refactor first, then fix issues, then add new features.

Forums