On Friday, 8 March 2013 at 13:02:06 UTC, Jakob Ovrum wrote:
> On Friday, 8 March 2013 at 05:29:14 UTC, Rikki Cattermole wrote:
>> I've actually modified dmd's frontend to support using the VS tool chain for linking 32 bit executables. But I didn't understand the backend to seperate the 32bit binary generation vs 64bit. I believe it shouldn't be too much. But I really don't understand it so if anyone is willing to help on this.
>> I haven't broken 64bit generation as far as I know. Because I added a cli argument (-msvc) which is enabled for -m64 automatically on Windows.
>
> I'd love to have an option like that. Win32 is at the very least going to be a target for many years to come (for some also a development platform) and the OPTLINK/OMF business is a real impediment.

Personally I think of it as a barrier for adoption. A real BIG one for casual devs, which is what we need to grow. It also limits us from getting it into e.g. high schools. Which may at best be using core 2 duo's. Hence why I started working on it. Got so sick of not having it.
Just wish my knowledge extended to how the backend worked because then I could have finished this weeks ago.

On Friday, 8 March 2013 at 17:40:58 UTC, Andrej Mitrovic wrote:
> Honestly D has huge potential for tools like compilers/linkers/etc.
> They're the types of programs where you practically know all your
> requirements at compile-time, so e.g. generics come into play really
> nicely.
>

That is the theory. In practice you'll run in MANY problems.

On Thursday, 7 March 2013 at 15:53:09 UTC, Denis Shelomovskij wrote:
> Didn't get. You don't have to use D with druntime. Just don't link it and everything will be OK - you will just get "better C" (i.e. with D structs and other good stuff).

Walter wrote all about it: http://www.drdobbs.com/architecture-and-design/assembler-to-c/228701319

On Thursday, 7 March 2013 at 01:25:02 UTC, Walter Bright wrote:
> Some months ago, I did make the source to optlink available on github:
>
> https://github.com/DigitalMars/optlink
>
> Rainer Schuetze has improved it where it can be built with modern tools (the older tools would not run on Win7). I know some of you are frustrated by optlink problems. Well, now you can do something about it!
>
> Note that the optlink source is quite a challenge to work on. It's very old skool (80's style).
>
> Here's an approach that I've used successfully to fix optlink seg faults:
>
> 1. Find out where in the source code it is. This is not so easy, even if using a debugger. The trouble is the asm functions do not have standard stack frames, so the debugger cannot do a stack trace. Even where there is a standard stack frame, the modern Microsoft debuggers fail to recognize them. You gotta use an older debugger under Windows XP.
>
> So, what I do, is look at the asm code where the seg fault occurs, and then grep through the asm source till I find it.
>
> 2. Convert the source file where the seg fault occurs to C. I do this one function at a time, running the full set of tests at each step. Otherwise, it's just impossible to figure out where you made a mistake in the conversion. Sometimes, you gotta go even finer grained - using the inline assembler feature of dmc to convert asm code line by line.
>
> You gotta pay very, very close attention to which registers have parameters passed through them, which registers are saved, and which registers have parameters that are silently passed through a function to callees of that function (!). This information is all pretty much utterly lacking in the comments, and the comments are often dead wrong as they refer to much older versions of the code.
>
> 3. Once it is in C, things get a lot easier. You can, for example, insert printf's to figure out where things go wrong, and *then* fix it.
>
>
> The full test suite for optlink has a lot of stuff I cannot publish on github. However, what you can do is run the win32 tests for dmd. I, of course, will run the full one when verifying pulls.
>
> Happy hacking!

Most people would consider this an exercise in self-flagellation, but I enjoy doing it.

http://www.drdobbs.com/architecture-and-design/assembler-to-c/228701319

On Thu, 07 Mar 2013 19:41:10 -0800
Walter Bright <newshound2@digitalmars.com> wrote:
> 
> I don't want to discourage people from trying to come up with a replacement linker for win32 written in D. I think that is a great project. But while a linker is a conceptually simple program, the awful file formats involved make it unnecessarily difficult and there are simply a lot of details and other things one has to do.
> 
> Like I said before, it'll take a sustained and determined effort to come up with a viable replacement for optlink.
> 

Interesting thing about this, is that if/when we did have this "new
linker" as discussed (including separation of individual object file
formats) is that we could also add in our own object file format
designed (and proven via a good test suite) to be much less quirky and
badly documented. Or, you know, not quirky and not badly
documented ;) Thus, at the very least, opening a door for others to
migrate, and potentially/finally/eventually get rid of the crufty
current formats. I mean, like you said, linkers are very simple
conceptually. So if they *can* be so simple, why should everyone have
to continue to stay stuck with a crappy one?

Just my random thoughts on it anyway.

On 3/8/2013 11:29 PM, Nick Sabalausky wrote:
> So if they *can* be so simple, why should everyone have
> to continue to stay stuck with a crappy one?

That's a good question. It's surprising how excessively complicated most designs are.

Am Thu, 07 Mar 2013 19:53:29 +0400
schrieb Denis Shelomovskij <verylonglogin.reg@gmail.com>:

