[fpc-devel] Parallel processing in the compiler

[Hans-Peter Diettrich]

Florian Klaempfl schrieb:
> Am 06.09.2010 16:12, schrieb Hans-Peter Diettrich:

>> 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.

I stopped searching after finding such code in aasmtai, aoptbase, 
aoptobj, assemble, globals, nadd, ncgutil, nld, ogcoff, options, 
optloop, pdecsub, pmodules, psub, symdef, systems.

As an extreme case, tcgprocinfo.generate_code requires 6 additional 
virtual methods.


>> 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?

For logical (functional) grouping. Looking at the parser, a single unit 
would be sufficient for every front-end. The current high number of 
parser units results from the inclusion of the semantical and framework 
actions, which should be moved into their own interfaces (or units), or 
better into the already existing interfaces of symbols, nodes etc.

WRT to multiple front-ends, true functional interfaces (methods) should 
be added to the basic framework classes. These classes currently are 
mere collections of fields and basic methods, that do not even 
encapsulate the management of their owned objects. See InitCompiler, 
InitParser, parser.compile and all the other parser stuff, that creates 
and manipulates objects instead of delegating such tasks to the involved 
classes.

>> 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 :)

What's wrong with the parser interface in TParser?

After a separation of unrelated parts (see above), the remaining code 
can be restructured again into local subroutines, that do not appear 
even in the specialized class declaration.


>> 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.

We seem to have different definitions for "formalism". Of course it's 
helpful to have parser units start with "p", node units with "n" etc., 
but just the parser units lack any functional separation into 
syntactical parsing, semantical actions, target specifics and flow control.

Logical grouping is not necessarily arbitrary or subjective. A compiler 
can be subdivided into front-ends, back-ends and infrastructure. 
Back-ends can be subdivided into system and CPU, with further 
exchangable functional blocks for e.g. object and debug information 
formats. The compiler infrastructure can be subdivided into 
parametrization, file/module management, and intermediate data storage. 
Intermediate data can be subdivided into symbol tables (declarations) 
and code (AST), with dedicated interfaces for the front- and back-ends, 
and general optimization.

A formal separation of cpubase from cpuinfo is not helpful, unless it 
has a logical (functional) justification.

DoDi