D to C compiler?

["Jérôme M. Berger"]

-----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 at gmail.com> wrote:
>>> On Sun, Jan 25, 2009 at 2:11 PM, dsimcha <dsimcha at yahoo.com> wrote:
>>>> == Quote from Nick Sabalausky (a at 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 at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkl81vwACgkQd0kWM4JG3k8gZQCgleX69aD9jv1TQdZv27nefH9W
8vUAoKZxOBzIm17A3fZw6I2jIZzH8PGY
=jAvI
-----END PGP SIGNATURE-----