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

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.

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.

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

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

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

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

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

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.

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