Jonas Maebe schrieb:
Such complications can be eliminated by a refactoring of the
targets, into dedicated classes. This can be done in the same
branch, because the existing units (in the target directories) have
conflicting names, and consequently must be replaced by new unit
trees - something similar to the systems implementation.
I don't understand why this "consequently must be" done. The compiler
only supports generating code for a single architecture, and there
are no plans to change this. It would needlessly complicate the
compiler source.
My experience with the compiler sources is different. The many
conditional parts, which are not even properly chained by {$ELSEIF ...},
make the maintance and refactoring a mess :-(
Currently the introduction of a new target CPU requires to update many
parts of the existing general compiler units, with no reliable search
key for these parts. No problem when the critical pieces become (part
of) virtual methods, where it's immediately clear that virtual methods
may deserve different target-specific implementations.
A proper OO approach will simplify the compiler maintenance, and it does
not require that a final compiler really should support multiple targets.
DoDi
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
