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.
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. The current high number of
parser units results from the inclusion of the semantical and framework
actions, which should be moved into their own interfaces (or units), or
better into the already existing interfaces of symbols, nodes etc.
WRT to multiple front-ends, true functional interfaces (methods) should
be added to the basic framework classes. These classes currently are
mere collections of fields and basic methods, that do not even
encapsulate the management of their owned objects. See InitCompiler,
InitParser, parser.compile and all the other parser stuff, that creates
and manipulates objects instead of delegating such tasks to the involved
classes.
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?
After a separation of unrelated parts (see above), the remaining code
can be restructured again into local subroutines, that do not appear
even in the specialized class declaration.
And after I found out that the current compiler
implementation is based on formal requirements, not on logical ones, I
As I said before: formalism is absolute, logic is subjective so in
complex situation formalism is really helpful.
We seem to have different definitions for "formalism". Of course it's
helpful to have parser units start with "p", node units with "n" etc.,
but just the parser units lack any functional separation into
syntactical parsing, semantical actions, target specifics and flow control.
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.
A formal separation of cpubase from cpuinfo is not helpful, unless it
has a logical (functional) justification.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
