[fpc-devel] NoGlobals branch
Florian Klaempfl
florian at freepascal.org
Fri Aug 20 13:41:07 CEST 2010
Am 20.08.2010 12:39, schrieb Hans-Peter Diettrich:
> 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,
E.g.?
I just greped for ifdef sparc in the general compiler directory:
11 hits:
- 5 in ogelf.pas (elf output generator, so quite natural)
- 1 in globals.pas to define the default cpu switches in init_settings
- 2 in options to display sparc only help pages and create sparc
specific defines
- 1 in systems.pas to set the sparc fallback target
- 1 in psystems.pas to set the sparc default floating point type
- 1 in fpcdefs.inc to set sparc specific conditionals
> with no reliable search
> key for these parts.
This is usually not needed. Doing a test driven approach, you'll
identify the parts to change very quickly.
> 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.
The problem is: not everything can be solved easily using OOP. And I'am
also against trying to make everything fit into OOP.
More information about the fpc-devel
mailing list