[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