[fpc-devel] Parallel processing in the compiler
florian at freepascal.org
Wed Sep 8 08:58:19 CEST 2010
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.
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
>>>>> 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.
More information about the fpc-devel