Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function.

One might ask, why not convert it to D? The answer is that I don't have a good test suite for optlink, so I have to be very very careful to not make a mistake in the translation. That means do one function at a time, rebuild, and retest, which means the compiled C code has to match the segment, naming and calling conventions used in optlink. I made a custom version of the dmc compiler to do this. Also, C can be made to work without any runtime library support at all, and since optlink does not use the C runtime library, this is useful.

Once it is in C and working, it will be trivial to translate it to D and start rewriting it.

Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).

The fix will go out in the next update, if you need it sooner please email me.

This is the too many fixups bug?!
If so that's great news.

So is it any slower now with things not in ASM?

--bb

On Tue, Nov 3, 2009 at 10:39 AM, Walter Bright <newshound1@digitalmars.com> wrote:
> Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function.
>
> One might ask, why not convert it to D? The answer is that I don't have a good test suite for optlink, so I have to be very very careful to not make a mistake in the translation. That means do one function at a time, rebuild, and retest, which means the compiled C code has to match the segment, naming and calling conventions used in optlink. I made a custom version of the dmc compiler to do this. Also, C can be made to work without any runtime library support at all, and since optlink does not use the C runtime library, this is useful.
>
> Once it is in C and working, it will be trivial to translate it to D and start rewriting it.
>
> Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
>
> The fix will go out in the next update, if you need it sooner please email me.
>

Bill Baxter wrote:
> This is the too many fixups bug?!
> If so that's great news.

Yah.

http://d.puremagic.com/issues/show_bug.cgi?id=424

Andrei

Bill Baxter wrote:
> So is it any slower now with things not in ASM?

Haven't measured it, but I doubt it, as it's only about 5% in C now.

Although asm code can be very small and fast, and optlink is the best of the best at that, it tends to be brittle (very hard to change the algorithm). The biggest speed gains are from algorithmic improvements.

"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hcptci$l06$1@digitalmars.com...
> [great optlink news]

That's great news!

Am I dreaming? This is too good to be true :O Walter, have you been replaced by an alien or reprogrammed using some sci-fi device? I can't believe the MsgBox of death is going away!


-- 
Tomasz Stachowiak
http://h3.team0xf.com/
h3/h3r3tic on #D freenode

Walter Bright Wrote:

> Optlink is written entirely in rather impenetrable assembler code, and is resistant to understanding and modification. Hence, over the last few months I've been very slowly converting it to C, function by function.
> 
> One might ask, why not convert it to D? The answer is that I don't have a good test suite for optlink, so I have to be very very careful to not make a mistake in the translation. That means do one function at a time, rebuild, and retest, which means the compiled C code has to match the segment, naming and calling conventions used in optlink. I made a custom version of the dmc compiler to do this. Also, C can be made to work without any runtime library support at all, and since optlink does not use the C runtime library, this is useful.
> 
> Once it is in C and working, it will be trivial to translate it to D and start rewriting it.
> 
> Anyhow, during this process I stumbled upon what the problem was. Optlink was apparently trying to account for some Borland obscure extension to the OMF. Remove this, and it works, although presumably it will no longer link Borland object files (who cares!).
> 
> The fix will go out in the next update, if you need it sooner please email me.

Why not changing object format instead and using format acceptable by the linker from MinGW suit? That could free you from rewriting the linker in C, then in D and then maintaining it. Are there any difficulties (technical or even licensing)?

Eldar Insafutdinov wrote:
> Why not changing object format instead and using format acceptable by
> the linker from MinGW suit? That could free you from rewriting the
> linker in C, then in D and then maintaining it. Are there any
> difficulties (technical or even licensing)?

I'd have to give up the entire toolchain on windows to do that.

Also, the gnu linker is dog slow.

Walter Bright Wrote:

> Eldar Insafutdinov wrote:
> > Why not changing object format instead and using format acceptable by the linker from MinGW suit? That could free you from rewriting the linker in C, then in D and then maintaining it. Are there any difficulties (technical or even licensing)?
> 
> I'd have to give up the entire toolchain on windows to do that.
> 
> Also, the gnu linker is dog slow.

Ok, thank you for the answer and for fixing optlink!

On 03/11/2009 20:39, Walter Bright wrote:
> Optlink is written entirely in rather impenetrable assembler code, and
> is resistant to understanding and modification. Hence, over the last few
> months I've been very slowly converting it to C, function by function.
>
> One might ask, why not convert it to D? The answer is that I don't have
> a good test suite for optlink, so I have to be very very careful to not
> make a mistake in the translation. That means do one function at a time,
> rebuild, and retest, which means the compiled C code has to match the
> segment, naming and calling conventions used in optlink. I made a custom
> version of the dmc compiler to do this. Also, C can be made to work
> without any runtime library support at all, and since optlink does not
> use the C runtime library, this is useful.
>
> Once it is in C and working, it will be trivial to translate it to D and
> start rewriting it.
>
> Anyhow, during this process I stumbled upon what the problem was.
> Optlink was apparently trying to account for some Borland obscure
> extension to the OMF. Remove this, and it works, although presumably it
> will no longer link Borland object files (who cares!).
>
> The fix will go out in the next update, if you need it sooner please
> email me.

awesome news! Once Optlink is moved to C and than D, it could grow new features like link-time optimizations.