Optlink Contribution

[Walter Bright via Digitalmars-d]

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.