On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
> 1. DMD can only output OMF binaries
> 2. DMD cannot output 64bit code for Windows
> 3. DMD is not compatible with the MSVC linker or runtime


I intend to fix all of those, at least for 64 bit Windows, in the near term.

On Mon, 18 Jun 2012 10:50:44 -0700, Walter Bright <newshound2@digitalmars.com> wrote:

> On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
>> 1. DMD can only output OMF binaries
>> 2. DMD cannot output 64bit code for Windows
>> 3. DMD is not compatible with the MSVC linker or runtime
>
>
> I intend to fix all of those, at least for 64 bit Windows, in the near term.
>

Does this somewhat vague statement meant that we are getting COFF support in the near term? Because if so, I have some serious plans for source embedding in custom sections. The only thing blocking it is the fact that OMF doesn't support custom sections. Once the source is embedded in libraries, we can finally jettison DI files once and for all! Also would it be possible at this point to clean up the backend such that we have a clean interface for interacting with object files during their construction, given that with COFF, all object format wills be roughly feature equal? Object generation is an unholy disaster of IFDEF's and my brain has melted every time I try to venture into it; but if we have a clean interface for interacting with them it would make it significantly easier to add things like custom sections, which in turn will open up a plethora of new options, including source embedding.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Monday, 18 June 2012 at 17:51:39 UTC, Walter Bright wrote:
> On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
>> 1. DMD can only output OMF binaries
>> 2. DMD cannot output 64bit code for Windows
>> 3. DMD is not compatible with the MSVC linker or runtime
>
>
> I intend to fix all of those, at least for 64 bit Windows, in the near term.

This is great news !

For one of my personal projects I wanted to use LLVM with D, after trying to convert the MSVC .lib to OMF format, linking with Win64GDC and MinGW LLVM (but I didn't include all LLVM libs), I gave up and I booted to my Mac partition where the object and the linker are the same for all.

On 18 June 2012 22:07, <michael.larouche@gmail.com>"@puremagic.com < "\"Michaël".Larouche"> wrote:

> On Monday, 18 June 2012 at 17:51:39 UTC, Walter Bright wrote:
>
>> On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
>>
>>> 1. DMD can only output OMF binaries
>>> 2. DMD cannot output 64bit code for Windows
>>> 3. DMD is not compatible with the MSVC linker or runtime
>>>
>>
>>
>> I intend to fix all of those, at least for 64 bit Windows, in the near term.
>>
>
> This is great news !
>

It really is. I suspect we will see a gigantic boots to the D community on the back of this change! :)

On Monday, June 18, 2012 23:23:02 Manu wrote:
> It really is. I suspect we will see a gigantic boots to the D community on the back of this change! :)

Well, we could all use a good pair of shoes. ;)

- Jonathan M Davis

On 6/18/2012 11:10 AM, Adam Wilson wrote:
> On Mon, 18 Jun 2012 10:50:44 -0700, Walter Bright <newshound2@digitalmars.com>
> wrote:
>
>> On 6/17/2012 3:34 AM, Jacob Carlborg wrote:
>>> 1. DMD can only output OMF binaries
>>> 2. DMD cannot output 64bit code for Windows
>>> 3. DMD is not compatible with the MSVC linker or runtime
>>
>>
>> I intend to fix all of those, at least for 64 bit Windows, in the near term.
>>
>
> Does this somewhat vague statement meant that we are getting COFF support in the
> near term?

Yes, because that is necessary for MSVC linker compatibility.

> Because if so, I have some serious plans for source embedding in
> custom sections. The only thing blocking it is the fact that OMF doesn't support
> custom sections. Once the source is embedded in libraries, we can finally
> jettison DI files once and for all! Also would it be possible at this point to
> clean up the backend such that we have a clean interface for interacting with
> object files during their construction, given that with COFF, all object format
> wills be roughly feature equal?

Probably not, though it will be better.

> Object generation is an unholy disaster of
> IFDEF's and my brain has melted every time I try to venture into it; but if we
> have a clean interface for interacting with them it would make it significantly
> easier to add things like custom sections, which in turn will open up a plethora
> of new options, including source embedding.

Yeah, me too. But fixing that is not so easy.

>> Does this somewhat vague statement meant that we are getting COFF support in the near term?
>
> Yes, because that is necessary for MSVC linker compatibility.

Hooray!

On 2012-06-19 01:22, Walter Bright wrote:
> On 6/18/2012 11:10 AM, Adam Wilson wrote:
>> Object generation is an unholy disaster of
>> IFDEF's and my brain has melted every time I try to venture into it;
>> but if we
>> have a clean interface for interacting with them it would make it
>> significantly
>> easier to add things like custom sections, which in turn will open up
>> a plethora
>> of new options, including source embedding.
>
> Yeah, me too. But fixing that is not so easy.

A start is to have a rigorous set of tests for this part of the compiler. I know the compiler has a test suite but I don't know how much of this particular code is covered.

With a rigorous set of tests one will feel more comfortable in refactoring the code.

Then it just some hard work that will probably take some time. The first thing would probably be to try to put everything platform specific in one place. Ideally there would only be one set of if-def's.
If possible this can happen iteratively in several steps. When a function needs to be changed refactor it as well to make it more clean.

Ideally we don't want to the new COFF backend to become a part of this mess.

-- 
/Jacob Carlborg

On Monday, 18 June 2012 at 20:23:31 UTC, Manu wrote:
> It really is. I suspect we will see a gigantic boots to the D community on
> the back of this change! :)

KickAss would be a cool codename for new object file writing capability in the backend.

> Object generation is an unholy disaster of IFDEF's and my brain has melted
> every time I try to venture into it

Funnily enough, cppcheck shares your opinion on the backend: Interrupted checking because of too many #ifdef configurations