digitalmars.D - D to C compiler?
- Nicolay Korslund (4/4) Jan 25 2009 I remember reading something about a D to C compiler on this group a few...
- Denis Koroskin (4/17) Jan 25 2009 There were two projects I've heard of, but none of them are functional A...
- Nick Sabalausky (16/29) Jan 25 2009 I don't think there's anything like that in a fully-usable form just yet...
- dsimcha (7/11) Jan 25 2009 This is true. I've played around w/ this C back end w/ some toy program...
- Jarrett Billingsley (4/15) Jan 25 2009 The problem with LDC on Windows is not that LLVM doesn't have a
- dsimcha (7/23) Jan 25 2009 Is there any decent reading material out there about how exception handl...
- Kagamin (2/4) Jan 26 2009 Matt Pietrek is famous for such a material. You can also look at NtRaise...
- Denis Koroskin (2/26) Jan 25 2009 Err... Isn't generated C code cross-platform? Code generated for Linux c...
- Brad Roberts (12/43) Jan 25 2009 That presumes that the interfaces are cross-platform, but they're not.
- Nicolay Korslund (5/22) Feb 06 2009 Reviving a slightly dated thread here:
- Robert Fraser (2/3) Feb 06 2009 At the expense of D->D compatibility...
- dsimcha (12/15) Feb 06 2009 C++ instead of pure C. All the major console SDKs at least will compile ...
- Chad J (11/20) Feb 06 2009 huh?
- Nicolay Korslund (3/7) Feb 07 2009 Well, on these platforms there isn't a D compiler, so ALL D code would h...
- Joel C. Salomon (4/5) Feb 07 2009 Is the D exception system not expressible in C? I’d much rather not se...
- Daniel Keep (7/14) Feb 07 2009 You might be able to do it with setjmp/longjmp, but it'd probably be
- Bill Baxter (6/22) Jan 25 2009 I would think a C backend would be converting exceptions into portable
- Brad Roberts (9/32) Jan 25 2009 It could, but then it still wouldn't necessarily interact properly with
- =?ISO-8859-1?Q?=22J=E9r=F4me_M=2E_Berger=22?= (37/68) Jan 25 2009 -----BEGIN PGP SIGNED MESSAGE-----
- Walter Bright (3/3) Jan 25 2009 Doing Win32 SEH exceptions is not that hard. Dmd's will interoperate
- Christopher Wright (3/11) Jan 27 2009 If you want to learn about Windows exception handling, ReactOS would be
- Wolfgang Draxinger (25/41) Jan 28 2009 There's the "Trivial D compiler" TDC on dsource.org, however it's
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
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? NicoThere 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
"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? NicoI 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
== 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
On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:== Quote from Nick Sabalausky (a a.a)'s articleThe 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.- 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
== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s articleOn Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote: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.== Quote from Nick Sabalausky (a a.a)'s articleThe 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.- 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
dsimcha Wrote:Is there any decent reading material out there about how exception handling is works under the hoodMatt Pietrek is famous for such a material. You can also look at NtRaiseException in wine sources.
Jan 26 2009
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:Err... Isn't generated C code cross-platform? Code generated for Linux could be used to compile code for Windows, no?== Quote from Nick Sabalausky (a a.a)'s articleThe 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.- 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
Denis Koroskin wrote:On Sun, 25 Jan 2009 23:01:49 +0300, Jarrett Billingsley <jarrett.billingsley gmail.com> wrote: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, BradOn Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote:Err... Isn't generated C code cross-platform? Code generated for Linux could be used to compile code for Windows, no?== Quote from Nick Sabalausky (a a.a)'s articleThe 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.- 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
Jarrett Billingsley Wrote:On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote: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== Quote from Nick Sabalausky (a a.a)'s articleThe 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.- 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.
Feb 06 2009
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
== Quote from Robert Fraser (fraserofthenight gmail.com)'s articleNicolay Korslund wrote: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.The exception problem and C could be sidestepped altogether by compiling toAt 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
Robert Fraser wrote:Nicolay Korslund wrote: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.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
Robert Fraser Wrote:Nicolay Korslund wrote: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. NicoThe 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 07 2009
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
Joel C. Salomon wrote:Nicolay Korslund wrote: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. :) -- DanielThe 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
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: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== Quote from Nick Sabalausky (a a.a)'s articleThe 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.- 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
Bill Baxter wrote:On Mon, Jan 26, 2009 at 5:01 AM, Jarrett Billingsley <jarrett.billingsley gmail.com> 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. Later, BradOn Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote: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== Quote from Nick Sabalausky (a a.a)'s articleThe 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.- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brad Roberts wrote:Bill Baxter wrote: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-----On Mon, Jan 26, 2009 at 5:01 AM, Jarrett Billingsley <jarrett.billingsley gmail.com> 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.On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha yahoo.com> wrote: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== Quote from Nick Sabalausky (a a.a)'s articleThe 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.- 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
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
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
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