[fpc-devel] NoGlobals branch
Hans-Peter Diettrich
DrDiettrich1 at aol.com
Fri Aug 20 12:39:18 CEST 2010
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
More information about the fpc-devel
mailing list