On Wednesday, 30 July 2014 at 09:06:11 UTC, Rikki Cattermole wrote:
> If we obsoleted the OMF format output we would need to have a free and distributed with PE-COFF linker.

GNU binutils should do.

On Wednesday, 30 July 2014 at 09:17:05 UTC, Joakim wrote:
> On Wednesday, 30 July 2014 at 09:06:11 UTC, Rikki Cattermole wrote:
>> On 30/07/2014 8:58 p.m., Joakim wrote:
>>> On Wednesday, 30 July 2014 at 08:12:17 UTC, Rikki Cattermole wrote:
>>>> On 30/07/2014 7:03 p.m., Kagamin wrote:
>>>>> Making dmd generate coff would make more sense.
>>>> +1
>>>> Most of the code should already be present in dmd, which makes it far
>>>> crazier not to.
>>>
>>> What makes it craziest is that there's a COFF32 branch lying around that
>>> nobody merges:
>>>
>>> http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmars-d@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com
>>>
>>>
>>> It would be a far better use of Jonathan's time to get COFF32 merged and
>>> obsolete Optlink altogether.
>>
>> If we obsoleted the OMF format output we would need to have a free and distributed with PE-COFF linker. If we can do this, I think Walter might go along with it.
>>
>> Unless of course we could convince Microsoft to have a download just for the linker. We could download that in e.g. the installer. Would be better than a full install.
>
> I don't think dmd comes with a COFF64 linker now, users are just told to install Visual Studio or the Windows SDK for a linker.  No reason you can't do the same with COFF32.  Optlink can stick around with OMF for a couple releases.  I suspect nobody would use it when given the choice of COFF32 support.

I think it's important to ship with a linker without requiring any further installation. One of the things that helped me to learn D was being able to download DMD and run RDMD on Windows without installing anything else. It's not obvious to very new users who don't come from a Windows C++ background where you can get a gratis Microsoft compiler or how to configure it. If we were going to switch to COFF32, it would be a big bonus to ship a COFF32 linker in the installer.

"w0rp"  wrote in message news:sinwmhzuvhmevqtunxms@forum.dlang.org...

> I think it's important to ship with a linker without requiring any further installation. One of the things that helped me to learn D was being able to download DMD and run RDMD on Windows without installing anything else. It's not obvious to very new users who don't come from a Windows C++ background where you can get a gratis Microsoft compiler or how to configure it. If we were going to switch to COFF32, it would be a big bonus to ship a COFF32 linker in the installer.

FWIW this was the plan when I started ylink.  I wanted to make a linker that could link omf and coff together, so I could tackle the object-format and runtime-format transitions independently.  It does support mscoff32 hello world now, but not much more.  Until it has debug info support it's not a viable replacement for optlink unfortunately. 

On Wednesday, 30 July 2014 at 13:03:30 UTC, Daniel Murphy wrote:
> "w0rp"  wrote in message news:sinwmhzuvhmevqtunxms@forum.dlang.org...
>
>> I think it's important to ship with a linker without requiring any further installation. One of the things that helped me to learn D was being able to download DMD and run RDMD on Windows without installing anything else. It's not obvious to very new users who don't come from a Windows C++ background where you can get a gratis Microsoft compiler or how to configure it. If we were going to switch to COFF32, it would be a big bonus to ship a COFF32 linker in the installer.
>
> FWIW this was the plan when I started ylink.  I wanted to make a linker that could link omf and coff together, so I could tackle the object-format and runtime-format transitions independently.  It does support mscoff32 hello world now, but not much more.  Until it has debug info support it's not a viable replacement for optlink unfortunately.

I didn't know about ylink. The prospect of having a free software linker for D on Win32 written in D does sound attractive. I assume it would be a lot of work to make it acceptable for usage.

"w0rp"  wrote in message news:vnaffnibgvtmqeuhzczx@forum.dlang.org...

> I didn't know about ylink. The prospect of having a free software linker for D on Win32 written in D does sound attractive. I assume it would be a lot of work to make it acceptable for usage.

I would estimate it's a smaller effort than DDMD.  (win32 + omf + cv4)

We really don't need to match the performance and memory usage of optlink.

The best part is we can then potentially re-use parts of it inside dmd, currently dmd has its own lib generator for each format. 

> I don't think dmd comes with a COFF64 linker now, users are just told to install Visual Studio or the Windows SDK for a linker.  No reason you can't do the same with COFF32.  Optlink can stick around with OMF for a couple releases.  I suspect nobody would use it when given the choice of COFF32 support.

Anybody seriously programming on Windows uses VS anyway.
But at least for 32 bit http://lld.llvm.org/windows_support.html could be packaged.

I like the discussion.  I do want to remind everyone that OPTLINK is very fast and switching to a different linker will likely result performance hit.  There are advantages to using COFF as it seems more compilers use that format and D would be more interoperable with other compilers and languages.  I think every peice of software has it's own goals which determine what tradeoffs to chose.  In my view, the linker should 1) always work and 2) be as fast as possible.  OPTLINK passes number 2 with flying colors but is does have bugs.  This is obviously due to the fact that it is written in assembly but keep in mind that the performance of the linker affects everyone who uses D.  Any performance hit on the linker will be seen in every single build of any D program. Adding 1 second to link time will add 1 second to build time since this process cannot be parallelized (as far as I know).

That being said, if it were up to me I wouldn't abandon OPTLINK so quickly.  I would spend time creating a test suite for OPTLINK, and try to comment the code a little better to encourage other developers to contribute.  Then I would consider adding support in DMD to generate COFF output files for those who want to link D object files with another linker. I wouldn't make this a huge priority though as one can use an OMF to COFF converter if they really needed it.

> What makes it craziest is that there's a COFF32 branch lying around that nobody merges:
>
> http://forum.dlang.org/thread/mailman.1560.1323886804.24802.digitalmars-d@puremagic.com?page=9#post-llldfc:242q6p:241:40digitalmars.com

Same procedure as every year.

On Wednesday, 30 July 2014 at 19:50:35 UTC, Jonathan Marler wrote:
> I like the discussion.  I do want to remind everyone that OPTLINK is very fast and switching to a different linker will likely result performance hit.

Wouldn't it be easier to optimize a linker written in D than tinker with optlink?

On Thursday, 31 July 2014 at 06:46:19 UTC, Kagamin wrote:
> On Wednesday, 30 July 2014 at 19:50:35 UTC, Jonathan Marler wrote:
>> I like the discussion.  I do want to remind everyone that OPTLINK is very fast and switching to a different linker will likely result performance hit.
>
> Wouldn't it be easier to optimize a linker written in D than tinker with optlink?

No matter how much you optimize your D code, you will only ever be able to use a subset of what assembly can do.  That being said, writing perfect assembly code is impossible, so we rely on the compiler to take our higher level concepts and have it decide on the best way to optimize.  The beauty of higher level languages is you can make high level changes resulting an a cascade of optimizations.  But the downside is sometimes changes can have cascading adverse affects as well.  One of the things I like about D is that it does a much better job of allowing the programmer to tell the compiler the "right" information it needs to know how to optimize.

I would like to see a linker written in D and see how it compares to optlink.  But I would reserve making a decision on moving to another linker until I got some solid performance data.  Some performance data for a D linker compiled with all three D compilers as well.