tooling quality and some random rant

[spir]

On 02/13/2011 07:53 PM, Walter Bright wrote:
> 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.

Great! Thank you very much for this clear & comprehensive explanation of the 
process, Walter. (*)

Denis

(I can understand what you mean with this 2-stage translation --beeing easier, 
safer, and finally far more efficient-- having done something similar, but at a 
smaller-scale, probably, in the field of automation; where languages are often 
even closer to asm than C, 'cause much "memory" is in fact binary IO cards, 
directly accessed as is.)
-- 
_________________
vita es estrany
spir.wikidot.com