Hi,

I just discovered D, and from what I can see it's pretty close to my "dream language". Has anybody ever suggested to create a compiler backend producing ANSI C source code, as e.g. SmartEiffel does for Eiffel programs? This would probably affect the performances negatively, but it would represent a useful first step to port the language to other platforms.

TIA --

Enzo

Enzo Michelangeli wrote:

> Hi,
> 
> I just discovered D, and from what I can see it's pretty close to my
> "dream language". Has anybody ever suggested to create a compiler backend
> producing ANSI C source code, as e.g. SmartEiffel does for Eiffel
> programs? This would probably affect the performances negatively, but it
> would represent a useful first step to port the language to other
> platforms.
> 
> TIA --
> 
> Enzo
> 
> 

I think Ilya Minkov has suggested such a project several times, but as there is a gdc (GNU D Compiler), where the dmd frontend is grafted onto the g++ backend or something, the point is somewhat moot. Check out the digitalmars.D.gnu NG for references and discussions.

Lars Ivar Igesund

> I think Ilya Minkov has suggested such a project several times, but as there is a gdc (GNU D Compiler), where the dmd frontend is grafted onto the g++ backend or something, the point is somewhat moot. Check out the digitalmars.D.gnu NG for references and discussions.

I don't think the point is moot at all. I would love to shove D code into the Intel compiler.

"Billy Zelsnack" <billy_zelsnack@yahoo.com> wrote in message news:cb79n4$20g7$1@digitaldaemon.com...
> > I think Ilya Minkov has suggested such a project several times, but as there is a gdc (GNU D Compiler), where the dmd frontend is grafted onto the g++ backend or something, the point is somewhat moot. Check out the digitalmars.D.gnu NG for references and discussions.
>
> I don't think the point is moot at all. I would love to shove D code into the Intel compiler.

It's possible to build one out of the front end sources. All it needs is someone to take charge of it.

"Walter" <newshound@digitalmars.com> wrote in message news:cb8bvh$hcv$1@digitaldaemon.com...
>
> "Billy Zelsnack" <billy_zelsnack@yahoo.com> wrote in message news:cb79n4$20g7$1@digitaldaemon.com...
> > > I think Ilya Minkov has suggested such a project several times, but
> > > as there is a gdc (GNU D Compiler), where the dmd frontend is
> > > grafted onto the g++ backend or something, the point is somewhat
> > >  moot. Check out thedigitalmars.D.gnu NG for references and
> > > discussions.
> >
> > I don't think the point is moot at all. I would love to shove D code into the Intel compiler.
>
> It's possible to build one out of the front end sources. All it needs is someone to take charge of it.

Do you think that relying upon the C optimizer downstream would seriously impact the achievable degree of optimization , compared with an optimizer explicitly designed for D?

Enzo

> Do you think that relying upon the C optimizer downstream would seriously
> impact the achievable degree of optimization , compared with an optimizer
> explicitly designed for D?

There is achievable and there is 'realizable in a near term time-frame'.      Also, the Intel compiler is pretty damn amazing. Walter vs 'large crack team of Intel engineers on their own turf', dunno.

"Billy Zelsnack" <billy_zelsnack@yahoo.com> wrote in message news:cb9sag$2u4e$1@digitaldaemon.com...
> > Do you think that relying upon the C optimizer downstream would
seriously
> > impact the achievable degree of optimization , compared with an
optimizer
> > explicitly designed for D?
>
> There is achievable and there is 'realizable in a near term time-frame'.
>       Also, the Intel compiler is pretty damn amazing. Walter vs 'large
> crack team of Intel engineers on their own turf', dunno.

There's nothing hard about what the Intel optimizer is doing in theory, it just takes a lot of careful implementation work. The Intel team has some obvious advantages over me:

1) They don't have to spend years writing and debugging a C++ front end. They just bought one.

2) They have access to the engineers who designed the chip to get better info on what code to generate.

3) They don't have to write a runtime library.

If I could only work on the optimizer/code generator, I could match what they do.

But to answer the original question, yes, there are many possible D-specific optimizations that would not be done by a C back end.

>>>explicitly designed for D?
>>
>>There is achievable and there is 'realizable in a near term time-frame'.
>>      Also, the Intel compiler is pretty damn amazing. Walter vs 'large
>>crack team of Intel engineers on their own turf', dunno.
> 
> 
> There's nothing hard about what the Intel optimizer is doing in theory, it
> just takes a lot of careful implementation work. The Intel team has some
> obvious advantages over me:
> 
> 1) They don't have to spend years writing and debugging a C++ front end.
> They just bought one.
> 
> 2) They have access to the engineers who designed the chip to get better
> info on what code to generate.
> 
> 3) They don't have to write a runtime library.
> 
> If I could only work on the optimizer/code generator, I could match what
> they do.
> 
> But to answer the original question, yes, there are many possible D-specific
> optimizations that would not be done by a C back end.

Which all are good reasons to think that D code ran through the Intel C compiler, will generate faster code on an Intel machine for now and the near future (at least).

In article <cbb0is$1kir$1@digitaldaemon.com>, Billy Zelsnack says...
>> 
>> But to answer the original question, yes, there are many possible D-specific optimizations that would not be done by a C back end.
>
> Which all are good reasons to think that D code ran through the Intel C compiler, will generate faster code on an Intel machine for now and the near future (at least).

I don't understand this conclusion.  Walter was just saying there are D-specific optimizations that would _not_ be done by a C back-end, and I assume that your conclusion means you think that such optimizations wouldn't help performance? From where I sit it seems to be to the contrary. :-/

TX

> In article <cbb0is$1kir$1@digitaldaemon.com>, Billy Zelsnack says...
> 
>>>But to answer the original question, yes, there are many possible D-specific
>>>optimizations that would not be done by a C back end.
>>
>>Which all are good reasons to think that D code ran through the Intel C compiler, will generate faster code on an Intel machine for now and the near future (at least).
> 
> 
> I don't understand this conclusion.  Walter was just saying there are D-specific
> optimizations that would _not_ be done by a C back-end, and I assume that your
> conclusion means you think that such optimizations wouldn't help performance?
> From where I sit it seems to be to the contrary. :-/

ie. Walter has better things to do right now than to optimize D for the Intel platform. Yes you 'could' make it faster, but is that going to happen real soon? Probably not.

I'm also not really sure how much faster a fancy new D code generator would be over D code kicked out to C. I still 'think' mostly in c++ and
that makes any of my code (and most likely many others) very well
suited to existing compilers.