tooling quality and some random rant

[Paulo Pinto]

Hi,

now I am conviced. Thanks for the explanation.

--
Paulo

"Walter Bright" <newshound2 at digitalmars.com> wrote in message 
news:ij99gb$18fm$1 at digitalmars.com...
> Paulo Pinto wrote:
>> Why C and not directly D?
>>
>> It is really bad adversting for D to know that when its creator came 
>> around to rewrite the linker, Walter decided to use C instead of D.
>
> That's a very good question.
>
> The answer is in the technical details of transitioning optlink from an 
> all assembler project to a higher level language. I do it function by 
> function, meaning there will be hundreds of "hybrid" versions that are 
> partly in the high level language, partly in asm. Currently, it's around 
> 5% in C.
>
> 1. Optlink has its own "runtime" system and startup code. With C, and a 
> little knowledge about how things work under the hood, it's easier to 
> create "headless" functions that require zero runtime and startup support. 
> With D, the D compiler will create ModuleInfo and TypeInfo objects, which 
> more or less rely on some sort of D runtime existing.
>
> 2. The group/segment names emitted by the C compiler match what Optlink 
> uses. It matches what dmd does, too, except that dmd emits more such 
> names, requiring more of an understanding of Optlink to get them in the 
> right places.
>
> 3. The hybrid intermediate versions require that the asm portions of 
> Optlink be able to call the high level language functions. In order to 
> avoid an error-prone editting of scores of files, it is very convenient to 
> have the function names used by the asm code exactly match the names 
> emitted by the compiler. I accomplished this by "tweaking" the dmc C 
> compiler. I didn't really want to mess with the D compiler to do the same.
>
> 4. Translating asm to a high level language starts with a rote 
> translation, i.e. using goto's, raw pointers, etc., which match 1:1 with 
> the assembler logic. No attempt is made to infer higher level logic. This 
> makes mistakes in the translation easier to find. But it's not the way 
> anyone in their right mind would develop C code. The higher level 
> abstractions in C are not useful here, and neither are the higher level 
> abstractions in D.
>
> Once the entire Optlink code base has been converted, then it becomes a 
> simple process to:
>
> 1. Dump the Optlink runtime, and switch to the C runtime.
>
> 2. Translate the C code to D.
>
> And then:
>
> 3. Refactor the D code into higher level abstractions.
>
>
> I've converted a massive code base from asm to C++ before (DASH for Data 
> I/O) and I discovered that attempting to refactor the code while 
> translating it is fraught with disaster. Doing the hybrid approach is much 
> faster and more likely to be successful.
>
>
> TL,DR: The C version is there only as a transitional step, as it's 
> somewhat easier to create a hybrid asm/C code base than a hybrid asm/D 
> one. The goal is to create a D version.