[fpc-devel] Parallel processing in the compiler

[Florian Klaempfl]

Am 08.09.2010 03:10, schrieb Hans-Peter Diettrich:
> Florian Klaempfl schrieb:
> 
>>> 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.
> 
> That's why I suggested solutions other than $IFDEF or virtual methods.

Using ifs is usually not possible because some symbols simply don't
existing on certain architectures.

> 
> 
>>> 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.
> 
> A parser structure should support the maintenance of the language, i.e.
> syntax. 

Well, it should also support the maintaince of the compiler code ;)

> In so far I'd group together e.g. directive handling, to ease
> the maintenance in case of new directives. Your suggested structure
> applies to the semantics of the language, 

The distinction between e.g. expressions and declarations is completly
syntax driven and has nothing to with semantics.

> which should be implemented
> outside a concrete parser (front-end). It's also a bad idea to move
> procedure processing into a different class (tprocinfo), and let it call
> paser methods from there. 

Actually the naming of t(cg)procinfo is probably bad, maybe it should be
called now tproccompiler.

> That's turning things upside down, breaking
> the recommended separation between front-ends and compiler :-(

Who recommends this? The writers of books like the dragon books? Those
people never wrote a real world compiler and tried to solve the real
problems of compiler writing.

> 
> In an OO design the parser methods must reside in one class, so that the
> means for further structuring are very limited. That's why I suggested
> local subroutines for parsing specific (non-reusable) parts of the
> language.
> 
> 
>>>>> 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.
> 
> It's only a matter of taste, whether the parser should be a member or
> the base of the parser class.

Well, you can call a lot a matter of taste then.