> 07.03.2013 14:28, Jacob Carlborg пишет:
> > On 2013-03-07 11:12, Moritz Maxeiner wrote:
> >
> >> Sorry if this has been answered before/is common knowledge, but is porting functions at a time to C wanted for optlink in general, or only for finding segfaults? (e.g. are pull-requests for that welcome)
> >
> > Yes, in general. I think the idea is to port the whole Optlink to C and then to D. It's easier to port from C to D than from assembly to D. This is because you can use a C version that doesn't use the runtime or standard library to get the generate assembly as close as possible to the original one. I think it was something like that.
> >
> 
> Didn't get. You don't have to use D with druntime. Just don't link it and everything will be OK - you will just get "better C" (i.e. with D structs and other good stuff).
> 

That's a little bit oversimplified. Even a simple POD struct references
the TypeInfo_Struct declaration in druntime. There's still some
compiler work needed to really make D usable without druntime. (Think
of issues like these: If you don't have druntime -> you don't have
typeinfo -> no D style varargs -> no associative arrays; you can't even
compare normal arrays (https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/adi.d#L368))

On Saturday, 9 March 2013 at 09:11:54 UTC, Johannes Pfau wrote:
> Am Thu, 07 Mar 2013 19:53:29 +0400
> schrieb Denis Shelomovskij <verylonglogin.reg@gmail.com>:
>
>> 07.03.2013 14:28, Jacob Carlborg пишет:
>> > On 2013-03-07 11:12, Moritz Maxeiner wrote:
>> >
>> >> Sorry if this has been answered before/is common knowledge, but is
>> >> porting functions at a time to C wanted for optlink in general, or
>> >> only for finding segfaults? (e.g. are pull-requests for that
>> >> welcome)
>> >
>> > Yes, in general. I think the idea is to port the whole Optlink to C
>> > and then to D. It's easier to port from C to D than from assembly
>> > to D. This is because you can use a C version that doesn't use the
>> > runtime or standard library to get the generate assembly as close
>> > as possible to the original one. I think it was something like that.
>> >
>> 
>> Didn't get. You don't have to use D with druntime. Just don't link it and everything will be OK - you will just get "better C" (i.e. with D structs and other good stuff).
>> 
>
> That's a little bit oversimplified. Even a simple POD struct references
> the TypeInfo_Struct declaration in druntime. There's still some
> compiler work needed to really make D usable without druntime. (Think
> of issues like these: If you don't have druntime -> you don't have
> typeinfo -> no D style varargs -> no associative arrays; you can't even
> compare normal arrays (https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/adi.d#L368))

It can be easily checked with "-betterC -defaultlib=" combo. You can skip phobos, druntime, use only C stdlib and look what will remain working in the language. Not much.

Am Sat, 09 Mar 2013 10:32:18 +0100
schrieb "Dicebot" <m.strashun@gmail.com>:

> On Saturday, 9 March 2013 at 09:11:54 UTC, Johannes Pfau wrote:
> > Am Thu, 07 Mar 2013 19:53:29 +0400
> > schrieb Denis Shelomovskij <verylonglogin.reg@gmail.com>:
> >
> >> 07.03.2013 14:28, Jacob Carlborg пишет:
> >> > On 2013-03-07 11:12, Moritz Maxeiner wrote:
> >> >
> >> >> Sorry if this has been answered before/is common knowledge,
> >> >> but is
> >> >> porting functions at a time to C wanted for optlink in
> >> >> general, or
> >> >> only for finding segfaults? (e.g. are pull-requests for that
> >> >> welcome)
> >> >
> >> > Yes, in general. I think the idea is to port the whole
> >> > Optlink to C
> >> > and then to D. It's easier to port from C to D than from
> >> > assembly
> >> > to D. This is because you can use a C version that doesn't
> >> > use the
> >> > runtime or standard library to get the generate assembly as
> >> > close
> >> > as possible to the original one. I think it was something
> >> > like that.
> >> >
> >> 
> >> Didn't get. You don't have to use D with druntime. Just don't link it and everything will be OK - you will just get "better C" (i.e. with D structs and other good stuff).
> >> 
> >
> > That's a little bit oversimplified. Even a simple POD struct
> > references
> > the TypeInfo_Struct declaration in druntime. There's still some
> > compiler work needed to really make D usable without druntime.
> > (Think
> > of issues like these: If you don't have druntime -> you don't
> > have
> > typeinfo -> no D style varargs -> no associative arrays; you
> > can't even
> > compare normal arrays
> > (https://github.com/D-Programming-Language/druntime/blob/e47a00bff935c3f079bb567a6ec97663ba384487/src/rt/adi.d#L368))
> 
> It can be easily checked with "-betterC -defaultlib=" combo. You can skip phobos, druntime, use only C stdlib and look what will remain working in the language. Not much.

I know that, I've run D code on the DS without druntime and on
Android as well, but betterC only disables moduleinfo, not typeinfo. So
you don't even get structs without druntime and that is certainly not
better than C.

test.d:
-------
struct A
{
}
-------

dmd -betterC -defaultlib= -c test.d
nm test.o
U _D15TypeInfo_Struct6__vtblZ

Ye, sure, I wanted to support your point with practical example, not object it by any means. By the way, templates and array literals I have tried were doomed, too :)