Am Sat, 09 Mar 2013 11:35:42 +0100
schrieb "Dicebot" <m.strashun@gmail.com>:

> 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 :)

Really, templates also don't work? There's a lot of work required till betterC is finished...

Am Sat, 09 Mar 2013 11:35:42 +0100
schrieb "Dicebot" <m.strashun@gmail.com>:

> 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 :)

Sorry, I misunderstood that then.

On 3/9/13, deadalnix <deadalnix@gmail.com> wrote:
> 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.
>

In practice I'm getting quite fed up with linker bugs, or DMD object gen bugs which cause the linker to choke. :)

On 3/7/13, Daniel Murphy <yebblies@nospamgmail.com> wrote:
> If anyone is interested I'll put it up on github.

I'd be interested, please do put it online when you get the time.

On Thursday, 7 March 2013 at 06:34:05 UTC, H. S. Teoh wrote:
> Man, that brings back the memories. I remember doing those kinds of
> stunts when coding for the good ole Motorola 6502. Back in those days,
Well, there never was a 'Motorola' 6502, in fact the manufacturer MOS Technologies (though founded by former Motorola employees) was a competitor to Motorola (which had released the 6800, which was similar but 10x as expensive) and was sued by Motorola at some point for patent infringements just before being bought up by Commodore...

Ralf

On Friday, 8 March 2013 at 17:40:58 UTC, Andrej Mitrovic wrote:
> On 3/8/13, Walter Bright <newshound2@digitalmars.com> wrote:
>> On 3/7/2013 8:16 PM, Brad Roberts wrote:
>>> Personally, even though I don't use win32, I believe that moving it over
>>> to use the VS toolchain and runtime is the
>>> right path forward.
>>
>> I like being able to provide a completely free D toolchain for win32.
>
> s/for win32/./
>
> :)
>
> 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.
>


Personally I prefer FP based languages for this type of work, given how easy it is to manipulate ASTs.

--
Paulo

On Thursday, 7 March 2013 at 14:42:25 UTC, Marco Leise wrote:
> On Thu, Mar 07, 2013 at 07:09:22AM +0100, Lars T. Kyllingstad
> wrote:
>
>> This reminds me of http://www.catb.org/jargon/html/story-of-mel.html
>
> Good story! Imagine how Mel must have known the entire program
> by heart and he never got any change requests that are so common today.
> I would have been addicted to that, too. But luckily 1975 was 8
> years before my birth and so I started "hacking" with QBasic
> Gorillaz, a turn based strategy game.

> I guess with SSE it still today makes sense to count
> instruction delays and throughput. Also take a look at this:
> http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf
> I don't think people like this programmer Mel are job-less
> today.

True, although I think this type of work is very complicated to do nowadays given how modern architectures work.

Only in simple CPU architectures it is possible to know the effect each instruction still has, whereas with modern ones you have to use some kind of profiler/code analyzer even for Assembly code, given the multiple level caches, parallel execution of instructions, instruction re-ordering and so on.

--
Paulo

"Jacob Carlborg"  wrote in message news:khaqhb$on0$1@digitalmars.com... 

On 2013-03-07 13:35, Daniel Murphy wrote:

> > If anyone is interested I'll put it up on github.
> 
> I would say put it there to see how much interest there is.

Better late than never...

https://github.com/yebblies/ylink

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!

Is this the current linker used by DMD on all platforms?

Very noob question about binary files. What else also put the code to load at right address (say, 0x08048000 on linux) of operating system is needed to a program run?