[fpc-devel] OO rewrite - globals

[Hans-Peter Diettrich]

Florian Klaempfl schrieb:

>>> Especially since in the past several people spent a lot of time on
>>> breaking cyclic dependencies and organising everything nicely into
>>> separate units (both for the parser and for the symbol table).
>> While that separation removed cyclic dependencies, it spread very
>> different functionality across units. In at least one case a procedure
>> exists in two units, so that more work is required to encapsulate
>> functionality in more classes.
> 
> This might be happen when copy/pasting. Usually such procedures can be
> easily moved to a common base unit.

That's not so easy, when global variables shall no more be used. In an 
OO approach all the replacements of the globals have to become class 
members, or they must be passed as arguments to all subroutines. Both 
models require all related types in the interface sections of all units, 
leading to cyclic references in many cases.

A quite simple solution were threadvars, that can have different values 
in every thread (e.g. unit to compile). This requires some care to 
prevent concurrent updates of all related data elements, by arbitrarily 
called procedures. This can be controlled best when all volatile 
variables are class members, and every mutable object is assigned to 
only one worker thread. The current implementation does something 
similar, but with almost no plan and protection against access to wrong 
instances - see the many checks for assigned and equal-to-self 
references. At least we should have dedicated push/pop procedures, that 
implement safe context switches - mainly in parsing units and procedures.

Code generation is one of the parts that can (and should) be separated 
from parsing, so that local procedures can be parsed ahead (not blocking 
the parser), and the code generation can be done in parallel threads.

DoDi