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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
