On 7/29/2014 10:53 PM, Jonathan Marler wrote:
I'm attempting to fix https://issues.dlang.org/show_bug.cgi?id=4831. I've been
debugging the optlink assembly and getting familiar with the code. I have a
couple questions though:
1. If I have any questions in the future about optlink who and where do I ask
these questions? For now I'm posting to this forum because I'm not sure where
else to send them.
I'm really the only person, except a couple others who have submitted PRs
against optlink.
2. Why are the assembly labels in this format: L<number>$? I ask because I
changed the labels for some functions so when I stepped through the assembly I
had a better idea of what the code was doing. So I'm not sure if I should leave
the new labels or go back to the old L<number>$ labels.
No known reason.
3. Is there any documentation for developers who would like to contribute to
optlink? I'd like to make sure I'm following any style rules or guidelines.
The fundamental problem with fixing optlink is there is essentially no test
suite. This means that any fixes to it need to be surgical - as little code
modified as practical, and pretty great care in doing it. Wholesale refactoring
"just because" or for "cleanup" are out of the question. Wholesale reformatting
is also out of the question.
Once what a function does is figured out, and its inputs and outputs identified,
adding comments to that effect is appreciated. Most functions in Optlink do not
identify what registers are used as input, what registers are used for output,
and which registers must be preserved. Some functions even return results in
flags. There is no consistency. To identify these, one must look at every call
of that function.
Any information about developing for optlink would be helpful. I haven't found
much information online. Thanks for any help, I'd like to start contributing to
the D tools, its a crime to let all these bugs live on for so long when they are
making adopting this language a hindrence for others.
I appreciate you stepping up to make a difference on this.
What I've done to fix bugs in Optlink is to first identify where in the code
things go wrong. Then, I convert that section of code to C. The C code, line by
line, mirrors the assembler. Then I fix the C code. This makes things much
easier because I can use printf, etc., in the C code.
