www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C backend for D?

reply "Enzo Michelangeli" <nospam em.no-ip.com> writes:
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
Jun 21 2004
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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
Jun 21 2004
parent reply Billy Zelsnack <billy_zelsnack yahoo.com> writes:
 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.
Jun 21 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 21 2004
parent reply "Enzo Michelangeli" <nospam em.no-ip.com> writes:
"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
Jun 22 2004
parent reply Billy Zelsnack <billy_zelsnack yahoo.com> writes:
 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.
Jun 22 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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


 impact the achievable degree of optimization , compared with an


 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.
Jun 22 2004
next sibling parent reply Billy Zelsnack <billy_zelsnack yahoo.com> writes:
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).
Jun 22 2004
parent reply Trejkaz Xaoza <trejkaz xaoza.net> writes:
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
Jun 22 2004
parent Billy Zelsnack <billy_zelsnack yahoo.com> writes:
 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.
Jun 22 2004
prev sibling parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Walter" <newshound digitalmars.com> escribiˇ en el mensaje
news:cbatqt$1fsp$1 digitaldaemon.com
| 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.
|

Sorry to ask, but why is that? (3)

| 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.

-----------------------
Carlos Santander Bernal
Jun 23 2004
parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:cbd4ob$1umu$1 digitaldaemon.com...
 "Walter" <newshound digitalmars.com> escribiˇ en el mensaje
 news:cbatqt$1fsp$1 digitaldaemon.com
 | 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.
 |

 Sorry to ask, but why is that? (3)

They use MS's on Win32, and GCC's on Linux
Jun 23 2004
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribiˇ en el mensaje
news:cbd696$20o4$1 digitaldaemon.com
| "Carlos Santander B." <carlos8294 msn.com> wrote in message
| news:cbd4ob$1umu$1 digitaldaemon.com...
|| "Walter" <newshound digitalmars.com> escribiˇ en el mensaje
|| news:cbatqt$1fsp$1 digitaldaemon.com
||| 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.
|||
||
|| Sorry to ask, but why is that? (3)
|
| They use MS's on Win32, and GCC's on Linux

Well, outsourcing is the way to go... lol!
Thanks!

-----------------------
Carlos Santander Bernal
Jun 23 2004
parent =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= <sigbjorn lundolsen.net> writes:
Carlos Santander B. wrote:

 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> escribiˇ en el mensaje
 news:cbd696$20o4$1 digitaldaemon.com
 | "Carlos Santander B." <carlos8294 msn.com> wrote in message
 | news:cbd4ob$1umu$1 digitaldaemon.com...
 || "Walter" <newshound digitalmars.com> escribiˇ en el mensaje
 || news:cbatqt$1fsp$1 digitaldaemon.com
 ||| 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.
 |||
 ||
 || Sorry to ask, but why is that? (3)
 |
 | They use MS's on Win32, and GCC's on Linux
 
 Well, outsourcing is the way to go... lol!
 Thanks!

Indeed. "MinGW" GCC uses MS's on Win32 too :-) Cheers, Sigbj°rn Lund Olsen
Jun 24 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
I intended to do it myself, but dropped it due to lack of time. It would 
not be a "first step" in porting to other platforms any longer, since 
David Friedman has already made a compiler with GCC backend from DMD source.

http://home.earthlink.net/~dvdfrdmn/d/

D is not completely expressable in ANSI-C, but it can be done in C with 
some compiler-dependent extensions, conserning exception handling so 
that it can cooperate with standard mechanisms of the operating system. 
On embedded systems, even more ANSI-like C can be used.

-eye

Enzo Michelangeli schrieb:

 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
 
 

Jun 23 2004