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
