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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
