Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

D Language accepted for inclusion in GCC

gcc.gnu.org

Post reply on HN
Print view View original

41–50 of 235 posts

Re: D Language accepted for inclusion in GCC

#41

Post by yellowapple »

boondaburrah wrote: post #29
amyjess wrote: post #27

Earlier quoted context omitted.

> The reference backend was only Open Source (not freely redistributable). Free redistributibility is part of the Open Source Definition. It is literally the first item: https://opensource.org/osd-annotated

I think they meant lower case "open source" (as in the source is open (anyone can read/compile it)). There are plenty of software that are open source but not freely distributable, such as Unreal Engine.

The usual term for that sort of arrangement would be "shared source".

Re: D Language accepted for inclusion in GCC

#42

Post by jpf91 »

jjnoakes wrote: post #26
qznc wrote: post #14

Earlier quoted context omitted.

Someone still needs to provide the man power for porting and maintaining those platforms.

Yes, understood. What I don't know is how much D-specific work is needed in the gcc backend per-target-triple. If it's a small amount of work, and the only thing really preventing it is wider adoption, this news may be the kick that it needs. If it's a large amount of work, then this news likely won't change much.

Likely none. Well, I guess that's kind of an oversimplification though so here's the detailed story:

We require some per-target integration to provide correct version(ARM), version(linux) statements in D code and we need to know the size of a mutex on the target system. Iain is currently rewriting this code here: https://github.com/D-Programming-GDC/GDC/pull/500

However, we already provide and the new, rewritten code will continue to provide this integration for many targets. For example, all debian targets should be working: https://packages.debian.org/experimental/gdc

The main problem with architecture support is porting the runtime library and phobos. Here ARM is supported, MIPS and PPC has seen some work from LDC devs but making this work fully on GDC might require some small changes, MinGW is broken (and was never fully supported).

One caveat thought is that all D compilers mainly target 32 or 64 bit systems. So things won't just work without changes for 8bit targets, although we've seen proof of concept D code on 8bit and 16bit CPUs as well.

Re: D Language accepted for inclusion in GCC

#43

Post by jjnoakes »

jpf91 wrote: post #42
jjnoakes wrote: post #26

Earlier quoted context omitted.

Yes, understood. What I don't know is how much D-specific work is needed in the gcc backend per-target-triple. If it's a small amount of work, and the only thing really preventing it is wider adoption, this news may be the kick that it needs. If it's a large amount of work, then this news likely won't change much.

Likely none. Well, I guess that's kind of an oversimplification though so here's the detailed story: We require some per-target integration to provide correct version(ARM), version(linux) statements in D code and we need to know the size of a mutex on the target system. Iain is currently rewriting this code here: https://github.com/D-Programming-GDC/GDC/pull/500 However, we already provide and the new, rewritten code…

Glad to hear there's work in progress. Last time I tried to configure gcc + gdc on AIX on PowerPC, I found out it was explicitly disabled in the configure script, and I didn't dig any deeper to find out why or the potential work involved.

Re: D Language accepted for inclusion in GCC

#44

Post by seren »

jjnoakes wrote: post #24
copx wrote: post #15

Earlier quoted context omitted.

How would that even work? Modern C++ libraries are largely templates, templates which must be instantiated at compile-time i.e. you need a full C++ compiler to use C++ libraries directly. Said compiler must somehow work together with the D compiler here, which should lead to god-awful memory use, compilation time, and error messages.

https://dlang.org/spec/cpp_interface.html

> D understands how C++ function names are "mangled" and the correct C++ function call/return sequence.

How does it work in practice ? C++ name mangling is not standardized and so every compiler can implement its own scheme. So does it mean there is a list of D compatible c++ compiler somewhere ? I have the feeling that if you are using some exotic proprietary c++ compiler it won't work well.

Re: D Language accepted for inclusion in GCC

#45

Post by tcbawo »

Rusky wrote: post #39
yorwba wrote: post #31

Earlier quoted context omitted.

