[fpc-devel] Parallel processing in the compiler

[Hans-Peter Diettrich]

Florian Klaempfl schrieb:

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

A solution for such problems was one of the first steps in that 
refactoring :-)

Life were much easier to me, when all targets could be checked 
(syntactically and at runtime) in one (Lazarus) project. E.g. I simply 
defined all implemented targets, and immediately got a bunch of errors, 
resulting from incompatible (duplicate...) code and declarations. So my 
primary interest in a new back-end structure is more targeted at ease of 
development, than on really using multiple back-ends in one application.


>> A parser structure should support the maintenance of the language, i.e.
>> syntax. 
> 
> Well, it should also support the maintaince of the compiler code ;)

This is what I'm doing right now again, based on and extending the 
previous OO_rewrite stuff.

The NoGlobals branch actually includes most of my intended 
modifications. Since it's unusable for stepwise merging into trunk, I'm 
willing to provide patches (or another branch) for such a merge, where 
distinct patches look easier to merge to me. I only should know what 
changes are acceptable, so that I can prepare the according patches 
based on the current trunk.

This can be done as (your) time allows, i.e. as soon as I get concrete 
OKAYs for concrete steps. This will require a review of the NoGlobals 
branch, based on *content*, not only based on *formal* considerations. 
When I have to provide the patches for trunk almost from scratch, I can 
take into account any deviation from the NoGlobals or other branches, 
e.g. with regards to the base of the parser class.


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

When parser "methods" are called from the outside, i.e. from tprocinfo, 
then this has nothing to do with syntax. It also is a bad idea to call 
e.g. consume(_POINT) for the final "end." during code generation or 
other semantical actions; preserving the token position for useful error 
messages can be achieved by other means.


>> 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 a reasonable change, but not towards multiple front-ends. A 
parser can provide and deposit all information in a tprocinfo object, 
for further processing. When that object provides an interface for 
inserting all related information, then it can be reused with other 
front-ends, which only differ in the syntax of the language - and this 
is one of my refactoring goals. It can be accepted or rejected, I only 
should get a definite answer.


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

My experience recommends that. Even if I never wrote an compiler of my 
own, I've implemented a number of decompilers in the last 25 years. 
Starting with my first such attempt (a C decompiler on my Atari ST) I 
know a lot about the different code generation of concrete compilers, 
and the requirements on different platforms. This insight allows me to 
determine much about the good and bad concepts in concrete compilers, 
without having ever seen their concrete implementation.

Please understand me right, I do not want to tell anybody how things 
*must* be done. I only want to suggest general changes, that help to 
overcome general problems, as known from other concepts and 
implementations. It's up to the core developers to accept or reject my 
ideas, and I'm willing to assist in the implementation of every accepted 
change. Currently we still are before any decision, what should be 
changed at all, for what win.

DoDi