digitalmars.D - C backend for D?
- Enzo Michelangeli (9/9) Jun 21 2004 Hi,
- Lars Ivar Igesund (6/20) Jun 21 2004 I think Ilya Minkov has suggested such a project several times, but as
- Billy Zelsnack (2/6) Jun 21 2004 I don't think the point is moot at all. I would love to shove D code
- Walter (4/10) Jun 21 2004 It's possible to build one out of the front end sources. All it needs is
- Enzo Michelangeli (6/18) Jun 22 2004 Do you think that relying upon the C optimizer downstream would seriousl...
- Billy Zelsnack (3/6) Jun 22 2004 There is achievable and there is 'realizable in a near term time-frame'....
- Walter (16/22) Jun 22 2004 seriously
- Billy Zelsnack (3/27) Jun 22 2004 Which all are good reasons to think that D code ran through the Intel C
- Trejkaz Xaoza (6/12) Jun 22 2004 I don't understand this conclusion. Walter was just saying there are D-...
- Billy Zelsnack (7/21) Jun 22 2004 ie. Walter has better things to do right now than to optimize D for the
-
Carlos Santander B.
(23/23)
Jun 23 2004
"Walter"
escribió en el mensaje - Matthew (3/18) Jun 23 2004 They use MS's on Win32, and GCC's on Linux
-
Carlos Santander B.
(27/27)
Jun 23 2004
"Matthew"
escribió en el mensaje - =?ISO-8859-1?Q?Sigbj=F8rn_Lund_Olsen?= (4/30) Jun 24 2004 Indeed. "MinGW" GCC uses MS's on Win32 too :-)
- Ilya Minkov (10/24) Jun 23 2004 I intended to do it myself, but dropped it due to lack of time. It would...
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
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 -- EnzoI 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
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
"Billy Zelsnack" <billy_zelsnack yahoo.com> wrote in message news:cb79n4$20g7$1 digitaldaemon.com...It's possible to build one out of the front end sources. All it needs is someone to take charge of it.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
"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...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? EnzoIt's possible to build one out of the front end sources. All it needs is someone to take charge of it.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.
Jun 22 2004
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
"Billy Zelsnack" <billy_zelsnack yahoo.com> wrote in message news:cb9sag$2u4e$1 digitaldaemon.com...seriouslyDo you think that relying upon the C optimizer downstream wouldoptimizerimpact the achievable degree of optimization , compared with anThere'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.
Jun 22 2004
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).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.
Jun 22 2004
In article <cbb0is$1kir$1 digitaldaemon.com>, Billy Zelsnack says...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. :-/ TXBut 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
In article <cbb0is$1kir$1 digitaldaemon.com>, Billy Zelsnack says...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.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. :-/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
"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
"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
"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
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
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