Related to the LDC (LLVMDC), at the moment it's for D1, but when you want to adapt LDC to D2, this may be used to implement its closures. This stuff will be present in LLVM 2.4 that will be out in about two weeks:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html

>This feature is similar to nested functions and closures, but does not require stack trampolines (with most ABIs) and supports returning closures from functions that define them. Note that actually using Blocks requires a small runtime that is not included with llvm-gcc.<

Bye,
bearophile

Bruno Medeiros Wrote:
> Robert Fraser wrote:
> > I hope so, but realistically LDC only works on x86 Linux and there's a lot of work getting it to work on other platforms (much of this work on LLVM itself instead of just LDC).
> 
> What do you mean? Are there any significant issues with LLVM itself on the Windows platform?

Namely structured exception handling.

I'd actually like to see a Phoenix compiler on Windows. Many Windows developers use MSVC, and being able to statically link to MSVC-generated code will help in migration of existing codebases to D (DMD uses the same object format as MS, but it won't link). It would also open the door to CLI support (shall we call it D.NET or D#?).

bearophile wrote:
> Related to the LDC (LLVMDC), at the moment it's for D1, but when you want to adapt LDC to D2, this may be used to implement its closures. This stuff will be present in LLVM 2.4 that will be out in about two weeks:
> 
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-August/002670.html
> 
>> This feature is similar to nested functions and closures, but does not require stack trampolines (with most ABIs) and supports returning closures from functions that define them. Note that actually using Blocks requires a small runtime that is not included with llvm-gcc.<
> 
> Bye,
> bearophile

From what I read 'Blocks' is not part of LLVM, just implemented on top of it. We'll probably do our own implementation of closures when we get to D2 (whenever that may be).

We already do things quite differently for D1's nested functions (compared to DMD).

Robert Fraser wrote:
> Bruno Medeiros Wrote:
>> Robert Fraser wrote:
>>> I hope so, but realistically LDC only works on x86 Linux and there's a lot of work getting it to work on other platforms (much of this work on LLVM itself instead of just LDC).
>> What do you mean? Are there any significant issues with LLVM itself on the Windows platform?
> 
> Namely structured exception handling.
> 
> I'd actually like to see a Phoenix compiler on Windows. Many Windows developers use MSVC, and being able to statically link to MSVC-generated code will help in migration of existing codebases to D (DMD uses the same object format as MS, but it won't link). It would also open the door to CLI support (shall we call it D.NET or D#?).

In the end LLVM could get us all that. There's already work getting LLVM do work with MSVC and there is actually a MSIL backend for LLVM as well.

Tomas Lindquist Olsen:

> We'll probably do our own implementation of closures when we get to D2 (whenever that may be).<

I see.


> We already do things quite differently for D1's nested functions (compared to DMD).<

May I ask what's the difference? I am curious.

Bye and thank you,
bearophile

Tomas Lindquist Olsen wrote:
> Robert Fraser wrote:
>> Bruno Medeiros Wrote:
>>> Robert Fraser wrote:
>>>> I hope so, but realistically LDC only works on x86 Linux and there's a lot of work getting it to work on other platforms (much of this work on LLVM itself instead of just LDC).
>>> What do you mean? Are there any significant issues with LLVM itself on the Windows platform?
>>
>> Namely structured exception handling.
>>
>> I'd actually like to see a Phoenix compiler on Windows. Many Windows developers use MSVC, and being able to statically link to MSVC-generated code will help in migration of existing codebases to D (DMD uses the same object format as MS, but it won't link). It would also open the door to CLI support (shall we call it D.NET or D#?).
> 
> In the end LLVM could get us all that. There's already work getting LLVM do work with MSVC and there is actually a MSIL backend for LLVM as well.

True, but considering the calisthenics it takes to build LLVM *itself* under VS, I don't know how they'll ever get LLVM-generated code linking with MS-generated code.

That being said, LLVMDC for Windows is the low-lying fruit here; an entire Phoenix-based compiler would be a lot more work.