anybody see the 64-bit version of dmd compiler?

alkor:

> anybody see the 64-bit version of dmd compiler?

I can't see it. It must be absent.

Bye,
bearophile

it's bad
d's good enough to make real projects, but complier MUST supports linux x64 as a target platform

believe, it's time to make 64-bit code generation

is it possible to take back-end (i.e. code generation) from gcc or it's too complicated?

alkor wrote:
> it's bad
> d's good enough to make real projects, but complier MUST supports linux x64 as a target platform
> 
> believe, it's time to make 64-bit code generation
> 
> is it possible to take back-end (i.e. code generation) from gcc or it's too complicated?

Look up gdc and ldc, both can target x86_64.  gdc tends to be lagging behind (ALOT) in the dmd front end, ldc not as much.

On 12/22/09 2:34 AM, Travis Boucher wrote:
> alkor wrote:
>> it's bad
>> d's good enough to make real projects, but complier MUST supports
>> linux x64 as a target platform
>>
>> believe, it's time to make 64-bit code generation
>>
>> is it possible to take back-end (i.e. code generation) from gcc or
>> it's too complicated?
>
> Look up gdc and ldc, both can target x86_64. gdc tends to be lagging
> behind (ALOT) in the dmd front end, ldc not as much.

GDC is being maintained again. See http://bitbucket.org/goshawk/gdc/wiki/Home
They are up to DMD 1.043 and there has been significant activity recently. It could take a while for them to get fully caught up, but they are making good progress.

Matt wrote:
> On 12/22/09 2:34 AM, Travis Boucher wrote:
>> alkor wrote:
>>> it's bad
>>> d's good enough to make real projects, but complier MUST supports
>>> linux x64 as a target platform
>>>
>>> believe, it's time to make 64-bit code generation
>>>
>>> is it possible to take back-end (i.e. code generation) from gcc or
>>> it's too complicated?
>>
>> Look up gdc and ldc, both can target x86_64. gdc tends to be lagging
>> behind (ALOT) in the dmd front end, ldc not as much.
> 
> GDC is being maintained again. See http://bitbucket.org/goshawk/gdc/wiki/Home
> They are up to DMD 1.043 and there has been significant activity recently. It could take a while for them to get fully caught up, but they are making good progress.

gdc is still lagging quite a bit, I've been following the goshawk branch.  The problem here is he has to deal with both the major DMD changes (in 2 different D versions) and the big changes in GCC, so maintaining gdc itself would be an annoying process since there isn't a bit of support on either end of the bridge.  (DM does what best for DM, gcc won't accept a language like D (even though it has more similarities to C/C++ then java/fortran/ada does).

ldc on the other hand has a great structure which promotes using it as a backend for a different front end, however it doesn't (yet) generic code nearly as good as gcc.

dmd's focus seems to be more about a reference compiler then a flexible compile that generates great code.

Personally, I still use an old ass gdc based on GCC 4.1.3, DMD1.020 because it happens to be the one that best supports my platform (FreeBSD/amd64).  The only real issues I run into is a few issues with CTFE and dsss/rebuild's handling of a few compiler errors  (eg. writefln("..."; results in rebuild exploding.)

Travis Boucher:
> ldc on the other hand has a great structure which promotes using it as a backend for a different front end, however it doesn't (yet) generic code nearly as good as gcc.

Can you explain better what do you mean?

Bye,
bearophile

bearophile wrote:
> Travis Boucher:
>> ldc on the other hand has a great structure which promotes using it as a backend for a different front end, however it doesn't (yet) generic code nearly as good as gcc.
> 
> Can you explain better what do you mean?
> 
> Bye,
> bearophile

llvm has been designed for use for code analyzers, compiler development, IDEs, etc.  The APIs are well documented and well thought out, as it its IR (which is an assembler-like language itself).  It is easy to use small parts of llvm due to its modular structure.  Although it's design promotes all sorta of optimization techniques, its still pretty young (compared to gcc) and just doesn't have all of the optimization stuff gcc has.

gcc has evolved over a long time, and contains alot of legacy cruft. It's IR changes on a (somewhat) regular basis, and its internals are a big hairy intertwined mess.  Trying to learn one small part of how GCC works often involves learning how alot of other unrelated things work. However, since it is so mature, many different optimization techniques have been developed, and continue to be developed as underlying hardware changes.  It also supports generating code for a huge number of targets.

When I say 'ldc' above, I really mean 'llvm' in general.

Travis Boucher:
> Although it's design promotes all sorta of optimization techniques, its still pretty young (compared to gcc) and just doesn't have all of the optimization stuff gcc has.

I have already done hundred of tests and benchmarks with LDC and llvm-gcc, and I'm starting to understand its optimizations. I am mostly ignorant of LLVM still, but I'm giving a bit of help tuning it, this improvement was motivated by me:
http://blog.llvm.org/2009/12/advanced-topics-in-redundant-load.html

Compared to GCC LLVM lacks vectorization (this can be important for certain heavy numerical computing code), profile-guided optimization (this is usually less important, it's uncommon that it gives more than 5-25% performance improvement), but it has a link-time optimizations that gcc lacks (about as important as profile-guided optimization or a little more).

LLVM produces bad X86 floating point code still, but its int/FP SSE code is about as good as GCC one or better (but it's not vectorized, so far).

GCC is older and it knows few extra small/tiny optimization tricks, but in most situations they don't create a large difference in performance, they are often quite specific.

So overall LLVM may sometime produce a little slower code, but in many situations it's about as good or even better (I can show a large amount of cases where LLVM is better). So the asm quality difference is smaller than you seem to imply. If the size of such performance differences are important for you, then you may want to use the Intel compiler instead of GCC, because it's sometimes better than GCC.

Bye,
bearophile

== Quote from bearophile (bearophileHUGS@lycos.com)'s article
> So overall LLVM may sometime produce a little slower code, but in many
situations it's about as good or even better (I can show a large amount of cases where LLVM is better). So the asm quality difference is smaller than you seem to imply. If the size of such performance differences are important for you, then you may want to use the Intel compiler instead of GCC, because it's sometimes better than GCC.
> Bye,
> bearophile

Does Intel even make compilers for any language outside the horribly crufty legacy language category (C, C++, Fortran)?