Add ImportC compiler to dmd (page 5)

On Monday, 10 May 2021 at 02:12:02 UTC, Adam D. Ruppe wrote: > > But I'm against merging something that's only maybe 20% done. Get up to 50% - integrated cpp with those #defines actually being available to D... and maybe we have something usable and a solid basis to estimate how much work is left (by the time you get to the point where you can do this, the work is about 1/3 done. There'd still the all the little details that need to be done and the inevitable flurry of bugs. I'd be surprised if this is legitimately usable by the end of the year. But it would prove it is realistically possible once importing a module with some defined constants works from the D side.) +1 For example a lot of "C" headers in the wild use pragma(pack), and it seems awful to implement. No, it doesn't correspond to what align(x) does.

On Monday, 10 May 2021 at 02:00:26 UTC, Brian wrote:

On Monday, 10 May 2021 at 01:53:26 UTC, Walter Bright wrote:

On 5/9/2021 6:13 PM, Max Haughton wrote:

#include <stdio.h>
inline int square(int num) {
     return num * num;
}

int main()
{
     printf("%d\n", square(3));
}

fails to link in C but not in C++.

I just tried it with gcc, it links. It does not with clang. Examination of clang's output shows it treated it as extern. I don't really understand what's going on with clang here, but that code will work with DMD.

It links on clang 11.0.1 here at -O2 or higher (including -Os and -Oz).
Also links with pcc -O and even tcc!

See my previous comment and think about what inlining does to the assembly.

May 10, 2021

Re: Add ImportC compiler to dmd

Posted by Ola Fosheim Grøstad
in reply to Ola Fosheim Grøstad

Permalink

Ola Fosheim Grøstad

Posted in reply to Ola Fosheim Grøstad

Permalink

On Monday, 10 May 2021 at 11:03:43 UTC, Ola Fosheim Grøstad wrote:

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.

To elaborate on this assume you have something like this:

#include "header1.h"
#include "header2.h"

DType1 x;
DType2 y;

int z = ©(FUNKYMACRO(1+*$x,*$y)

The the compiler would collect all #includes in the D-file and create a C-function with (cachable) source looking something like this:

#include "header1.h"
#include "header2.h"

int __transpiled1234(__DType1_translated_to_C* __x, __DType2_translated_to_C* __y){
return FUNKYMACRO(1+*__x, *__y);
}

And generate the following D code:

int z = __transpiled1234(&x, &y);

Something like that.

On Monday, 10 May 2021 at 00:47:22 UTC, Walter Bright wrote: > On 5/9/2021 4:27 PM, Max Haughton wrote: >> `inline` in the C standard (although given as an example C11 footnote 138) technically *only* has guaranteed implications other than actually inlining the function, is ignoring it valid? > > C11 6.7.4-6 says: > > "A function declared with an inline function specifier is an inline function. Making a function an inline function suggests that calls to the function be as fast as possible. The extent to which such suggestions are effective is implementation-defined." > > Ignoring it is not only valid, it's what modern C compilers do anyway. inline change the linker flags so that multiple definitions do not fail. That's all it does.

On 5/10/2021 3:57 AM, Dibyendu Majumdar wrote: > 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. Thanks for the tip! Unfortunately, the file is not a C preprocessor in all it's hideous detail, so it'll be a problem. Fortunately, we do have a C preprocessor: https://github.com/DigitalMars/dmpp

On 5/10/2021 3:03 AM, Basile B. wrote: > 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. We *can* do a full translation of C with ImportC.

On 5/10/2021 4:01 PM, deadalnix wrote: > inline change the linker flags so that multiple definitions do not fail. That's all it does. They're still done with COMDATs (the equivalent in Elf, Mach, MSCoff). A COMDAT is a separate section. One COMDAT per function means they can be handled separately. The pre-1990 way was to lump everything into one section, and the different functions could not be teased out of that. Some of the more peculiar C linkage semantics are sad attempts to deal with no COMDAT support.

On Tuesday, 11 May 2021 at 04:18:23 UTC, Walter Bright wrote: > On 5/10/2021 3:03 AM, Basile B. wrote: >> 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. > > We *can* do a full translation of C with ImportC. That would be a game changer

Forums