[fpc-devel] Parallel processing in the compiler

[Florian Klämpfl]

Am 05.09.2010 05:04, schrieb Hans-Peter Diettrich:
> Jonas Maebe schrieb:
>> On 04 Sep 2010, at 19:41, Hans-Peter Diettrich wrote:
>>
>>> Every parallel processing requires that all related data is private
>>> to every thread. Since some time I'm trying to eliminate such
>>> (currently) global variables. Now ppudump turned into an show
>>> stopper, due to the unsystematic and obscure unit dependencies in
>>> the compiler:
>>
>> I think it is quite systematic and logical that the ppu loading
>> should not depend on code generator internals.
> 
> Right, that's how it *should* be designed. But try to find out why the
> code generation is added, when variables like current_filepos or
> current_tokenpos are moved into TModule (current_module) :-(

Why should current_filepos and current_tokenpos go into TModule? They
can be perfectly threadvars. Further, I don't see them fitting into
TModule, they describe not the state of a module but are part of the
compilation state. Even more, consider several threads compiling
different procedure of one module: putting current_filepos and
current_tokenpos into TModule won't work in this case.

> The last change was to remove ppudump from the Makefile, and this proved
> that so far only ppudump is sensitive to changes in the compiler
internals.

Guess why I'am sceptical that it's usefull to use the compiler parser
for other purposes like code tools or documentation: probably once per
week a simple compiler change breaks this external usage (we made this
experience ten years ago ;) ).

How we can continue? I'll see if I find within the next week time (I
were on holiday for one week) to review the noglobals changes and how we
can split them into usable parts.