Rust has an opt-in garbage collector as a library ( https://docs.rs/gc/ ). I don't know how good it is, though.

By that measure, so do C and C++.

You could implement GC in C++ using RAII (although smart pointers get you a long way). AFAIK, automatic GC is not possible with C.

Re: D Language accepted for inclusion in GCC

#46

Post by amelius »

yorwba wrote: post #34
CJefferson wrote: post #30

Earlier quoted context omitted.

That sounds ..wrong. what about the C++ standard library? Neither vector or sort sounds like that?

Those > can be instantiated a finite number of times and then used like non-templated code. So you have a C++ file that uses vector , vector , vector , vector , etc. once and then you can link to them from D code. The only case where that doesn't work is when you have lots of one-off instantiations, where requiring an instantiation in C++ code for each use in D would get annoying quickly.

Does the D compiler know how to mangle/demangle C++ names?

Do you have to write some kind of D header file for foreign C++ functions? Otherwise, how would D even know about the existence of e.g. vector::push?

Re: D Language accepted for inclusion in GCC

#47

Post by iamNumber4 »

copx wrote: post #15
iamNumber4 wrote: post #10

Earlier quoted context omitted.

One of D's goals is to be ABI compatible with C and C++, ABI compatibility with C is 100% as I understand it. C++ is a work in progress. What is ABI compatiblity? in a nutshell it let's you use libraries from another programming language. In D, all you need is a D file that describes the C/C++ library as a wrapper so the D compiler knows what you are using. This means D will build upon everything that already exists…

How would that even work? Modern C++ libraries are largely templates, templates which must be instantiated at compile-time i.e. you need a full C++ compiler to use C++ libraries directly. Said compiler must somehow work together with the D compiler here, which should lead to god-awful memory use, compilation time, and error messages.

You should probably read up on ABI Compatibility, and, Compiling vs linking as well.

Let's be clear a compiler builds a object files that have to be linked to create a executable binary. IE compiler makes .o files. Linker takes output object files from the compiler an puts them (.o,.so/.dll,.a) together, to make .exe files.

This all works because you are linking to the C/C++ library binaries (the .o, .so, .a, .dll) files generated by a C/C++ compiling/linking. In most cases this is shared object library/dll provided by the operating system or pre-built library you install on the system. There is no need to compile it because it is pre-built. if you do compile the library yourself, it is a one time thing.

In D you create a .d file that describes what is in a C++ library .o/.so/.a/.dll file. So that upon linking, you take your D code's .o files + the C/C++ .o files to put together a full executable binary.

Re: D Language accepted for inclusion in GCC

#48

Post by kryptiskt »

seren wrote: post #44
jjnoakes wrote: post #24

Earlier quoted context omitted.

https://dlang.org/spec/cpp_interface.html

> D understands how C++ function names are "mangled" and the correct C++ function call/return sequence. How does it work in practice ? C++ name mangling is not standardized and so every compiler can implement its own scheme. So does it mean there is a list of D compatible c++ compiler somewhere ? I have the feeling that if you are using some exotic proprietary c++ compiler it won't work well.

In practice there are two dominating standards nowadays, the Itanium ABI and Microsoft's, so it's quite tractable to handle the common cases.

Re: D Language accepted for inclusion in GCC

#49

Post by castratikron »

I remember trying out D a few years ago. One of the things that threw me off was the bare-bones compiler. I think I was using the reference compiler at the time. The language itself I thought was pretty cool, slices are neat.

I could really see D take off now that it's getting gcc support.

Re: D Language accepted for inclusion in GCC

#50

Post by kbenson »

seren wrote: post #44
jjnoakes wrote: post #24

Earlier quoted context omitted.

https://dlang.org/spec/cpp_interface.html

> D understands how C++ function names are "mangled" and the correct C++ function call/return sequence. How does it work in practice ? C++ name mangling is not standardized and so every compiler can implement its own scheme. So does it mean there is a list of D compatible c++ compiler somewhere ? I have the feeling that if you are using some exotic proprietary c++ compiler it won't work well.

There was some interesting discussion regarding this here recently in the comments regarding a Rust demangling library[1].

1: https://news.ycombinator.com/item?id=13706799

Post reply on HN