www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D to C compiler?

reply Nicolay Korslund <korslund gmail.com> writes:
I remember reading something about a D to C compiler on this group a few years
ago. (I'm not really a regular here anymore, so there might have been more
recent mentions that I've missed.) Does anyone know if there's any such project
still around that's alive or could be revived? Or if there's any other viable
solutions for converting D to C (or C++)?

The reason I would want to do this is to port D code to currently non-supported
platforms. This is especially important for game projects (like my own
monsterscript project) - most game console SDKs take C/C++ and nothing else.
The C/C++ output wouldn't have to be nice or even human readable - just
compilable. It would only be used as a middle step in the compilation process
for these platforms.

Any ideas or suggestions?

Nico
Jan 25 2009
next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 25 Jan 2009 17:56:30 +0300, Nicolay Korslund <korslund gmail.com> wrote:

 I remember reading something about a D to C compiler on this group a few  
 years ago. (I'm not really a regular here anymore, so there might have  
 been more recent mentions that I've missed.) Does anyone know if there's  
 any such project still around that's alive or could be revived? Or if  
 there's any other viable solutions for converting D to C (or C++)?

 The reason I would want to do this is to port D code to currently  
 non-supported platforms. This is especially important for game projects  
 (like my own monsterscript project) - most game console SDKs take C/C++  
 and nothing else. The C/C++ output wouldn't have to be nice or even  
 human readable - just compilable. It would only be used as a middle step  
 in the compilation process for these platforms.

 Any ideas or suggestions?

 Nico
There were two projects I've heard of, but none of them are functional AFAIK. Perhaps, LDC could translate D code into C? BTW, what are the platforms you are talking about?
Jan 25 2009
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nicolay Korslund" <korslund gmail.com> wrote in message 
news:glhuiu$11ck$1 digitalmars.com...
I remember reading something about a D to C compiler on this group a few 
years ago. (I'm not really a regular here anymore, so there might have been 
more recent mentions that I've missed.) Does anyone know if there's any 
such project still around that's alive or could be revived? Or if there's 
any other viable solutions for converting D to C (or C++)?

 The reason I would want to do this is to port D code to currently 
 non-supported platforms. This is especially important for game projects 
 (like my own monsterscript project) - most game console SDKs take C/C++ 
 and nothing else. The C/C++ output wouldn't have to be nice or even human 
 readable - just compilable. It would only be used as a middle step in the 
 compilation process for these platforms.

 Any ideas or suggestions?

 Nico
I don't think there's anything like that in a fully-usable form just yet, but there are at least a few leads: - Like Denis said, I've heard LLVM is supposed to have a plain-C backend, but I don't know how far along that is or if it's working with LDC (and from what I hear, even LDC itself isn't quite production-ready just yet, but it is movng along quickly). - It might be possible to create something with ANTLR to do this, but you'd have to define a full D grammar in ANTLR along with instructions on how to convert it to C. A lot of work, but might be easier than a full from-scratch D-to-C converter. - Also, I'm in the early stages of a pet project that, if successful, may eventually be able to do that. But it's nowhere near such a level yet. But regardless, the ability to convert D to plain C is something that IMO really does need to happen at some point.
Jan 25 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Nick Sabalausky (a a.a)'s article
 - Like Denis said, I've heard LLVM is supposed to have a plain-C backend,
 but I don't know how far along that is or if it's working with LDC (and from
 what I hear, even LDC itself isn't quite production-ready just yet, but it
 is movng along quickly).
This is true. I've played around w/ this C back end w/ some toy programs and and it works reasonably well, but I forgot about it. At any rate, could this be used as a temporary kludge to get LDC "working" on unsupported platforms like Windows until it works natively? Basically, LDC for Windows and other unsupported platforms would compile the D code to C, and then compile the C code w/ the native C compiler for the platform.
Jan 25 2009
next sibling parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 - Like Denis said, I've heard LLVM is supposed to have a plain-C backend,
 but I don't know how far along that is or if it's working with LDC (and from
 what I hear, even LDC itself isn't quite production-ready just yet, but it
 is movng along quickly).
This is true. I've played around w/ this C back end w/ some toy programs and and it works reasonably well, but I forgot about it. At any rate, could this be used as a temporary kludge to get LDC "working" on unsupported platforms like Windows until it works natively? Basically, LDC for Windows and other unsupported platforms would compile the D code to C, and then compile the C code w/ the native C compiler for the platform.
The problem with LDC on Windows is not that LLVM doesn't have a backend for Windows; it does. It's just that LLVM doesn't yet support Windows exception handling. Using the C backend wouldn't help there.
Jan 25 2009
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s article
 On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 - Like Denis said, I've heard LLVM is supposed to have a plain-C backend,
 but I don't know how far along that is or if it's working with LDC (and from
 what I hear, even LDC itself isn't quite production-ready just yet, but it
 is movng along quickly).
This is true. I've played around w/ this C back end w/ some toy programs and and it works reasonably well, but I forgot about it. At any rate, could this be used as a temporary kludge to get LDC "working" on unsupported platforms like Windows until it works natively? Basically, LDC for Windows and other unsupported platforms would compile the D code to C, and then compile the C code w/ the native C compiler for the platform.
The problem with LDC on Windows is not that LLVM doesn't have a backend for Windows; it does. It's just that LLVM doesn't yet support Windows exception handling. Using the C backend wouldn't help there.
Is there any decent reading material out there about how exception handling is works under the hood and why it can't be done in a cross-platform way at the C level? From reading and participating in discussions about LDC, I've come to realize that implementing exception handling is a *much* harder problem than I would have anticipated, and I've become very curious as to why. Wikipedia would be the obvious place, but it doesn't seem to provide much detail.
Jan 25 2009
parent Kagamin <spam here.lot> writes:
dsimcha Wrote:

 Is there any decent reading material out there about how exception handling is
 works under the hood
Matt Pietrek is famous for such a material. You can also look at NtRaiseException in wine sources.
Jan 26 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 25 Jan 2009 23:01:49 +0300, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:

 On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 - Like Denis said, I've heard LLVM is supposed to have a plain-C  
 backend,
 but I don't know how far along that is or if it's working with LDC  
 (and from
 what I hear, even LDC itself isn't quite production-ready just yet,  
 but it
 is movng along quickly).
This is true. I've played around w/ this C back end w/ some toy programs and and it works reasonably well, but I forgot about it. At any rate, could this be used as a temporary kludge to get LDC "working" on unsupported platforms like Windows until it works natively? Basically, LDC for Windows and other unsupported platforms would compile the D code to C, and then compile the C code w/ the native C compiler for the platform.
The problem with LDC on Windows is not that LLVM doesn't have a backend for Windows; it does. It's just that LLVM doesn't yet support Windows exception handling. Using the C backend wouldn't help there.
Err... Isn't generated C code cross-platform? Code generated for Linux could be used to compile code for Windows, no?
Jan 25 2009
parent Brad Roberts <braddr puremagic.com> writes:
Denis Koroskin wrote:
 On Sun, 25 Jan 2009 23:01:49 +0300, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:
 
 On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 - Like Denis said, I've heard LLVM is supposed to have a plain-C
 backend,
 but I don't know how far along that is or if it's working with LDC
 (and from
 what I hear, even LDC itself isn't quite production-ready just yet,
 but it
 is movng along quickly).
This is true. I've played around w/ this C back end w/ some toy programs and and it works reasonably well, but I forgot about it. At any rate, could this be used as a temporary kludge to get LDC "working" on unsupported platforms like Windows until it works natively? Basically, LDC for Windows and other unsupported platforms would compile the D code to C, and then compile the C code w/ the native C compiler for the platform.
The problem with LDC on Windows is not that LLVM doesn't have a backend for Windows; it does. It's just that LLVM doesn't yet support Windows exception handling. Using the C backend wouldn't help there.
Err... Isn't generated C code cross-platform? Code generated for Linux could be used to compile code for Windows, no?
That presumes that the interfaces are cross-platform, but they're not. The win32 api's are win32 specific. Exception handling specifications are different between windows and unix (nearly all unix os' use the exact same eh specs for the last 10 years or so). Within the unix world, the lowest level syscalls aren't the same across the various flavors. That's why specifications like posix were created. Those interfaces are specifically designed to insulate applications from the lowest level details of cross-system differences. Anyway, if only it was that simple.. :) Later, Brad
Jan 25 2009
prev sibling parent reply Nicolay Korslund <korslund gmail.com> writes:
Jarrett Billingsley Wrote:
 On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 - Like Denis said, I've heard LLVM is supposed to have a plain-C backend,
 but I don't know how far along that is or if it's working with LDC (and from
 what I hear, even LDC itself isn't quite production-ready just yet, but it
 is movng along quickly).
This is true. I've played around w/ this C back end w/ some toy programs and and it works reasonably well, but I forgot about it. At any rate, could this be used as a temporary kludge to get LDC "working" on unsupported platforms like Windows until it works natively? Basically, LDC for Windows and other unsupported platforms would compile the D code to C, and then compile the C code w/ the native C compiler for the platform.
The problem with LDC on Windows is not that LLVM doesn't have a backend for Windows; it does. It's just that LLVM doesn't yet support Windows exception handling. Using the C backend wouldn't help there.
Reviving a slightly dated thread here: The exception problem and C could be sidestepped altogether by compiling to C++ instead of pure C. All the major console SDKs at least will compile C++. This doesn't mean we would need to use any more C++ features like classes or templates, the result could be pretty much "C with exceptions". An added benefit would be automatic eh compatibility with existing C++ code, on all platforms. As a side note, compiling D->C++ could probably be done at a higher level than using C-as-assembler-output, which I suspect is what LLVM will end up doing. This isn't a high priority though. Nico
Feb 06 2009
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Nicolay Korslund wrote:
 The exception problem and C could be sidestepped altogether by compiling to
C++ instead of pure C. All the major console SDKs at least will compile C++.
This doesn't mean we would need to use any more C++ features like classes or
templates, the result could be pretty much "C with exceptions". An added
benefit would be automatic eh compatibility with existing C++ code, on all
platforms.
At the expense of D->D compatibility...
Feb 06 2009
next sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Robert Fraser (fraserofthenight gmail.com)'s article
 Nicolay Korslund wrote:
 The exception problem and C could be sidestepped altogether by compiling to
C++ instead of pure C. All the major console SDKs at least will compile C++. This doesn't mean we would need to use any more C++ features like classes or templates, the result could be pretty much "C with exceptions". An added benefit would be automatic eh compatibility with existing C++ code, on all platforms.
 At the expense of D->D compatibility...
Who cares? If D really takes off as a language, eventually there will be native D compilers for everything. What we need now, though, is a way to get better platform support and solve our chicken and egg problem (not that many people are interested in working on native D compilers for more obscure platforms b/c D isn't that popular, D won't become that popular until there's less FUD about platform support). I think that getting this sooner rather than later would be a good thing even if it is a massive kludge and only works for standalone programs.
Feb 06 2009
prev sibling next sibling parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Robert Fraser wrote:
 Nicolay Korslund wrote:
 The exception problem and C could be sidestepped altogether by
 compiling to C++ instead of pure C. All the major console SDKs at
 least will compile C++. This doesn't mean we would need to use any
 more C++ features like classes or templates, the result could be
 pretty much "C with exceptions". An added benefit would be automatic
 eh compatibility with existing C++ code, on all platforms.
At the expense of D->D compatibility...
huh? I mean... "This doesn't mean we would need to use any more C++ features like classes or templates" The next step is to mark everything extern C, and make sure it's all mangled before it hits codegen (that happens anyways). ABI compatibility is preserved. We win. The only problem I see with this plan is that LLVM supposedly HAS a C backend, but I've yet to hear about any C++ backend. It may be a lot more work than if you can just use some macro/setjmp/etc hacks to make eh work in C.
Feb 06 2009
prev sibling parent Nicolay Korslund <korslund gmail.com> writes:
Robert Fraser Wrote:

 Nicolay Korslund wrote:
 The exception problem and C could be sidestepped altogether by compiling to
C++ instead of pure C. All the major console SDKs at least will compile C++.
This doesn't mean we would need to use any more C++ features like classes or
templates, the result could be pretty much "C with exceptions". An added
benefit would be automatic eh compatibility with existing C++ code, on all
platforms.
At the expense of D->D compatibility...
Well, on these platforms there isn't a D compiler, so ALL D code would have to be use the C++ eh system. D->D compatibility in this case wouldn't be a problem. Nico
Feb 07 2009
prev sibling parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
Nicolay Korslund wrote:
 The exception problem and C could be sidestepped altogether by compiling to
C++ instead of pure C. All the major console SDKs at least will compile C++.
This doesn't mean we would need to use any more C++ features like classes or
templates, the result could be pretty much "C with exceptions". An added
benefit would be automatic eh compatibility with existing C++ code, on all
platforms.
Is the D exception system not expressible in C? I’d much rather not see a greater dependency on C++ than already exists. —Joel Salomon
Feb 07 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Joel C. Salomon wrote:
 Nicolay Korslund wrote:
 The exception problem and C could be sidestepped altogether by compiling to
C++ instead of pure C. All the major console SDKs at least will compile C++.
This doesn't mean we would need to use any more C++ features like classes or
templates, the result could be pretty much "C with exceptions". An added
benefit would be automatic eh compatibility with existing C++ code, on all
platforms.
Is the D exception system not expressible in C? I’d much rather not see a greater dependency on C++ than already exists. —Joel Salomon
You might be able to do it with setjmp/longjmp, but it'd probably be horrible. This isn't a dependency on C++; it's just that C++ has exceptions and C doesn't. The only dependency D has on C++ is that the front end is written in it. Hopefully someone will come along and fix that one day. :) -- Daniel
Feb 07 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Mon, Jan 26, 2009 at 5:01 AM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:
 On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 - Like Denis said, I've heard LLVM is supposed to have a plain-C backend,
 but I don't know how far along that is or if it's working with LDC (and from
 what I hear, even LDC itself isn't quite production-ready just yet, but it
 is movng along quickly).
This is true. I've played around w/ this C back end w/ some toy programs and and it works reasonably well, but I forgot about it. At any rate, could this be used as a temporary kludge to get LDC "working" on unsupported platforms like Windows until it works natively? Basically, LDC for Windows and other unsupported platforms would compile the D code to C, and then compile the C code w/ the native C compiler for the platform.
The problem with LDC on Windows is not that LLVM doesn't have a backend for Windows; it does. It's just that LLVM doesn't yet support Windows exception handling. Using the C backend wouldn't help there.
I would think a C backend would be converting exceptions into portable setjmp/longjmp. That's the only way to emulate exceptions in C as far as I know. Not so? --bb
Jan 25 2009
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Bill Baxter wrote:
 On Mon, Jan 26, 2009 at 5:01 AM, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:
 On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 - Like Denis said, I've heard LLVM is supposed to have a plain-C backend,
 but I don't know how far along that is or if it's working with LDC (and from
 what I hear, even LDC itself isn't quite production-ready just yet, but it
 is movng along quickly).
This is true. I've played around w/ this C back end w/ some toy programs and and it works reasonably well, but I forgot about it. At any rate, could this be used as a temporary kludge to get LDC "working" on unsupported platforms like Windows until it works natively? Basically, LDC for Windows and other unsupported platforms would compile the D code to C, and then compile the C code w/ the native C compiler for the platform.
The problem with LDC on Windows is not that LLVM doesn't have a backend for Windows; it does. It's just that LLVM doesn't yet support Windows exception handling. Using the C backend wouldn't help there.
I would think a C backend would be converting exceptions into portable setjmp/longjmp. That's the only way to emulate exceptions in C as far as I know. Not so? --bb
It could, but then it still wouldn't necessarily interact properly with other C++ or D code eh mechanisms which aren't sjlj based. On unix, sjlj exceptions aren't used anymore. I'm not sure about windows. The presentation I saw that went through win64 showed that at least those weren't sjlj but rather closely matched unix, using lookup tables to do the unwinding. Later, Brad
Jan 25 2009
next sibling parent reply =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= <jeberger free.fr> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brad Roberts wrote:
 Bill Baxter wrote:
 On Mon, Jan 26, 2009 at 5:01 AM, Jarrett Billingsley
 <jarrett.billingsley gmail.com> wrote:
 On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:
 == Quote from Nick Sabalausky (a a.a)'s article
 - Like Denis said, I've heard LLVM is supposed to have a plain-C backend,
 but I don't know how far along that is or if it's working with LDC (and from
 what I hear, even LDC itself isn't quite production-ready just yet, but it
 is movng along quickly).
This is true. I've played around w/ this C back end w/ some toy programs and and it works reasonably well, but I forgot about it. At any rate, could this be used as a temporary kludge to get LDC "working" on unsupported platforms like Windows until it works natively? Basically, LDC for Windows and other unsupported platforms would compile the D code to C, and then compile the C code w/ the native C compiler for the platform.
The problem with LDC on Windows is not that LLVM doesn't have a backend for Windows; it does. It's just that LLVM doesn't yet support Windows exception handling. Using the C backend wouldn't help there.
I would think a C backend would be converting exceptions into portable setjmp/longjmp. That's the only way to emulate exceptions in C as far as I know. Not so? --bb
It could, but then it still wouldn't necessarily interact properly with other C++ or D code eh mechanisms which aren't sjlj based. On unix, sjlj exceptions aren't used anymore. I'm not sure about windows. The presentation I saw that went through win64 showed that at least those weren't sjlj but rather closely matched unix, using lookup tables to do the unwinding.
Mingw gcc uses sjlj still. There is an unofficial version which can use either sjlj or Dwarf2: http://www.tdragon.net/recentgcc/ AFAIK neither will interoperate with VisualC++ eh. The main differences are: - Dwarf2 eh comes at no cost so long as no exception is thrown, sjlj adds calls to setjmp for every try/catch block and for every stack frame in which destructors need to be called; - sjlj can unwind through foreign stack frames (ie an exception is thrown in a callback that was called from a foreign function and the exception is caught in that function's caller) and Dwarf2 cannot. However since any destructor or cleanup code in the foreign stack frames is ignored, this feature is pretty useless anyway. To come back to the topic. I believe it would be a good thing to implement sjlj exception handling in llvm as a general, default system even if some platforms then use a specific model. The reasons are: - sjlj will be portable to any platform without modification, so it will greatly improve portability all around; - sjlj should be reasonably straightforward and easy to implement; - How often do you need to throw exceptions across foreign stack frames anyway? Not that this wouldn't be a nice addition, but I for one would much prefer having exceptions that work in 99.9% of the use cases rather than not having any exceptions at all. Jerome - -- mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkl81vwACgkQd0kWM4JG3k8gZQCgleX69aD9jv1TQdZv27nefH9W 8vUAoKZxOBzIm17A3fZw6I2jIZzH8PGY =jAvI -----END PGP SIGNATURE-----
Jan 25 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Doing Win32 SEH exceptions is not that hard. Dmd's will interoperate 
with VS's. If you look at the phobos source code, and experiment a bit 
compiling samples and looking at the asm output, it should be enough.
Jan 25 2009
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Brad Roberts wrote:
 It could, but then it still wouldn't necessarily interact properly with
 other C++ or D code eh mechanisms which aren't sjlj based.  On unix,
 sjlj exceptions aren't used anymore.  I'm not sure about windows.  The
 presentation I saw that went through win64 showed that at least those
 weren't sjlj but rather closely matched unix, using lookup tables to do
 the unwinding.
If you want to learn about Windows exception handling, ReactOS would be a good place to ask questions.
 Later,
 Brad
Jan 27 2009
prev sibling parent Wolfgang Draxinger <wdraxinger darkstargames.de> writes:
Nicolay Korslund wrote:

 I remember reading something about a D to C compiler on this
 group a few years ago. (I'm not really a regular here anymore,
 so there might have been more recent mentions that I've
 missed.) Does anyone know if there's any such project still
 around that's alive or could be revived? Or if there's any
 other viable solutions for converting D to C (or C++)?
 
 The reason I would want to do this is to port D code to
 currently non-supported platforms. This is especially important
 for game projects (like my own monsterscript project) - most
 game console SDKs take C/C++ and nothing else. The C/C++ output
 wouldn't have to be nice or even human readable - just
 compilable. It would only be used as a middle step in the
 compilation process for these platforms.
 
 Any ideas or suggestions?
There's the "Trivial D compiler" TDC on dsource.org, however it's not been active for years. And I'm working on a similair project, though my compiler will use a laguage derived from D, but with some significant changes, which I call 'D*'. One of the features of D* is, that it's explicitly meant to be compiled into C, and it has a special import mode, in which one can "import" a C header file. Actually the file goes to a full C99 lexer I wrote from scratch. It also takes care of preprocessor constants and stuff like that. Also this special import allows to apply regular expressions to all found itentifiers, so that the identifiers used from the D* source. E.g. extern (C) { namespace gl { import <GL/gl.h> : "s/^gl\.+//", "s/GL_\.+//"; } } would include the OpenGL headers into namespace gl, rewriting all identifers so that one can write gl.Begin(gl.POINTS) instead of gl.glBegin(GL_POINTS) Wolfgang
Jan 28 2009