[fpc-devel] Parallel processing in the compiler

[Florian Klaempfl]

Am 06.09.2010 16:12, schrieb Hans-Peter Diettrich:
> Florian Klaempfl schrieb:
> 
>>> I have no real idea, how in such a model the initialization of the
>>> threadvars has to be implemented. That's why I try to assign all
>>> state-related variables to a definite object, whose reference can be
>>> easily copied (or moved?) into any created thread.
>>
>> In case of current_filepos, the initialization could be done by the
>> specific worker thread class doing e.g. code generation.
> 
> I see the main problem in the identification of all the global
> variables, that have to become threadvars. Or do you know of an way, to
> make the compiler identify variables that have to become threadvars?

No.

> Another more recent experiment was to convert the back-ends into
> classes. It turned out that much target-specific code resides in the
> general compiler units, whose separation into virtual back-end methods
> would involve much work. In another approach the $IFDEFs could be
> replaced by ordinary IFs, what would both simplify the redesign and
> preserve the current compiler speed.

You still didn't point out which locations you actually mean.

> 
> 
>>> The current compiler "structure" is
>>> dictated by purely *formal* aspects (unit dependencies), and does not
>>> reflect the *logical* dependencies between objects, variables,
>>> procedures etc. 
>>
>> The problem is (very simplified): in a compiler everything depends on
>> everything, so getting some structure is only possible with some
>> formalism, formalism is the last resort when logic does not work
>> anymore. Formalism is also something absolute while logic might be
>> rather subjective.
> 
> I dare to disagree. It's not so hard to encapsulate everything in
> dedicated (mostly existing) classes. Only the requirement, that
> *external* tools should be able to use part of the compiler, without
> importing too many dependencies, results in the implementation of
> otherwise unneeded hacks and workarounds. In a radical OO redesign the
> number of involved units (and global variables) could be reduced
> dramatically, 

Why do you want to reduce them? Logic or formalism?

> so that finally the compiler could be decomposed into a
> small number of building blocks (packages...), with tiny interfaces to
> each other.

Counter example: your attempt of the OOP parser :)

> 
> 
>>> This lack of logical structure, next lack of up-to-date
>>> documentation, 
>>
>> Nobody volounteered yet to continue Carl's work of documenting the
>> compiler.
> 
> Where can this work be found? Do you mean the 1.x PDF document, that is
> not helpful with newer versions?

Yes.

> 
> As mentioned above, I've started an documentation attempt some time ago.
> But after many arising questions remained unanswered, I had to figure
> out everything myself. 

Indeed, that's what we do as well :) Some parts of the compiler, e.g.
parser, are probably not touched for 10 years.

> And after I found out that the current compiler
> implementation is based on formal requirements, not on logical ones, I

As I said before: formalism is absolute, logic is subjective so in
complex situation formalism is really helpful.