Hi, now I am conviced. Thanks for the explanation.
-- Paulo "Walter Bright" <[email protected]> wrote in message news:[email protected]... > 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.
