[fpc-devel] Parallel processing in the compiler

[Florian Klaempfl]

Am 07.09.2010 09:49, schrieb 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.

Well, I see no problem with it. Of course, one can do an overly complex
design to avoid this but as I said before, I see no use in doing so. It
makes only maintainance more complex.

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

This is not logical to me. For me it is logical to group the parser by
expression sub parser, declaration sub parser etc. and even split the
declaration parser into type etc. one.

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

That it inherits from TScanner.

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

As you said multiple times: *can*. One can also subdivide more or less
or even choose another grouping.

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

It has for me a logical and formal one: cpuinfo contains info which is
used by generic/common parts of the compiler. Cpubase contains the basic
stuff which is used by the cpu specific part of the compiler. Of course,
there are deviations from this rule due to laziness and simplicity and
refactoring over time, but this is how it is used to be.